Secure Beyond Breach
Preparing Your Organization for Success
In this chapter:
- Steps to prepare for a successful micro-segmentation project
- The two phases of implementation and which teams have to be involved
- 5 most common errors to avoid
When you assume breach and consider micro-segmentation as a control that you want to adopt, it is important to note that this cannot be done in absentia of other individuals and groups within your organization. This chapter describes the different people that may need to be involved in two different phases of implementation.
In phase I: Identifying Initial Target Applications, the organization identifies the applications and infrastructure that they want to protect. Phase II: Engineering the Solution is the implementation stage, with a focus on the segmentation process. The same people do not need to be involved throughout the process – in fact, some team members may come and go on the project. You (and your organization) need to be comfortable with this fact and set the proper expectations for the people involved.
For instance, the accounting team may need to be consulted during the period in which the organization identifies critical applications. Accounting may know which applications are used to generate and recognize revenue but may not be involved with the actual job of implementing segmentation – nor in the ongoing effort to make segmentation part of business as usual. Meanwhile, the Linux platform engineering team might take over after the applications that need to be protected are identified and might be involved throughout the micro-segmentation program.
Chapter 4 discusses how to avoid “boiling the ocean,” or, how to make sure you get the micro-segmentation program up and running. The key to not boiling the ocean is identifying first desired outcomes and creating a plan that allows those outcomes to be realized.
The question is how to avoid the temptation to do everything on the segmentation journey. Applications naturally sprawl and may live in existing data centers and public cloud environments. The answer is to get the right people involved in determining your first desired outcome – that is, what you want to secure beyond the breach. That’s why we begin with phase I.
Phase I: Identifying Initial Target Applications
To determine the first cybersecurity goals of your organization, it is critical to get the right people in the room. Since no single person can contextualize the entire application ecosystem and understand which applications are the most business critical, it is good to get team members from each department to a meeting (or series of meetings) to find out which applications their respective groups truly “can’t live without.”
In some organizations there have been past efforts to identify critical applications. That information should be brought to the working group; starting from scratch may be unnecessary.
First, build your tiger team. Appoint a tiger team leader who has core people skills: they can influence and win over others, build alliances, dig into research, and drive change with authority. If this person doesn’t already have position authority to drive change, a senior leader should empower them with this authority
The tiger team in phase I should include the person who will eventually own the micro-segmentation service for the organization (see description in phase II) as well as representatives from these departments:
- IT / Security
It is critical that key stakeholders appoint accountable people to the tiger team.
Tiger team members should work with others to rank the organization’s applications on a scale from most to least critical or non-critical. As representatives respond, you will quickly see that many applications are used by multiple groups within the organization – and while one group may view an application as critical to their function, others may see it as low priority. At the very least, the organization will learn how different applications impact different groups.
Once the applications are listed and identified with regard to criticality, you need to assess the ranking – the challenge with identifying and protecting the initial applications will be people and process, not technology.
Repeatable processes will be vital to the program’s success. Ensure that your organization can make the internal process changes required to protect the applications. For instance, make the tiger team choose the top thirty applications to prioritize for segmentation; any additional applications can be protected after your organization builds out the micro-segmentation process for the first tranche of applications.
Remember, the journey to micro-segmentation is not principally a challenge of technology; people and process determine the organization’s success.
Phase II: Engineering the Solution
Choose a project lead
Once the initial target applications have been identified, a senior executive or executive team will need to identify the person who will serve as the long-term micro-segmentation service owner. The owner may be the same person who led phase I and was on the tiger team. Multiple people can succeed in this effort. So what are the critical skills and components?
Given the different groups involved in the segmentation effort, the leader must:
- work across different functions;
- have a proven track record of driving initiatives within the organization;
- understand how the organization works;
- prioritize and make strategic decisions.
This person is likely to have the most critical role in the segmentation effort and should be someone in IT infrastructure, network engineering, or security. Most important are leadership skills to build partnerships and alliances across the organization as well as technological acumen to make decisions about tradeoffs.
Let’s get into the range of teams who will be involved in the micro-segmentation effort throughout the process and into sustainment.
- Application owners and teams: These teams know how their application(s) communicates and which workloads are part of their application(s). These teams also know about applications that are being redesigned or re-platformed, which may be a way of getting ahead of segmentation so that policies can follow the application development lifecycle.
- Core service engineers: This team runs “core services” like Active Directory, NTP, Syslog, DNS, and other critical systems within the organization. Because most applications use these core services, core service engineers need to be involved early to identify the workloads in the services they provide. They attest to the workloads that are part of their applications. They are involved again during the policy development phase, when organizations opt to segment core services.
- Network team: Traditionally involved with network segmentation, this team needs to understand how the microsegmentation effort will impact them.
- Configuration management database (CMDB) team: All micro-segmentation solutions on the market use tagging or labeling for writing policy. Ultimately those tags and labels should come from a canonical source of truth. One recommendation is to use the CMDB as this source, which means that the solution should synchronize with the CMDB around workloads and their tags and labels.
- Security team: This team receives alerts from blocked traffic and must be involved with onboarding the segmentation solution, so it is critical to get the security team involved early.
- Security operations center: In the end, the microsegmentation solution will be passed on to operations. Therefore, a set of workflows need to be developed in the security operations center (SOC).
Identify applications to be segmented
Once the leader has been identified, it is a good idea to get the application engineering team into a room to conduct analysis of the applications that will be segmented. Application engineering and the owner of the micro-segmentation project should put them into three categories.
Category 1 applications will not be re-platformed or updated any time in the near future. These are the truly brownfield applications that will require deep application dependency mapping (as discussed in chapter 5).
Category 2 are those applications that are set to be re-engineered, or new versions that are set to be delivered. These applications can be handled by including segmentation in the application development lifecycle.
Category 3 applications will be re-platformed; that is, moved from IaaS to containers or moved to the cloud.
Define roles and responsibilities
Once the categories of applications have been listed, the next step is to gather the different teams and organize the effort.
For category 1 applications, the critical teams to involve are:
- Application service owners, application developers, and application security – responsible for ensuring that applications are running and available at all times;
- CMDB team – responsible for maintaining the metadata (labels and tags) that will be used to write segmentation policies;
- Core service engineering – run Nagios, Active Directory, NTP, and other services that most (if not all) of the workloads within an organization use;
- Platform engineering – primarily responsible for Linux and Windows engineering.