RISK MANAGEMENT STRATEGIES
Developing an information security program using SABSA, ISO 17799
Shon Harris
11.22.2006
Rating: -4.29- (out of 5)
|
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.
[IMAGE]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:
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
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
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:
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:
Conceptual – Access control program design construction and goals
Logical – Components of the access control program (password management, user registration, monitoring, least privilege, separation of duties)
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)
Component – Products and tools that support and enforce the access control program (password management tool, identity management product, user registration product, monitoring tool)
Operational – Products and processes are maintained
The SABSA model uses different roles that work with these different perspectives:
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.
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.
|
|
Rate this Tip
|
To rate tips, you must be a member of SearchSecurity.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
