Technological Upheaval
Ground breaking innovations often causes some form of upheaval. Most folks are familiar with the story of Robin Hood and his band of merry men. Another group living in the Sherwood Forest area, though later around 1811, were the Luddites. These men from the past have a great deal to teach us concerning the ramifications of revolutionary technological change. The Luddites were highly skilled and quite well paid croppers (men who worked cloth). Their job was to cut the cloth after it had been raised with shears. These shears weighed 40 lb and were 4 feet long. Their world was turned upside down by the introduction of the water powered shearing frame. This new technology was simple enough that it could be operated by an unskilled worker, taking under a quarter of the time.

Luddites fought back by breaking into factories at night and destroying the new machines. In a three-week period, for example, over two hundred stocking frames were destroyed. While this may not be as exciting as Robin Hood, just as in that story the heavy hand of the government came down on the Luddites. The Frame Breaking Act made machine-breaking a capital offense. In Yorkshire in 1812, over 12,000 soldiers were brought in to keep order. Roundups of hundreds of men occurred. Some were deported to penal colonies and others were executed. At one point seventeen men were executed. In the end, the Luddites could not stop technology from advancing. By the 1820s the Luddite movement had ceased to be active and few croppers could find work in the woolen industry.

It’s All About Risk
The moral of the story is that technology does not exist in a vacuum. Not if it is useful technology. It ends up being integrated into the environment in which it operates. This integration can be peaceful, or not. Either way, it will occur. Policy based compliance tend to have policies dictating discrete, predefined information security requirements along with associated safeguards and countermeasures. There is minimal flexibility in implementation and little emphasis on explicit acceptance of mission risk. Compare that to risk based protection where the enterprise missions and business function drive security requirements, associated safeguards, and countermeasures. It is highly flexible in implementation and focuses on acknowledgment and acceptance of mission risk.

Today, organizations are taking a serious look at their information technology (IT) groups and questioning the governance models necessary to minimize risks and maximize returns. Taking the definition from the Control Objectives for Information and related Technology (COBIT) executive summary, IT governance is “a structure of relationships and processes to direct and control the enterprise in order to achieve the enterprise’s goals by adding value while balancing risk versus return over IT and its processes.”

Command and Control
Business managers and stakeholders, in order to trust and rely on IT must have some sense of reliability and control. Add to this business mix the constant pressures to decrease cost, increase reliability, and meet requirements to comply with local and federal regulations. Communication between different groups within an organization is essential, whether that be technical folks, auditors, finance, managers, etc. Innovation cannot exist only in the IT arena. It must translate into overall business process improvements. To help do this, companies are showing greater interest in best practices and in frameworks such as Information Technology Infrastructure Library (ITIL), International Organization for Standardization (ISO/IEC ) 17799, and COBIT. Government organization need to follow the DoDI 8500.2 “Information Assurance (IA) Implementation” document or National Institute of Standards and Technology (NIST) SP 800-53A “Recommended Security Controls for Federal Information Systems.”

As organizations attempt to implement these frameworks/recommendations/requirements questions concerning how to bring these standards together arise along with difficulties in helping organizations get from where the company current is to where the company needs to be? Government does not get a free pass. Government agencies are faced with the daunting task of having to work together to combat security risks. That includes federal information systems that support defense, civil, and intelligence agencies along with private sector information systems supporting U.S. industry and businesses and information systems supporting critical infrastructures within the U.S. It would be helpful if we could start talking the same language. Or at least develop a dictionary so we can understand each other. Winston Churchill once said, “Out of intense complexities intense simplicities emerge.” By bringing together the seemingly diverse security best practices and controls from COBIT, ITIL, DoDI 8500.2, and NIST SP 800-53A, we hope intense simplifications emerges.

