The most important piece of architecture is to understand the why: why it is that you are doing what it is that you are doing. Understanding the why leads you to the how. Understand it in the context of the broader business and organization goals context and let that be the guide to when and how you implement security.
Ted Ipsen, president and COO of Positroniq, LLC
Security is not an end in and of itself – it doesn’t operate in a vacuum. This means it is only useful in the furtherance of some other goal that an organization or individual has. Or, as J Mascis asked on the seminal album Green Mind, “How can you move without a goal?” Would you use antivirus software if malware didn’t exist? Would you hire armed guards to protect an empty room? Of course not. Without a goal – that is, something to protect – security controls have no point.
Understanding the mission of the organization is the starting point for security work. In a business context, the mission (among other things) usually involves the business being competitive, profitable, able to undertake new activities, enabling the workforce, positioning itself the way it wants, and minimizing risk while maximizing opportunity. Other organizations (for example, non-commercial entities) might have different missions.
Start with the enterprise goals and examine them for the success factors or enablers. Identify high-level goals, describe the reason for these goals, and build the implementation strategy to reach them. Implementation determination of which technology, security, and practical factors are required to succeed. You might refer to this as a “technology goal”: a part of a larger plan that feeds into and supports a business goal.
Technology goals and success factors branch off to be supported by security goals and define things that need to be in place to support the usage of that technology securely. This figure shows how the flow works in practice.
Starting from the top down, you could map out most, if not all, of the security goals and necessary functionality that will represent the “universe” of items that are important to us (security requirements) in our security architecture. By “cascading” each of the organizational goals to the implementation strategies that support it, and using the resulting subgoals to provide input to the next layer in a pyramid-like fashion, this would (should we complete this exercise in its entirety) result in a complete list of all the technology and security goals that our architectures will need to support.
This is a security-focused view into the COBIT 5 “goals cascade” (COBIT 5: A Business Framework for the Governance and Management of Enterprise IT. Pages 17-20. ISACA), which is, in turn, based on research from the University of Antwerp. There is a continuous chain from the highest organizational goals down to each and every technology and security outcome necessary to support the organization’s mission.
To sum up, a systematic approach follows these steps:
- Understand enterprise goals
- Derive organizational success factors (organizational enablers)
- Derive technology goals
- Derive technology success factors (technology enablers)
- Derive security goals
- Derive security success factors (security enablers)
You could spend quite a bit of time going through this process completely, and fully for an entire organization. And there is benefit in doing so. However, we need to balance completeness and depth of understanding with time constraints; no one has infinite time.
Luckily there are some ways to abbreviate the process. Most organizations already have documentation written that codifies security goals and success factors implicitly or explicitly. Look for documents (such as policies, procedures, standards, and guidance) that either directly or indirectly state security goals. For example, a policy statement such as “passwords must be a minimum of 10 characters in length” tells us something directly about security goals, while a statement such as “log all access to confidential data” tells us something indirectly. To the extent that these are recorded already, we can leverage them to save ourselves quite a bit of work in building our baseline understanding of what’s important.
Secondly, there are assumptions that we can make based on how things normally work that can also save time, meaning we can assume things about the technology landscape that are likely to be true even if we haven’t specifically mapped out each and every enterprise goal that they in turn support. For example, you may not have visited every state in the US to observe roads in all states, but you can infer that drivers in all 50 states drive on the same side of the road since this rule is federal.
Shortcuts are fantastic for saving time, but don’t forget that they might not tell the whole story. There can be times where drawing upon policy documentation can lead us astray. For example, we all know that not every organization follows their security policies to the letter. And though some things may be almost universally true for most organizations; there will be outliers where it isn’t. When defining security goals, use shortcuts judiciously and stay alert for situations where they might not tell the whole story.
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.