Another Breach! Security Controls Shouldn’t be that Hard!

I just read an interesting article in Network World about a breach at a major financial institution. The article pointed out that the breach resulted from a lack of deploying adequate security controls on the corporate servers. The article goes on to state, “Strong access management policies and network segmentation are key to limiting the extent of damage that attackers can do once they gain a foothold inside a network. However … implementing uniform security controls across their vast networks can be difficult because they often have to integrate large numbers of new systems with different levels of security as a result of acquiring other companies.”

There are a number of reasons that it is difficult to adequately deploy security controls – mergers and acquisitions, different organizational groups involved, disparate/heterogeneous systems, etc. – but, on an increasingly regular basis, the media continues to point out real world examples that illustrate the importance of deploying proper security controls.

There are a number of aspects involved in security, but I’d like to drill into the points that are quoted above: 1) access management policies and 2) network segmentation.

Let’s first look at access management. This is all about addressing “who can do what,” so let’s focus on identity and privilege management. There are some first principles that can help us think about how to make it easier to deploy and enforce access management policies:

  1. Have a unified namespace – namespace needs to be distinct and deterministic
    • Namespace management is at the root of any system that requires association with any type of anchor (e.g. need to associate attributes or policies with a user)
    • If the user “John Doe” exists on different systems, is this the same person or different people?
    • If a Unix user ID is “123” on system A, is “123” on system the same user?
  2. Privilege and access policies need to be consistent across an environment
    • If John Doe is supposed to be a web administrator, the definition and configuration of a web administrator should be consistent from system to system (and across platforms such as Unix/Linux/Windows)
  3. There should be a way to answer the question “Who can do what?”
  4. There should be a way to answer the question “Who did what, and is it what I expected?”

I won’t go into a deep dive where I shamelessly plug the Centrify Server Suite software, but I will mention a few key points that you can drill into on our website:

  1. Centrify Server Suite leverages the most widely deployed identity directory service in the world – Active Directory. This assures a consolidated user namespace, security via open standards (Kerberos), and a time-proven identity repository that is highly available and fault tolerant (in other words, no need to certify another identity silo to assure availability, scale, and disaster recovery). Centrify’s solution also assures that namespaces are centralized and mapped appropriately across systems under management, so no worries when it comes to disparate UIDs and GIDs across Unix/Linux systems.
  2. Centrify uses a roles-based approach for defining and enforcing least privilege access. Combined with the Centrify Zones management model, our customers have a “single pane of glass” for all access policies across more than 450 different flavors of OSes – this covers not only authentication and profile mapping, but also authorization and auditing policies!
  3. With built in reports and the ability to customize reports with PowerShell, Centrify Server Suite provides all the information you need to clearly identify “who can do what” across all the systems under management.
  4. Centrify Server Suite audits all activity, and with the Enterprise Edition customers are able to see all activity in both event/meta-data form as well as full session video capture. This provides a closed loop, single solution for establishing privilege and audit controls, as well as providing proof for auditors.

CSS key capabilities

Ok, now let’s look at network segmentation.

Security professionals always talk about “defense in depth,” and we hear metaphors such as “a bank has a lock on its front door, but your money is still locked up in a safe within the bank.” So, segmenting servers within your network is part of a defense in depth strategy. For example, you may wish to make sure that only servers involved in credit card transactions should be able to communicate with each other – there is no reason for a development server to be able to communicate with a back office credit card server.

So what’s the big deal about network segmentation? Well, one important aspect is how much you think your servers (network endpoints) may change and how this impacts your network configuration and network access rules. In the past, servers were relatively fixed – they had a static IP address and networks were configured based on the IP addresses of those servers. Servers could be configured into specific subnets and corresponding VLANS. Fast forward to now, and we see servers being instantiated on the fly within virtualized environments or in cloud style environments. We also see more change due to reconfigurations and activities such as mergers and acquisitions. All of this puts more strain on the organization, because server teams and network teams need to operate in lockstep in order to assure consistent access policies.

One way to address this problem is to make the network really smart – make it know everything or make it “programmable” so that it can reconfigure itself on the fly. We are seeing this with the whole movement around software defined networking. Another way to address this problem is to move the network isolation enforcement closer to where the data/services reside, namely, on the server itself. Every server has a network interface and is capable of providing network isolation based on protocols such as IPSec which operates at the network layer (and can also provide confidentiality of the data in transit). Both of these mechanisms are valid, and you should decide what mechanisms work best for your network segmentation needs.

That said, I would like to mention a little discussed technology that Microsoft developed – essentially, it allows for centralized configuration of host based network policies based on Microsoft Group Policy. In this way, any Windows server may be set up with specific network access policies based on using IPSec. Now, here’s the interesting part – Centrify provides this same capability for non-Windows systems, so that you can set centralized network isolation polices across the heterogeneous servers in your environment. This enables centralized identity related security policies within the same “pane of glass” – pretty cool huh? As a result, the administrator who is setting up servers and access policies can also configure the server policy for network segmentation. For more information on this, take a look at the Server Suite Platinum Edition on the Centrify website.

isolation and encryption

I admit to being a little biased, but I think we’ve got a great solution for “strong access management policies and network segmentation.” What do you think?