Battle Plans
First, a little background. The Department of Defense Information Assurance Certification & Accreditation Process (DIACAP) and NIST both address the Federal Information Security Management Act (FISMA) of 2002 requirements. FISMA is a United States federal law which recognizes the importance of information security to the economic and national security interest of the United Stats. FISMA tasked NIST with the responsibility of “providing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems.” While DIACAP establishes “the standard DoD process for identifying, implementing and validating information assurance (IA) Controls for authorizing the operation of DoD information systems and for managing the IA posture across DoD information consistent with Title III of the E-Government Act, FISMA, DoDD 8500.a and DoDI 8500.2.” A major part of the DIACAP process is testing to make sure compliance with regulations occurs. The testing is based on security controls set out in DoDI 8500.2. The NIST SP 800-53A also “provides guidelines for assessing the effectiveness of security controls employed in information systems supporting the executive agencies of the federal government.” As you can see, NIST 800-53A and DoDI 8500.2 are fairly similar in definitions and methodologies.

COBIT’s original purpose was to link IT process and controls to business requirements. Management guidelines were later added, providing management tools such as metrics and maturity models. ITIL is effective IT service management focused. It consists of 10 processes, which break down into service support (operational) and service deliver (tactical) processes. ISO/IEC 17799 focuses on security and attempts to aid an organization in the creation of an effective IT security plan.

Strengths and Weaknesses
The Information Systems Audit and Control Association (ISACA) has put a great deal of effort in mapping COBIT to other standards. In part, this is because of COBIT’s focus is on business requirements. COBIT can be used as the framework and governance model under which other best practices integrate. Take a look at these mapping guides:

• COBIT Mapping: Mapping of NIST SP800-53 Rev 1 With COBIT 4.1
• COBIT Mapping: Mapping of TOGAF 8.1 With COBIT 4.0
• COBIT Mapping: Mapping of CMMI for Development V1.2 With COBIT 4.0
• COBIT Mapping: Mapping of ITIL With COBIT 4.0
• COBIT Mapping: Mapping of PRINCE2 With COBIT 4.0
• COBIT Mapping: Mapping of ISO/IEC 17799: 2005 With COBIT 4.0
• COBIT Mapping: Mapping PMBOK to COBIT 4.0
• COBIT Mapping: Mapping SEI’s CMM for Software to COBIT 4.0
• COBIT Mapping to ISO/IEC 17799:2000 With COBIT, 2nd Edition
• COBIT Mapping Overview of International IT Guidance, 2nd Edition
• Aligning COBIT, ITIL and ISO/IEC 17799 for Business Benefit

Coming Together
To keeps things somewhat simpler, let us only focus on the mappings that exist for ITIL with COBIT and NIST SP800-53 with COBIT. Through this approach, we will develop a path from DoDI 8500.2 to ITIL. The mapping should be helpful not only in understanding but also in organization. Keep in mind, DoDI 8500.2 is the catalog of controls and can be matched against NIST SP 800-53A. Appendix G of NIST SP 800-53A does match up ISO/IEC 17799 and DoDI 8500.2.

When we combines these mappings, we do begin to see both the strengths of certain standards. We also gain depth of coverage. Take a look at the following mapping for configure and implement acquired application software to meet business objectives.

The complete mapping can be found from this link. This is a work in progress and is meant only as a first attempt to produce something that might clarify and help.

Building Trust
Dr. Ron Ross, project leader for the FISMA Implementation Project, has been doing some talks on transforming the certification and accreditation process through a unified risk management framework. He also wants us to be able trust each other. One of his recent presentation from November 14, 2007 to the ACT/IAC Information Security and Privacy Shared Interest Group titled “Building Trust Relationships Among Organizations” makes some very important points. In the presentation Ross states that there is an information security paradigmatic shift occurring from a policy based compliance model to a risk-based protection model. This is of key importance because the responsibility of security to provide information will depend on a trust relationship established among partners. This is applicable to both the government and industry. Trust can occur only when an organization understands the security state of their partners. Government and industry must be able to trust and understand each other’s security state.

Michael Smith, manager in the Audit and Enterprise Risk Services organization of Deloitte & Touche LLP, makes the following important point about the unified catalog of controls in his post, “One Catalog to Rule Them All“:

