Secure Beyond Breach
The Specifics of the Policy Decision Process
In this chapter:
How to take a strategic, risk-based approach to making policy decisions
7 practical steps for policy decision-making
Application dependency maps get your organization mapped out. To protect your crown jewels and data centers against breach, however, you need to define policy for how applications and workloads are allowed to interact. Identifying the required policy takes effort and when you begin the journey into micro-segmentation and policy decision-making, the landscape can look daunting. This chapter will build on previous chapters by walking you through the specific questions that come up in the policy decision process and helping you to see your way forward.
Breaking down the task into achievable steps can make it far more manageable. It is important to construct a plan and focus on achieving results that provide organizational value. To this end, the first thing to identify is where to start and how to most effectively deliver on the organization’s objectives.
In previous chapters, we described how crucial it is that you understand the stakeholders that need to be involved in the micro-segmentation process and determine where to begin the project. Typically the policy decision process includes security teams, who define standards and best practices; business service owners, who are best placed to understand how business applications operate; and security implementation teams, who may prepare and implement policy. Organizations vary in this regard but identifying who needs to be involved in the policy decision process and calling out their respective roles is key to success and smooth running of the process.
There are two fundamental approaches to the policy decision process: the strategic and the tactical. Both hinge on people and process over technology. By working with the key players to set policy and make change, you can achieve lasting security for your crown jewel applications. It requires a strategic approach to look across your enterprise and smart tactics to both win support across the organization and control your environment.
A strategic approach to a segmentation project makes the most long-term sense.
You want to start making policy decisions where it is easiest to implement segmentation and where the perception of risk is lower, as explained in previous chapters. Once you get some initial applications completed, other service owners can see and understand the benefits. To set policy and achieve segmentation, it is best to pick a representative application (or a set of representative applications) and proceed through non-production instances to pre-production and finally to production in a controlled manner. You can then operationalize micro-segmentation and are ready to turn this into a mainstream process.
Much of the heavy lifting will be done in the first few applications, and this approach allows the organization to plan, deploy, learn, and improve. The first application will require the foundational infrastructure to be in place, the necessary integrations to be built in, and a segmentation policy to be developed in order to gain controlled access to your core infrastructure. Once complete, all subsequent applications will inherit all of the work. Therefore, subsequent applications do not have to revisit setup and initial policy development, which allows you to get on with the job of authoring business application policies efficiently and without distraction.
The strategic approach is an effective one and likely how you would prefer to run any project. However, often the organization is pursuing segmentation because of a compliance deadline, audit requirement, or known risk that needs mitigation within a defined timeframe. In such instances, many organizations are deploying micro-segmentation on their most business critical assets and on an aggressive timeline.
An urgent requirement to deploy a solution focuses the organization, gains senior leadership support, and facilitates fast progress. Once the technology is deployed and proven in the most critical parts of the business, it takes many concerns and objections from other business service owners off the table. The technology is not difficult to deploy or use as there are no changes to topology or infrastructure. The main challenge is overcoming organizational inertia. A strict timeline with strong executive support can overcome this inertia and enable meaningful change.
But where do I actually start?
Assuming you have decided on your approach and which services or applications you will tackle first (as discussed in chapter 4), you will still feel a sense of uncertainty about where to begin. Fear not: there is a well-trod path to take.
It starts with a plan.
Your first step is to build a project plan that contains steps for design, implementation, and validation. Planning is key to success, and labeling and policy design are central to the process.
To read the rest of this chapter, download the PDF below.
Check out Chapter 7: Considerations for Cloud and Containers