Secure Beyond Breach
Don’t Boil the Ocean
In this chapter:
- Key criteria for deciding where to start segmenting
- Early planning considerations and tips
One single concept underpins much of cybersecurity practice, including micro-segmentation (sometimes referred to as security segmentation): the principle of least privilege. First used in computer science in 1974, least privilege is the practice of limiting a user’s access to the information required to complete their job. Another term for least privilege is “Zero Trust.” Zero Trust (sometimes also referred to as default-deny or whitelist) is an approach to security where the default stance is to block access unless explicitly authorized. Micro-...
The principle of least privilege applies not only to users but also to workloads and applications in the data center and cloud and to IoT and other devices that are part of the network. Least privilege also applies to services provided by the environment. An IoT-enabled smoke detector should not be able to access human resources systems to control personnel information, for example. Personnel management is not part of the job responsibility of a smoke detector – and such unnecessary connections present unacceptable risk within the enterprise.
Micro-segmentation is simply the application of the principle of least privilege to the machine-to-machine and application-to-application traffic inside a data center.
Applications and machines should have the same need-to-know limits imposed on them as humans. Once broadly applied across the data center, this technique limits the movement of bad actors inside an enterprise infrastructure.
So once you have your teams aligned and your metadata managed, where do you start?
Where to Start
Given that the concepts of least privilege can and should be applied pervasively, the most common impediment to segmentation success is to assume we can “boil the ocean.”
As with any good security or IT project, the chances of success increase when a high-priority business need aligns with security goals. Finding this alignment can sometimes be a challenge. An example of an early opportunity for success could be identifying a single critical application, ideally one that will likely be audited and that comes with a financial or reputational impact.
A great first win is to segment the application and block unnecessary attack paths into the application. This helps a business owner solve an audit item problem and encourages everyone to take security responsibilities seriously. It also shows how a team of people can make progress happen not only effectively but quickly.
These three benefits – support for the business, security effectiveness, and operational efficiency – are the key ingredients for a first win in any enterprise.
These significant early accomplishments build confidence across the organization and provide a foundation for the project’s continued success. You can share the results of the early win and attract other business leaders within your organization to approach the project with interest. They will perhaps even selfselect into the next round of micro-segmentation projects for the enterprise.
Be strategic: start with the crown jewels
You need a strategy to identify where to start. First, you need the right tools to understand who all your users are, which was discussed in previous chapters. Second, you need to have a catalog of all your information – the green pill of metadata.
Third, you need a whitelist mapping of users to information that is driven by a well-defined need-to-know rationale. Finally, you need a security control that can enforce your map, the policy decision process.
Start with a survey of your digital “crown jewels,” as explained in chapter 2. Many organizations have already done this work and categorized applications that are of critical value to the business. Working from an existing application helps ensure the micro-segmentation project has significant value to the business. Unless you’re The Coca Cola Company, improving the security of your employee beverage tracking application probably isn’t enough. So if you haven’t made a complete application list, you should identify and target one of your digital crown jewels first.
If there is a critical application with security and audit findings against it, that is a great place to start. The immediate, pressing need of an internal or external audit – or a mandate for business compliance – provides ample opportunity to show immediate and quantifiable impact across the enterprise. The scope of the first deployment should not be the largest or smallest within the organization, or the most complex. Too small a scope may provide too little value and visibility, and too large a scope may introduce unachievable complexity, resource requirements, and risk. Starting with an application dependency map is a valid analytical approach for gaining insights on where to start.
Finally, there needs to be a willingness for operational change on behalf of the application owners. In enterprises, some applications in operation have been functioning for years, barely touched or assessed. The application “just works” and is reliable; owners are resistant to any sort of change or perceived tinkering. The developers of the application have long since departed, leaving scant documentation, and the operational team responsible for its health fear the instability of change on a system they don’t fully understand. Such an application isn’t the best first candidate.
Instead, choose a healthy application with a business need for ongoing change, such as a new version or feature deployment, or an application whose function is well understood.
In summary, the key criteria for deciding where to start the micro-segmentation project are:
- high value (a.k.a. digital crown jewels);
- mandate (audit findings);
- alignment with business needs and programs for change (e.g., new version or feature deployment).
Starting strong requires the involvement of the right people. These are the key stakeholders around which the working group is built, such as the security team, the application owner and/ or development team, and the system administrators who often own the operational aspects of the system. Without the support of these individuals, decisions cannot be made and key actions will languish.
Micro-segmentation is a disruptive change to the status quo, and deploying it within an organization will require a new process. The first deployment is an opportunity to build that process by understanding what works for the organization and how the various teams interact with each other. The goal is to systematize the process within this first deployment and to document early learnings to promote ease, pace, and stability for wider adoption. Process-oriented members of the team are critical at this stage.
To guide the decision of where to start, let’s use the analogy of building a city. Prior to breaking ground, there must be a full survey and map of the land and the surrounding area. The impact needs to be understood; the builders need to know what they are “working with.” Having a full application dependency map of the data center and various clouds enables intelligent and impactful decisions to be made easily, ensuring that each edifice is correctly built from the foundation up and remains stable no matter how many floors are added.
Simply showing application owners a full-fidelity map of the environment with all assets and traffic flows often yields one of these “aha” moments:
- “I didn’t know that application was still running.”
- “I didn’t know those two things talked to each other.”
- “That’s not supposed to be happening.”
That last revelation is always the most exciting. But the actual output of this map process will be that application owners can determine what their workloads are doing all the time. Application owners know their applications best – here is where we ensure all the applications are present and accounted for.
Once the initial survey of the land (building the map) is complete, the next step is analogous to building the roads, the mass transport systems, and electrical grid – foundational infrastructure to support the city. In micro-segmentation, this equates to authoring policy related to core services.
Dial-tone services are the vital core services for getting your infrastructure up and running. They allow other systems to run, such as DNS, DHCP, Active Directory, Syslog, and Chef/ Puppet, which are non-negotiable components of a data center; every workload requires access to them. Starting here sets the foundation for every other application to gather an immediate view of the flows to these core business services. It’s worth spending the time to ensure as much information as possible is captured at this stage, as it will provide the foundation and ease to application owners for flow attestation, removing burden, and eliminating potential confusion at later stages.
To read the rest of this chapter, download the PDF below.
Check out Chapter 5: Mapped Out: Application Dependency Maps and the Path to Security