In this post on situational awareness for cybersecurity, we present five recommendations for the practice of architecture in the service of cybersecurity situational awareness (SA). Cybersecurity architecture is fundamentally an economic exercise. Economics is the practice of allocating finite resources to meet requirements. The goal of a cybersecurity SA architecture is to deploy your finite resources, such as equipment, staffing, and time, to enforce your organization's cybersecurity policies and controls. The endpoints on your network and the network itself form the space within which you deploy these resources.

The inputs to a cybersecurity SA architecture are policies and controls, plus budgets for the resources to allocate. Your architecture is only as good as these inputs. They needn't be perfect, but you should always seek to understand them as well as you can, and when they change, your architecture may also need to change.

Work Incrementally and Iteratively, Starting with Policy

Your policies and controls are the most important requirements for a cybersecurity SA architecture; if you don't know why you're building something, you'll succeed only by accident. However, policy and architecture can--and if you're successful, always will--evolve together, so they can both benefit from a process of iterative refinement.

Begin simply. Review existing policies, identify an architectural change that will promote and enforce adherence to those policies, and then ask the policy owners what they think of your proposed change. They will probably have concerns about some aspect of your new architecture. That's good. These are opportunities to explore what these policies really mean and what problems the policy owners are trying to solve. Make some changes, take them back to the policy owners, and have more conversations.

This iterative approach aligns well with other Agile processes, such as DevSecOps or scaled Agile. Like those processes, it should never really stop as long as you're still building and changing your architecture, although it will likely slow down when you have mostly designed the architecture you want. You will need to pick it back up when big architecture changes are in order.

Collect Data Across Observation Domains

In previous posts on network situational awareness, we have considered the endpoint and network observation domains, and the various techniques used by analysts to perform monitoring in those domains and respond to changes as necessary. A good cybersecurity SA architecture should determine how to collect monitoring data from those domains. It should also determine how to structure the environment in which defenders analyze that data to attain situational awareness about how policies are being followed or violated in the enterprise.

As you build your architecture, consider these domains in light of the policies you are trying to address. Some policies, such as password reuse on a single system, may be enforceable with automated controls. In this case, situational awareness consists of knowing when passwords change and whether users attempt to reuse passwords. This information won't generally be visible from the network, so endpoints must be configured to make this information available to analysts. How it is made available depends on analyst workflow and may require changes to the monitoring-and-response architecture.

Architect Around Analysts

Improvements to cybersecurity architecture for situational awareness often require buying new tools, but procurement isn't always the right answer. It can often be more effective to change a configuration, or even to consolidate from multiple tools to one. The important thing is that the tools and data empower analysis, and particularly the trained human analysts that are the most valuable part of the system. Cybersecurity SA architecture exists to support workflow and process.

This focus on workflow and process, however, does not mean workflow cannot change. If you're just beginning to implement situational awareness, you may not even have a monitoring workflow. The most valuable resource in any situational awareness activity, however, is analyst judgment. Centering workflow and working to optimize it makes the best use of analysts' time and gives them the best information from which to make decisions.

Manage Risk to Speed Implementation

Conversations and designs are important, but they aren't the end goal. When is it time to move on to implementation? This question really focuses on risk. Mistakes in architecture are usually extremely costly to fix, and you may have burned through a lot of time and money before you realize you've made wrong decisions. However, it's impossible to avoid some mistakes without getting field experience and knowing the lessons that implementation can teach you.

Therefore, shed implementation risk and start implementing as soon as it is lower than the risk of not doing so. Keep scope small. Don't try to do too much in your architecture; identify a small part of your policy problem and design a small solution. Work with your policy owners to develop metrics for success. Then run one or, ideally, more pilots to learn what you don't know and develop confidence in what you got right.

Define your success metrics before you've started putting significant resources into prototyping. You can always adjust metrics if they are flawed or if conditions change, but remember why you decided on them in the first place, and stay true to the spirit of those decisions. Your metrics should always include these two things:

• The ability to produce budgets for a production rollout. They won't have to be perfect, but they should be within the organization's tolerance for risk. Be sure to include budgets for ongoing maintenance.
• The ability to produce an integration plan, should the pilot be approved for general production.

Use Your Metrics for Success and to (Safely) Speed Deployment

Now that we know when to start prototyping our solutions, how do we know when we're ready to put them into general production? First, will your pilot solution meet your needs? Answering this question is when those metrics for success become critical and why it's so important to define them before the pilot begins. Otherwise it can be hard to separate the value of a program from the investment you've made in it. Predefined success criteria give you a superpower: the ability to say "No."

Assuming you have met your success criteria with one or more of your candidate solutions, you're ready to put a solution into practice. It's time to plan the integration of your solution into the production baseline. Keep the channels to your policy owners open, which is also an architecture problem. Moreover, you may run into issues that require clarification on policy matters. Mostly, though, you will be working with your implementation team. Implementers and maintainers are also stakeholders in the architecture, and success depends on them being able to do their jobs. Consider their needs, and consider architecture changes that may help them.

Conclusion and Next Steps

In this post, we've put together a roadmap for converting policy imperatives into implementation through the medium of architecture. We hope you can see how the need to budget resources to meet a need is an economic problem. What we have sketched out is an economic solution: an iterative, risk-driven process that tells us where to put our scarce resources and when to shift them from one phase of the process to the next.

Future posts will focus on data analysis for cybersecurity situational awareness. As an architect, you will learn more about the analytic techniques that analysts employ, and we hope this will help you understand your designs differently and give you an appreciation for how analysts provide value to the organization. Cybersecurity situational-awareness analysts are important stakeholders in the architecture process. They are not just important end users, but also a valuable voice among policy owners. They can tell you what data to keep and what to discard, potentially saving time and money. Moreover, architecture can make a cyber hunt team considerably more effective by creating cyber terrain that favors them over the adversary. Don't overlook the cybersecurity situational-awareness analysts' value to you as an architect, or your value to them.

Additional Resources

Read the first blog post in this series on situational awareness, Situational Awareness for Cybersecurity: An Introduction.

Read the second blog post in this series, Situational Awareness for Cybersecurity: Assets and Risk.

Read the third blog post in this series, Situational Awareness for Cyber Security: Three Key Principles of Effective Policies and Controls.

Read Engineering for Cyber Situational Awareness: Endpoint Visibility, the fourth blog post in this series on situational awareness.

Read Situational Awareness for Cybersecurity Architecture: Network Visibility, the fifth blog post in this series.

Read Situational Awareness for Cyber Security Architecture: Tools for Monitoring and Response, the sixth blog post in this series.