This is the final article in SearchSecurity.com's Information Security Governance Guide.
Developing an information security program to establish information security governance can be a Herculean task, depending on the security team's experience and know how. Fortunately, there are time-tested frameworks available to help.
Different organizations, consulting companies and information security professionals follow different approaches to setting up an information security program. Many organizations follow the ISO 17799 approach or morph it to fit their organization's specific needs. Another approach is called the Sherwood Applied Business Security Architecture (SABSA).
What is interesting about the SABSA model is that it slices an enterprise into different layers so that security can be more focused and precise. The model is made up of six layers, as shown below. Each layer represents a different view of the organization and the types of security controls that need to be put into place.
The SABSA model follows the Zachman Framework, which has been around for some time. The Zachman Framework breaks down an enterprise architecture into discreet and manageable components. The SABSA model also uses the same types of questions as the Zachman Framework to help people who are responsible for developing and deploying an information security program:
- What are you trying to do at this layer? – The assets to be protected by your security architecture
- Why are you doing it? – The motivation for wanting to apply security, expressed in the terms of this layer
- How are you trying to do it? – The functions needed to achieve security at this layer
- Who is involved? – The people and organizational aspects of security at this layer
- Where are you doing it? – The locations where you apply your security, relevant to this layer
- When are you doing it? – The time-related aspects of security relevant to this layer
The difference between ISO 17799 and SABSA is the focus and granularity. The ISO standard is security oriented, high-level and provides vague best practices that can be used to help determine what should be in a security program. SABSA is more business process oriented and detailed oriented because it dissects an organization and allows you to understand what needs to happen at each layer.
For example, ISO 17799 provides guidelines on what an organization should do as it pertains to personnel security. It gives broad stroke advice on the major components that should be in any personnel security program within an organization, as in screening, confidentiality agreements, conditions of employment, job descriptions, user training, etc. This ISO standard provides this type of broad stroke advice for each of the following silos of an information security program:
- Security policy
- Organizational security
- Asset classification and control
- Personnel security
- Physical and environmental security
- Communications and operations management
- Access control
- System development and maintenance
- Business continuity management
- Compliance
SABSA does not work in this construct of individual silos. It approaches all of these security issues through the specific levels of an organization that were laid out in the previous figure. Let's walk through an example using access control. ISO 17799 lists the components that should be in an access control program (user registration, password management, node authentication, event logging, etc.) Instead of listing what should be in these individual silos, SABSA looks at access control through the following perspectives:
- Contextual – Business risks for not practicing access control, compliance requirements as they pertain to access control, level of access control that is required to meet business objectives
- In the context of our company, how should we practice access control?
- Conceptual – Access control program design construction and goals
- What does our access control program need to look like, and what are we trying to accomplish?
- Logical – Components of the access control program (password management, user registration, monitoring, least privilege, separation of duties)
- What pieces and parts are going to make up our access control program?
- Physical – Specifications and processes of the access control program (password standards, user registration process steps, what is monitored and how, specifications of what duties need to be separated)
- What are the necessary standards, procedures, baselines and process steps that the parts of our access program need to follow?
- Component – Products and tools that support and enforce the access control program (password management tool, identity management product, user registration product, monitoring tool)
- What products, tools and personnel will we use in our access control program?
- Operational – Products and processes are maintained
- Who is going to maintain our access control program and how?
The SABSA model uses different roles that work with these different perspectives:
- Business owner = Contextual
- Architecture = Conceptual
- Designer = Logical
- Builder = Physical
- Tradesman = Component
- Facilities Manager = Operational
This is a similar approach as software development. Someone at a software company uncovers a business need to develop a specific software product. (Business owner) The next group gets more granular and develops the necessary functionality of this product that their customer base would require. (Architecture) The next group gets more granular and develops the overall, high-level design for this product. (Designer) The next group gets more granular and develops the technical specifications of the product. (Builder) The next group gets more granular and develops the actual software code for the product. (Tradesman) And the next group configures and maintains the product. (Facilities Manager).
Now, if you are new to security and what is actually required in a security program, this model and approach may make you bleed from the ears. It all depends upon your level of experience and knowledge of security in the first place. If a company is just trying to figure out what should be in its security program, then it should start with ISO 17799. This standard will hold your hand and state, "You need building block A, you need building block B, you need building block C, etc." But as stated before, many if not most companies have many of the building blocks in place, but that does not mean they have security governance. Security governance is the threads that expand and connect all of these building blocks and allow the security program to work as a living organism throughout all of the departments of a company.
If a company has its security building blocks in place, it can evolve past ISO 17799. If the company would like a holistic approach of how to actually integrate security through out the whole enterprise at the different levels, then it can look to the SABSA model.
There is no doubt that the SABSA model is theoretical and academic in nature, which means that it can be difficult for many in the security field to understand and use. But most people in our industry are not accustomed to working from an architectural level down to the component level. Our industry came from technology, so most security professionals only work the Physical, Component and Operational levels.
If a security program is only made up of Physical, Component, and Operational mechanisms, there is no way that security governance is in place. Security governance requires all levels to be working in concert.
Please also remember that the ISO 17799 and SABSA are frameworks that provide guidance. You can use them as starting places to develop your own approach for developing and implementing a security program. If you choose to implement the SABSA model, maybe you don't need six full layers or maybe your organization needs seven layers. Although many people in our industry are not ready to understand and implement the SABSA model, it (or something like it) is where we are going as our need to integrate security into business processes increase, and as governance and oversight is demanded from laws and regulations. If you still need to get your head around ISO 17799, don't look at SABSA. If you understand and have implemented ISO 17799 (or something close) read the book Enterprise Security Architecture, which describes the SABSA model. Don't try and implement it the next day, think about it for a while and ponder how it can help your organization and know that it is just a framework and it is up to you to decide which pieces and parts work for your organization.
Information Security Governance Guide
What is information security governance?
Key elements when building an information security program
Steps in the security program life cycle
Developing an information security program using SABSA, ISO 17799
About the author:
Shon Harris is a CISSP, MCSE and President of Logical Security, a firm specializing in security educational and training tools. Shon is a former engineer in the Air Force's Information Warfare unit, a security consultant and an author. She has authored two best selling CISSP books, including CISSP All-in-One Exam Guide, and was a contributing author to the book Hacker's Challenge. Shon is also the co-author of Gray Hat Hacking: The Ethical Hacker's Handbook.
