Lucky for me, and the rest of the business world, other really smart people have already sorted this stuff out and created best practices, frameworks, and architectures. Organizations like NIST, ISO, and DoD have published and maintain extensive documents on what should be considered when developing a security plan, and how to go about implementing it.
Before we get too far, let's discuss the differences between security frameworks, enterprise architectures, and security controls.
Security Frameworks
A security framework is the highest-level of abstraction when it comes to creating a comprehensive security program. The analogy used in the book is that the framework is like what type of house you want (ranch, 3 BR, 2BA). Security frameworks offer general guidelines on how a business should address various topics such as Information Systems Management Solution (ISMS) requirements, ISMS implementation, Network Security, Outsourcing Security, and many more.
The most widely used security framework is the ISO/IEC 27000 series.
Enterprise Architectures
The next level down is the enterprise architecture. The goal of the enterprise architecture is to map and diagram the entire organization and consider it's security needs based on how data and processes move throughout the organization. Rather than implementing point solutions, which only address problems as they arise in one place, the enterprise architecture aims to provide consistent security solutions throughout the organization. It also helps to show how changes in one area, can affect another area. Continuing the house analogy, the enterprise architecture is the architecture layout of the house (floors, walls, ceilings).
Common enterprise architectures include:
- Zachman Architecture Framework
- The Open Group Architecture Framework (TOGAF)
- Department of Defense Architecture Framework (DoDAF)
Security Controls
Moving to a more granular level, we now come to security controls. These are more specific guidelines on how to actually implement various controls. For instance, where the high-level framework may simply say that unauthorized access should not be permitted, the security controls guide will give more specific processes for meeting this objective such as:
- Using unique user IDs
- Checking that a user has authorization to access the requested service or information
- Maintaining a record of persons registered to use a service
In a way, the security controls guide provides a checklist of things that should be accomplished in order to meet a higher objective. In the house analogy, controls are the specifications and code that needs to be met for safety (electrical, construction, fire).
Major security control development platforms include:
- Control Objectives for Information and related Technology (CobiT)
- NIST 800-53 (developed by the U.S. government)
- Committee of Sponsoring Organizations (COSO)
Please note that there are differences between all of these various frameworks, architectures, and controls. If there weren't, we wouldn't have them. Discussing these differences is outside the scope of this post, however. The important thing is that there is common ground between each, and that is what I'm more concerned with.
One more thing
There is one more thing that fits into this overall picture of developing a comprehensive security program. That is blueprints. Blueprints are documents that security professionals develop to show the processes and components involved to meet a security objective. Blueprints lie somewhere between the enterprise architecture and the security controls. In the house analogy blueprints are the different components of a house (window types, security system, plumbing). Blueprints are important because they can be used across various business units to understand how something, such as user authentication, should be implemented. This helps provide a cohesive and consistent approach to security.
No comments:
Post a Comment