Unless you've been sleeping for the past few weeks, you've likely heard about the scandal regarding the NSA's secret PRISM program, which allegedly monitors all national and
If this news didn't revive the discussion around building a good enterprise security strategy, it certainly caused many to take a second and critical look at cloud-based services, especially those operating under U.S. jurisdiction.
A similar story about a foreign security agency hacking the Belgian ISP Belgacom is also affecting government enterprises and companies operating in the European Union. According to information released about the incident, the malware that spied on the international traffic the ISP handled was so advanced it remained undiscovered for almost two years, even during intermediate security audits several companies carried out.
With the news of these incidents, the question remains: How can organizations protect themselves against such security attacks?
It's not possible to create a 100% safe system, at least not without disconnecting it from networks and the Internet, which is what the Russian Intelligence Agency appears to have recently done. Should we all revert to using typewriters instead of Exchange email? Most definitely not. However, recent news emphasizes the need for a clear enterprise security strategy.
What should this strategy include? More than just technology.
All too often, enterprises emphasize securing their networks and the systems on them. But in cases where people are determined to retrieve confidential data, they might exploit other vulnerabilities as well, including poor physical security or even gullible employees.
A typical enterprise security strategy includes a multi-layered defense over all involved areas, which encompasses physical access, employees and information and communications technology. It's no longer enough to implement measures to keep someone out of your network and systems because it's only effective if you closely monitor for suspicious activity. There is no single way of doing things right, and there isn't a way to fully protect you or your network from threats. However, you can make the perpetrator's life as difficult as possible.
Simple steps to secure your Exchange environment
There are obvious actions you can implement in your enterprise security strategy to secure your Exchange environment, like securing physical access and the network itself. The latter can be achieved by deploying multiple network security devices, including firewalls and reverse proxy servers. But in an Exchange environment, there should not be any firewall between your Exchange servers -- at least not one that actively blocks traffic. To provide an additional layer of security, you could secure server-to-server and client-to-server connections using IPsec.
In addition to the basic actions you can take, consider these more specific steps.
Authentication: Probably the single biggest security risk in enterprise networks is authentication. Implementing strong authentication mechanisms will significantly reduce potential risks. After all, knowing a user's password is no longer enough to gain access to resources. Outlook supports smart card authentication and vendors such as RSA allow its software to be deployed for two-factor authentication in programs like Outlook Web App. Still, third-party security tools could introduce additional challenges.
Role-based access control: Limit the amount of administrators and start leveraging role-based access control (RBAC). RBAC is one of Exchange's built-in features that can help you restrict access to specific resources. Prior to Exchange 2010, admins had to revert to setting permissions using access control lists in Active Directory. RBAC allows you to do the same, but it defines access based on a set of rules in Management Roles or Role Groups.
These roles are then assigned to specific security groups that let you add users who need specific access to Exchange. If you want to take it one step further, you can set time limits for administrative access to your environment by only temporarily adding someone to a certain security group.
The problem with RBAC is that Exchange, or the tools that plug into Exchange's management framework via PowerShell, enforce it. All RBAC does is offer a different approach to authorize access to resources. Under the hood, Exchange is still modifying Active Directory (AD) attributes. This also means if someone has appropriate permissions to change these attributes directly in AD, he's perfectly able to do so. In the end, your security is only as strong as the weakest link in the chain. Consider deploying split permissions if you need to further restrict access for Exchange administrators in your environment.
Audit logs: For monitoring, use Mailbox and Admin audit logs to record and report the use of administrative privileges. These features can help you backtrack any changes that might have been made.
Security patches: Deploy security-related patches for your devices and systems. Microsoft frequently releases updates for its products that often include security updates. Revise the updates and deploy them in a timely manner. Look out for any critical updates. Microsoft does a good job of communicating them over its security bulletin blog, but don't forget to test them first.
If you are really concerned about security in your organization or if you have the feeling you're not doing enough, consider hiring a security professional. These professionals can conduct a security risk assessment and create a mitigation plan based off that. In the end, it's not only Exchange that will benefit from it. Be prepared to make some significant changes, even in the areas where you least expect it. Often times, it's not just technology causing problems.
About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.
This was first published in October 2013