What a unified catalog of controls means is that we now have something that is standardized across the board so that I can take an IA practitioner from the DoD side, put them into a civilian agency, and have a reasonable expectation that they will succeed there. In other words, I’ve decreased the switch costs for personnel transfers. I’ve also made it easier for agencies to share data with each other (conspiracy buffs here can think things about Census data feeding the Total Information Awareness program and corroborated against your classified file) and to support each other as vendors under Lines of Business, which the government needs desperately.

Eustace D. King has an article in the July issue of CrossTalk titled “Transforming IA Certification and Accreditation Across the National Security Community.” In the article King discusses the DoD and DNI CIOs seven goals for transforming C&A processes across the DoD and the IC. These goals can be found off the director if National Intelligence CIO’s “Re-Vitalizing Certification & Accreditation Initiative” page and include (quoting from King’s article):

1. Define a common set of impact levels and adopt and apply them across the DoD and IC.
2. Adopt reciprocity as the norm, enabling organizations to accept the approvals by others without retesting or reviewing.
3. Define, document, and adopt common security controls, using NIST SP 800-53 as a baseline.
4. Adopt a common lexicon, using CNSSI 4009 as a baseline, thereby providing both the DoD and IC a common language and common understanding.
5. Institute a senior risk executive function, which bases decisions on an enterprise view of risk considering all factors, including mission, IT, budget, and security.
6. Incorporate IA into enterprise architectures and deliver IA as common enterprise services across the DoD and IC.
7. Enable a common adaptable process that incorporates security within the lifecycle processes and eliminates security-specific processes.

I do like the idea of “define, document, and adopt common security controls, using NIST SP 800-53 as a baseline.”

At the last month’s Infosecurity Canada Conference & Exhibition, Al Purdy, now principal of DRA Enterprises Inc. addressed the importance of a establishing an risk management framework. “The most likely way to address some of the risks is a public-private sector collaboration based on an established risk management framework“, Purdy said. Purdy points out that the IT Governance Institute (ITGI), developers of COBIT is reported working on a risk management framework for release later this year. Herr Urs Fischer, who is leading a steering committee that is developing the framework, admits, “While COBIT does contain some discussion of risk management, ITGI realized that it needed to provide more depth and guidance as technology professionals struggle with issues around compliance with regulations such as Basel II.” Fisher goes on to say, “It’s more of an add-on (to COBIT) than a new one.” Fisher explains, “It’s not a checklist. It’s more about the way you should do risk management.”

Parting Words
I started this post wondering if a shift is beginning towards the risk-based protection model. We see elements in play. There is a definite need for establishment of a common language between all our standards, best practices, and requirements. Recent research published in the IT Governance Global Status Report 2008 found a six percent increase from 2005 in the importance of IT to business strategy. IT is increasingly playing a more vital role in business and government. Help is needed that will allow different groups within an organization to understand IT. This need to communicate goes beyond the boundary of an organization. Governments and industry need to properly be able to evaluate the risk of working with their partners and they can only do this if they can evaluate their partner’s security readiness. Partnerships do not end within one’s own country. It is not surprising to see the push for a common risk management framework.

Jacob August Riis, an Danish-born American journalist and slum reformer who created new standards in civic responsibility regarding the poor and homeless in his reporting of New York City slum conditions, once wrote, “When nothing seems to help, I go and look at a stonecutter hammering away at his rock perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that blow that did it, but all that had gone before.” Sometimes the hands of change seem to move at glacial speeds, but change will come. When all the elements are in place, change can come like a flash flood. The best we can do is be patient and then make sure we are not caught like the Luddites, on the wrong side of technological advancements.

Special Thanks
I wanted to add a note of special thanks to Michael Smith over at the Guerilla CISO. Michael is quoted above. I have been a long time reader of Michael’s blog and when I came across questions concerning DIACAP, I dropped him an email. He was most helpful and informative with his responses, shared with me some pdfs, and pointed me to some great sites. If you want to know more about Michael, Martin McKeay did an interview with him a few months back. Of course, any mistakes in this post are my own, and the correct information is due to the help that Michael provided.