This chapter is from the book
This chapter is from the book
This chapter is from the book
System Validation
No system or architecture will ever be completely secure; there will always be a certain level of risk. Security professionals must understand this risk and be comfortable with it, mitigate it, or offset it to a third party. All the documentation and guidelines already discussed dealt with ways to measure and assess risk. These can be a big help in ensuring that the implemented systems meet our requirements. However, before we begin to use the systems, we must complete the two additional steps of certification and accreditation.
Certification and Accreditation
Certification is the process of validating that implemented systems are configured and operating as expected. It also validates that the systems are connected to and communicate with other systems in a secure and controlled manner, and that they handle data in a secure and approved manner. The certification process is a technical evaluation of the system that can be carried out by independent security teams or by the existing staff. Its goal is to uncover any vulnerabilities or weaknesses in the implementation.
The results of the certification process are reported to the organization’s management for mediation and approval. If management agrees with the findings of the certification, the report is formally approved. The formal approval of the certification is the accreditation process. Management usually issues this in a formal, written approval that the certified system is approved for use and specified in the certification documentation. If changes are made to the system, it is reconfigured; if there are other changes in the environment, a recertification and accreditation process must be repeated. The entire process is periodically repeated in intervals depending on the industry and the regulations they must comply with. As an example, Section 404 of Sarbanes-Oxley requires an annual evaluation of internal systems that deal with financial controls and reporting systems.
Governance and Enterprise Architecture
Information security governance requires more than certification and accreditation. Governance should focus on the availability of services, integrity of information, and protection of data confidentiality. The Internet and global connectivity extend the company’s network far beyond its traditional border. This places new demands on information security and its governance. Attacks can originate from not just inside the organization, but anywhere in the world. Failure to adequately address this important concern can have serious consequences.
Security and governance can be enhanced by implementing an enterprise architecture (EA) plan. The EA is the practice within information technology of organizing and documenting a company’s IT assets to enhance planning, management, and expansion. The primary purpose of using EA is to ensure that business strategy and IT investments are aligned. The benefit of EA is that it provides a means of traceability that extends from the highest level of business strategy down to the fundamental technology. EA has grown since first developed it in the 1980s; companies such as Intel, BP, and the United States government now use this methodology. One early EA model is the Zachman Framework. It was designed to allow companies to structure policy documents for information systems, so they focus on Who, What, Where, When, Why, and How, as shown in Figure 5.8.
)
Figure 5.8. Zachman model.
Federal law requires government agencies to set up EAs and a structure for its governance. This process is guided by the Federal Enterprise Architecture (FEA) reference model. The FEA is designed to use five models:
- Performance reference model—A framework used to measure performance of major IT investments.
- Business reference model—A framework used to provide an organized, hierarchical model for day-to-day business operations.
- Service component reference model—A framework used to classify service components with respect to how they support business or performance objectives.
- Technical reference model—A framework used to categorize the standards, specifications, and technologies that support and enable the delivery of service components and capabilities.
- Data reference model—A framework used to provide a standard means by which data can be described, categorized, and shared.
An independently designed, but later integrated, subset of the Zachman Framework is the Sherwood Applied Business Security Architecture (SABSA). Like the Zachman Framework, this model and methodology was developed for risk-driven enterprise information security architectures. It asks what, why, how, and where. More information on the SABSA model is at http://www.sabsa-institute.org/.
The British Standard (BS) 7799 was developed in England to be used as a standard method to measure risk. Because the document found such a wide audience and was adopted by businesses and organizations, it evolved into ISO 17799 and then later was used in the development of ISO 27005.
ISO 17799 is a code of practice for information security. ISO 17799 is written for individuals responsible for initiating, implementing, or maintaining information security management systems. Its goal is to help protect confidentiality, integrity, and availability. Compliance with 17799 is an involved task and is far from trivial for even the most security conscious organizations. ISO 17799 provides best-practice guidance on information security management and is divided into 12 main sections:
- Risk assessment and treatment
- Security policy
- Organization of information security
- Asset management
- Human resources security
- Physical and environmental security
- Communications and operations management
- Access control
- Information systems acquisition, development, and maintenance
- Information security incident management
- Business continuity management
- Compliance
The ISO 27000 is part of a family of standards that can trace its origins back to BS7799. Organizations can become ISO 27000 certified by verifying their compliance to an accredited testing entity. Some of the core ISO standards include the following:
- 27001—This document describes requirements on how to establish, implement, operate, monitor, review, and maintain an information security management system (ISMS). It follows a Plan-Do-Check-Act model.
- 27002—This document was originally the BS7799 standard, then was republished as an ISO 17799 standard. It also describes ways to develop a security program within the organization.
- 27003—This document focuses on implementation.
- 27004—This document describes the ways to measure the effectiveness of the information security program.
- 27005—This document describes risk management.
You can find out more about this standard by visiting the ISO/IEC 27002:2005 website (http://tinyurl.com/8feso97).
One final item worth mentioning is the information technology infrastructure library (ITIL). ITIL provides a framework for identifying, planning, delivering, and supporting IT services for the business. ITIL presents a service lifecycle that includes
- Continual service improvement
- Service strategy
- Service design
- Service transition
- Service operation
True security is a layered process. Each of the items discussed in this section can be used to build a more secure organization.