“I think the most important part of the architecture process is risk, informed by data. Nowadays, it’s all about the data. We’ve moved beyond building strategies to protect a given server, or service. In reality, what you really need are strategies to protect the data.”
– Steve Orrin, Federal CTO at Intel Corporation
(IT) Risk Management
Risk management is a key part of most (if not all) of the numerous security frameworks, regulatory requirements, security architectural frameworks, guidance, and other practical security advice you will come across. Meaning, it is understood to be of such importance that it is near-universally prescribed as a key principle and tenet of generally accepted security practice. Some organizations, particularly larger organizations, will have either a high-level risk management function that cascades in focus to the technology environment or an IT-focused risk management function. Other times, mostly in large and highly regulated organizations, they’ll have both.
The function of the risk management team is to ensure that any given risk is identified, assessed for impact and likelihood, mitigated to the extent practical, and tracked over time. What’s a risk in this context? It’s defined formally by the International Organization for Standardization, Risk management – Vocabulary, as the “effect of uncertainty on objectives” or, perhaps more concretely, in COBIT 5: for Risk, ISACA, (indirectly referencing the ISO guide) as “…the combination of the probability of an event and its consequence…”. In plain language, it’s the combination of the likelihood and impact of something unexpected arising. Risk management seeks to account for these risks systematically. Therefore, risk managers are the folks that oversee and implement that effort.
Risk management can be general in nature, applying to the entirety of the business and all risk sources (for example, business risks, financial risks, operational risks, and so on) or it can be narrowly scoped (for example, IT and/or technology risks).
Risk management is absolutely critical to the security architect for a few reasons. First, in keeping with the principle that the security architecture is there to ensure that the business can meet its goals and to enable the mission of the organization, risks to the business are obviously an important part of making that happen.
Second, an understanding of what risks exist is key to the goal of resilience: specifically, knowing what could happen, how likely it is to do so, and what the impact might be as a result is an important part of ensuring that the overall system, network, and applications are resilient to those unexpected events. In fact, risk management is so critical to the process that you will notice that we have included a section on it as part of the process that we’ve laid out in our book.
In organizations that have a defined risk management function, security architects will find that they are one of the main stakeholders in the work that the architect performs. They will, for example, help the architect to prioritize controls, security mechanisms, countermeasures, and other artifacts of their security vision and strategy. They will help translate underlying business requirements into security goals, they will track residual risks that may exist after countermeasures are put in place, they can help provide and track important metrics to the architect about the function of security solutions post implementation, and they will in turn be a primary consumer of metrics and telemetry gathered by the architect.
Because information about risk is so important to the work of the security architect, if the function does not formally exist within the organization, architects will find that they will need to perform some elements of the risk management process themselves.
Security Operations
The last area that we will cover is that of security operations, that is, the folks that directly use, maintain, interface with, and otherwise administer and support the security controls and tools that the architect fields into production. Security operations can be its own team, it can be part of another team (for example, network operations), or it can be distributed functionally based on the tool/control in scope (for example, firewall administration in network operations, application controls with business teams, monitoring tools in the security operations center, and so on).
Operations teams work closely with the architect in a few different ways. First, given their role as the primary interface point for the controls that the architect will deploy as part of their strategy, they can provide valuable input to requirements; they can help ensure that architecture designs are feasible and maintainable. Second, they can provide requirements directly into the architectural process; for example, there may be gaps in the visibility they have into the organization, areas where operations can be streamlined, or other criteria that can become requirements of the security architecture design.
This means that, just like the other roles outlined previously, security architects and security operations teams will need to work together very closely for maximum effect. Likewise, it is not unheard of for architects to take a more active role in the operational side of the designs they put together. This is often the case in smaller companies where security operations may not be a fully realized function, it can happen in situations where security operations are distributed and there is no clear home for an operational element in the design, or it can happen for certain areas of operation that are needed by the architect but that the operations team is unable to support (for example, the gathering of metrics from controls).
This post is part of a series excerpted from our book: Practical Cybersecurity Architecture: A guide to creating and implementing robust designs for cybersecurity architects, ISBN-13 : 978-1838989927 available at Amazon and published by Packt.