The CERT Division of the SEI has evaluated the cyber resilience of hundreds of organizations. We've seen that many organizations may not have formally established a controls management program. In this blog post, we will describe the basic controls management life cycle and provide a method for establishing effective controls for a new "green field" system or identifying gaps in an existing "brown field" system.

Cybersecurity controls management is vital to building a resilient system.

For many technically-minded folks, the thought of building a new system can be like tearing open presents on Christmas morning. There's no better feeling than adding new servers to your VM cluster, or installing the latest Integrated Development Environment (IDE) and just slinging some sweet code. Reality sets in when it's time to show the business folks (who paid for our new toy) that the juice is worth the squeeze--or to put it in business speak, "This new tool will allow us to reduce our total cost of ownership by maximizing our return on investment." Sounds great. But how?

Unfortunately, if you've gotten this far in the process without following some type of controls management process, you may have a hard time decreasing TCO and increasing ROI. Let's take a look at some basic controls management practices.

In our VM cluster example, you just purchased new servers to add to your cluster.

• How did you determine the specifications for the server?
• Did you simply buy the same hardware as before?
• Did you buy newer, faster servers to give more "oomph" to your critical systems?

Knowing the answer to these questions is the first phase in controls management: defining your control objectives. Control objectives are nothing more than requirements. So, before you buy those new servers, go ahead and write down your requirements. Share them with your peers, your manager, the compliance team, and anybody else who can help you identify the technical and regulatory requirements that your new acquisition needs to meet for a successful deployment.

To take defining control objectives to the next level, consider adding a table top exercise (such as threat modeling) to your process. This allows you and your team to identify hidden "gotchas" that may not have previously been considered.

One very popular form of threat modeling is known as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege). Many of those topics will be near and dear to the hearts of security folks. Their work lives revolve around preserving the confidentiality (information disclosure), integrity (tampering), and availability (denial of service) of the systems and services they support.

There's a bit of a learning curve to conducting a threat model exercise. But after a few practice runs, you'll start to see the value in the effort. Start by drawing a high-level diagram of the new system or your existing system and applying the various threat types to each of the shapes. A STRIDE threat model has four shapes that represent the following components of a system:

• processes (services)
• external entities (web browser or third party system)
• data stores (log files, registry entries, database)
• data flows (stick to virtual/physical networks to start with)

As shown in Figure 1, each shape is evaluated for one or more of the letters of the STRIDE acronym.

Figure 1 - STRIDE Associations

Figure 2 shows an example of a simple high level system diagram that's made of the STRIDE shapes.

Figure 2 - High Level System Diagram

Not sure which threats to evaluate? If you're building a web application, perhaps you should start with the Open Web Application Security Project (OWASP) Top 10, which lists the ten most critical web application security risks. If you're not building a web app, or you're looking to expand your threat model, perhaps you should speak with representatives from an information sharing and analysis center (ISAC) about the pertinent threats in your industry.

For example, phishing is a very popular entry point for bad actors. These bad actors are "spoofing" vendors such as your ISP or your mail provider. After a successful compromise through a phish, they're now also spoofing an end user on your network. Phishing is just one example of a highly visible spoofing threat.

For a great resource on STRIDE threat modeling, please consider reading Threat Modeling: Designing for Security by Adam Shostack.

Once you've defined your control objectives, it's time to go shopping for the control. In this case, we're buying servers. This is the second phase of controls management: implementing controls.

For tech folks, this is their favorite part of the process. They're implementing something new while enhancing the level of service their employer provides to their customers. This is also the phase that everyone does. Everyone implements controls--unfortunately, with varying levels of success! To augment your chance of success, be sure to define control objectives first.

The final phase (and the most often overlooked) is evaluating the control to ensure that it meets the control objectives. Before deploying your servers into your VM Cluster, you'll run formal or informal acceptance tests. However, are your acceptance tests based on your control objectives? Are you testing your control (new servers) to make sure they meet each and every control objective?

This practice is often referred to as a gap analysis and is imperative to developing a successful controls management strategy. Even the most sophisticated processes can have gaps. It's best to have a defined process for catching those instances where the control does not meet the control objective.

In this post, we've discussed the three main phases of controls management: defining control objectives, implementing controls, and testing the controls (gap analysis). Defining control objectives is vitally important to determining the correct controls. Augmenting your control objective phase with a table top exercise will help your organization to limit the number of missed control objectives and thereby build more resilient systems. Implementing controls puts them into action. Testing the controls shows whether they actually meet your control objectives.

For help with analyzing your controls management strategy, we encourage you to contact the Department of Homeland Security to determine if you qualify for a free Cyber Resilience Review (CRR) assessment. The CRR is a one-day assessment that helps organizations identify problem areas in their cyber program related to asset management, controls management, vulnerability management, and similar topics. You can learn more by visiting US-CERT Assessments: Cyber Resilience Review.