Information Security Today Home
IT Auditing and Sarbanes-Oxley Compliance: Key Strategies for Business Improvement
ITIL Release Management: A Hands-on Guide
How to Achieve 27001 Certification: An Example of Applied Compliance Management
Complete Guide to Security and Privacy Metrics: Measuring Regulatory Compliance, Operational Resilience, and ROI
ITIL: Service Management Implementation and Operation

Leveraging IT Control Frameworks for Compliance

Todd Fitzgerald

A variety of laws and regulations have surfaced over the past decade in an attempt to strengthen the security of information stored within the companies to which the information assets are entrusted. As a result of the laws and regulations, various security control "standards" and "frameworks" have evolved and become popular means to meet the requirements of the laws. Because laws and regulations are intentionally developed at a higher, "what needs to happen" level vs. the "how to secure the information" level, the standards and control frameworks become valuable tools to ensure that security is planned, organized, implemented, tested, and monitored.

Governance, risk, and compliance (GRC) is a term that has been embraced primarily by the vendor community in recent years in recognition of the fact that companies are struggling with the plethora of controls that must be implemented to meet the extensive requirements of the laws and regulations. Governance is simply the structure, policies, and practices that are put in place by the organization to ensure that the controls are adequately communicated, carried out, and enforced by engaging direction and support at the appropriate organizational level. Risk is the act of making informed decisions about the losses that the company is willing to accept given a breach of security and building the appropriate mitigating risk strategies to reduce the risk to acceptable levels defined by the business. Compliance is ensuring that the controls are being adhered to on an ongoing basis, thereby increasing the likelihood of a reduction of risk and increased adherence to the governance intended by the organization.

The three components of GRC are necessary for adequate security controls; however, implementing them does not ensure that a security program is adequate. Compliance is a necessary control that has been recognized by governments for centuries. Criminal acts, by their very nature, are forms of noncompliance with the laws that are in place. Take driving a car for example. As a teenager obtains his driver's license, the diligent parent warns about the downside of not following the laws, reckless driving, speeding, and paying attention to parking and vehicle regulations. The teenager says, "Sure dad, no problem" and forgets five minutes later as he morphs into his busy teenage social network of friends and peer pressure, away from the constant parental reminders. He does not realize at the time the consequences of his actions. Or, maybe he does subconsciously, but it is not the most important thought in his daily "work life." Time goes on, piling up speeding tickets, tickets for excessive window tinting, unpaid parking tickets  until one day, he has the opportunity to pay his own car insurance! The parent at that point transfers the risk to the child, and then the learning of true cost of noncompliance begins. The risk is ultimately acknowledged and accepted, and new mitigating strategies are put in place, such as better driving. Organizations are made up of many busy "teenagers," each of which is influenced by his peer work groups and needs to be educated as to the future costs of noncompliance to the security controls. Adopting a control framework is a good start; however compliance must be addressed as an ongoing, deliberate strategy.

So, What Are The Control Frameworks?

Control frameworks and security standards are often interchangeable terms depending upon the creator. Just to confuse things further, ISO27001 posits an Information Security Management "system" (ISMS) and the controls are contained within the ISO27002 "Code of Practice." The National Institute of Standards and Technology (NIST) Special Publication 800-53, entitled Recommended Security Control for Federal Information Systems, breaks the controls into 17 control "families" and three "classes" (Managerial, Operational, Technical) of controls. COBIT defines a framework the same as a Control Framework, which is defined as a tool for business process owners that facilitates the discharge of their responsibilities through the provision of a supporting control model. Alternatively, COBIT defines a standard as a business practice or technology product that is an accepted practice endorsed by the enterprise or IT management team.

For the purposes of this discussion, control frameworks, controls, and standards are interchangeable, as the "intent" of each of them is to provide some definition to a practice or set of practices that if performed, will protect the organization's information assets. These consist of documented, executed, tested, implemented, and monitored controls which reduce the risk of threats succeeding against the company vulnerabilities.

The following are some examples of the control frameworks and standards that address information security requirements:

Health Insurance Portability and Accountability Act (HIPAA): The final rule for adopting security standards was published in February 20, 2003, which required a series of administrative, technical, and physical security procedures for entities to use to assure the confidentiality of Protected Health Information (PHI). The standard was intentionally non-technology specific and intended to provide scalability to small providers and large providers alike.

Federal Information Security Management Act of 2002 (FISMA): The primary purpose is to provide a comprehensive framework for ensuring the effectiveness of security controls over information resources that support federal operations and assets. The law also provided funding for NIST to develop the minimum necessary controls required to provide adequate security. The government publishes an annual report card based upon their assessment of compliance with the framework.

National Institute of Standards and Technology (NIST) Recommended Security Controls for Federal Information Systems (800-53): The standards and guidelines reference the minimum set of controls that must be implemented to protect the federal system based upon the risk level determined. Implementation of the 17 families of security controls establishes a level of "security due diligence" for the federal agencies and the contractors which perform work for the government. These standards are very comprehensive, freely available, and an excellent resource to supplement the other control frameworks.

Federal Information System Controls Audit Manual (FISCAM): Issued by the General Accounting Office, this provides guidance for Information Systems auditors to evaluate the IT controls used in support of financial statement audits. This is not an audit standard, but is included here because auditors are typically testing the control environment in government audits using this standard. There has been increased emphasis on the use of NIST 800-53 controls and the NIST 800-53A Assessments, however FISCAM is still utilized by government auditors and, therefore, it is worthwhile to understand the contents.

ISO/IEC 27001:2005 Information Security Management Systems Requirements: Provides a model for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an ISMS. This was an evolution from British Standard BS7799-2 and ISO17799.

ISO/IEC 27002:2005 Information Technology Security Techniques-Code of Practice for Information Security Management: Provides 11 security control clauses (Security Policy, Organizing Information Security, Asset Management, Human Resources Security, Physical and Environmental Security, Communications and Operations Management, Access Control, Information Systems Acquisition, Development and Maintenance, Incident Management, Business Continuity Management, and Compliance). The code of practice specifies the controls necessary and the implementation guidance by specifying the controls that may be chosen to build the ISMS specified through application of ISO/IEC 27001:2005.

Control Objectives for Information and Related Technology (COBIT): A framework and supporting toolset that allow managers to bridge the gap with respect to control requirements, technical issues and business risks, and communicate that level of control to stockholders. COBIT can be used to integrate other standards as an umbrella framework. COBIT gained increasing popularity through implementation to demonstrate compliance with Sarbanes-Oxley regulations, which were enacted in 2002 to require management and the external auditor to report on internal controls over financial reporting.

Payment Card Industry Data Security Standard (PCI DSS): A set of comprehensive requirements for enhancing payment account security, formed by several major credit card issuers, to facilitate the broad adoption of a comprehensive security standard.

Information Technology Infrastructure Library (ITIL): ITIL is a set of books published by the British government's Stationary Office between 1989 and 1992 to improve IT service management. The framework contains a set of best practices for IT core operational processes such as change, release and configuration management, incident and problem management, capacity and availability management, and IT financial management. ITIL's primary contribution is showing how the controls can be implemented for the service management IT processes.

Security Technical Implementation Guides (STIGS) and National Security Agency (NSA) Guides: Configuration standards for Department of Defense Information Assurance, however freely available and used as the basis for technical standards for many private organizations. These standards, if implemented, support many of the high-level requirements specified within requirements such as FISMA, HIPAA, PCI, NIST, GLBA, COBIT, ISO27001, etc.

The World Operates on Standards
The obvious fact about standards is that they are useful and the world is made up of many of them, from the minimum weight in the passenger seat that must be met before the airbag protection will become active, to the specification of the size of a #8 screw, to the standard formats for electronic data interchange of electronic transactions between healthcare providers, payers, and clearinghouses.

Standards ensure that products are built to specifications and allow us to "simplify" the complexity of the world by creating a common deliverable and common language. Imagine if every time a manufacturer wanted a product built they had to design a screw that could be potentially different from any other screw a manufacturer created! Not only would this process be very expensive, it would also be very time consuming for the customer and the supplier, and would be very error-prone. Non-standardized processes also slow down the delivery of the product or service.

Henry Ford recognized many years ago that there were efficiencies and increases in quality by creating vehicles which looked the same and were painted the same color (black). While they were actually available in other colors, the primary color produced was black for efficiency. Imagine if stoplights were each made with different colors to represent stop-slowdown-go. Imagine roadways that used different types of striping to indicate passing vs. non-passing lanes based upon the state that you lived in! The world would be very chaotic with each individual interpreting the colors and passing lanes as they drove, many times potentially making the wrong decision.

Sometimes we like the standards, sometimes we do not. Sometimes, they just do not make intuitive sense to us, nor do they seem effective. For example, the Transportation Security Administration (TSA) originally did not allow nail clippers on the airplane, and reversed the decision in 2005 after negative public opinion. Lighters were also subsequently allowed in July, 2007 by the Federal Aviation Administration. Laws, regulations, and the standards that support them are sometimes developed without the extensive analysis of their necessity, or in reaction to a major event and the need to "do something," only to be rescinded later for their lack of effectiveness. This is understood, as government and private industry must react to make demands and situations, making decisions on the data available at the time. In defense of the TSA, decisions to limit what was brought on an airplane had to be made quickly on the heels of September 11, 2001, and their focus was on objects which had the potential to harm. Thus, the standard of "no nail clippers" was enacted. Liquid restrictions were placed on travelers due to an incident where the chemicals could be used to create explosives. By the time of this publication, due to new technology scanning, the "no liquid" standard may also disappear.

Standards Are Dynamic
Over time, the standards evolve, and they change to meet the societal and technological needs. While the intent of many security standards appears to stay the same over time, the underlying technologies that must be supported are constantly changing. Just as in the "no liquids" on airplanes were first introduced, and then evolved into "as long as the liquids are 3oz or less and fit in a 1qt baggie," and then may morph into "no requirements at all" due to investments in more advanced scanning technology, information security standards also need to change.

Most control frameworks are written at a higher, broader level, which provides flexibility to implement controls to satisfy the specific technological request. For example, the ISO27002:2005 Information Technology Security Techniques (Code of Practice) control 10.5.1d indicates that "the back-ups should be stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site." This leaves much interpretation up to the implementer of the standard-how far away is far enough? Before Hurricane Katrina inflicted extensive damage on New Orleans, Louisiana, and other surrounding areas in 2005, many individuals felt that storage a few miles away was sufficient. Today, when companies are assessing their business continuity plans, they typically point to Katrina, and quickly decide that 50-100+ miles away would greatly reduce the risk. Others have invested in new replication technologies and the availability of inexpensive storage to ensure availability of the information.

Changing environments necessitate the ability to change the implementation strategies to meet the lower cost of technology, increased effectiveness of controls, and conformance to emerging regulations.

The "How" Is Typically Left up to Us
As the aforementioned example illustrates, the good news is that the standards may be written to be flexible over time. The bad news is that they are written to be flexible over time. In other words, standards often lack the specificity of the "how" that would be useful to implementing the standard. Obviously, this is by design; however, it leaves the implementer of the standard to "figure out" based upon the available alternatives what the best method of implementation should be for their particular environment and cost constraints.

The "best practices" terminology has received criticism over the past several years, as the beauty is in the eye of the beholder. A practice that works for one organization may not fit for another. One organization may implement a policy banning USB drives due to their small size, while another may allow them as long as the contents are automatically encrypted with the company-approved software. Still another may prohibit their use by policy to most users, but allow adoption by those which establish a business need (as specified in ISO27002:2005 10.7.1f), as well as taking the additional step of controlling access through active directory authorization and a vendor product. Which is the "best practice"? It depends on the organizational culture, appetite for risk, cost constraints, etc. It may also be the case that the individuals within the organization do not have access to sensitive information, thus limiting the exposure.

Therefore, the "best practice" for an organization must take in many factors not defined within the individual standard. Typically, an organization would be prudent to follow the trends within their particular vertical industry, and pay attention to what the "herd" is doing. If 70% of the sheep are heading for the hills, it may be worth heading in that direction. It is also important to understand why, as the 10% going another direction (assuming 20% are standing still), may be headed to a better best practice. In the tape backup example, maybe the 10% that are utilizing online, high-speed compressed disk-to-disk backup strategies are the "best practice" that is right for the organization.

Whatever these practices are named for our individual organizations, each must recognize that the practices must satisfy the standard and where they do not, sufficient business justification and risk acceptance must be documented. In this manner, the standards become the reference point for making informed business decisions.

Key Question: Why Does the Standard Exist?
Before deciding the "how" to implement the standard, it is a useful exercise to examine the selected control within the standard and analyze why does this control exist in the first place? What threat is it addressing? What would the risk be to my organization if I decided to ignore addressing the control? In other words, how is implementing the control increasing the security, protection, or information assurance of the information assets within the organization? Understanding the "what if I don't" can quickly lead to a deeper understanding of the "intent" of the control, vs. trying to ensure compliance with every detail of the control.

For example, if there is a control within the standard which says that logs of activity to the system must be retained for 1 year, access must be restricted to only those with a need to know, understanding why this standard exists will contribute to "how" it should be implemented. If the intent of the control is to be able to go back and analyze incidents, then the individuals who need read access are the systems security operations team, or those responding to the incidents. The files may also need to be online if there is a frequent occurrence of investigation. Alternatively, the logs may not be able to be reviewed due to resource (human) constraints, and may necessitate the investment in a security incident management tool which aggregates and correlates the information.

Understanding the intent of the control also assists in interpreting the terminology used within the control. The standards are promulgated by many different organizations, committees, and geographic representations. The NIST uses terminology in the 800-53 standard (Recommended Security Controls for Federal Information Systems) with roots in the Government Sector that would be familiar to many accustomed to working for or contracting with government agencies. Contrast that with the IT Governance Institute's COBIT framework that is reviewed by an internationally represented committee.

Compliance Is Not Security But It Is a Good Start
Checking off each of the controls specified within a standard is analogous to completing the weekend honey-do list at home it may be "done" at the end of the weekend, but wait for the household auditor to see if it was done "well." When the Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLBA), Federal Information Security Management Act (FISMA), Payment Card Industry Data Security Standards (PCI), and other regulations arrived on the scene, some organizations reviewed the "Compliancy with the standard" as the primary goal, and subsequently created a checklist approach to satisfying the controls with the minimum that would be needed for "compliancy," without the benefit of a real risk assessment.

The danger in this is that the security controls implemented may prove to be ineffective to addressing the vulnerabilities of the organization and the threats that they face. However, even though compliance with standards may not be sufficient to mitigate the risk level to an acceptable level for the organization, the fact that the organization is adopting a control framework provides the opportunity to create a baseline and enhance the security level over time. Without such a framework in place, there is less chance that the environment will be secure, as items can be missed too easily.

Integration of Standards and Control Frameworks
Each of the standards and control frameworks contributes in their own way and the astute security professional will become familiar with each of them. COBIT provides an excellent overall framework that ties business goals, governance drivers, business outcomes and IT resources, processes, and goals together. ISO27001 provides a nice framework for establishing the ISMS, ensuring that risks are assessed, controls are implemented, management is actively involved, and the documentation is up to date. NIST 800-53 provides the detailed controls with tailored enhancements with the specifications for assessing the controls (800-53A document). HIPAA Final Federal Security Rule provides the framework for implementing protection for the Healthcare vertical industry. The Federal Information Security Management Act (FISMA) relies on the controls specified by NIST to comply with the regulation instead of creating a new set of controls. The ITIL provides the control areas for providing effective and efficient service delivery, and overlaps the security areas specified in the other control areas.

Several organizations, such as NIST and the IT Governance Institute have recognized the commonality of these standards as evidenced by their work in mapping controls between HIPAA, NIST 800-53, COBIT, FISMA, ITIL, and others. While the wording, level of the control, and measures for assessment may have different criteria, there is much commonality amongst the controls. For example, controls regarding configuration management and the need to develop baselines may not be specifically called out in HIPAA and FISMA as they are in ISO27001 and NIST, however, the need for securing the computing devices are represented within the controls for technical controls and the implementation of systems security plans.

Value of Audits
Once a control framework or set of standards has been chosen and implemented, it is imperative that the framework be audited on a regular basis internally and externally. Gaps in process are typically uncovered during these audits, and if these gaps are mitigated quickly, over time, the security program becomes more complete. Care must be taken to address reasonable risk, as it is rare that an organization will execute every control every time. What is important is that there are mitigating or compensating controls that catch the anomalies before they become major issues, and prompt follow-up and correction actions are taken. Audit testing of the control frameworks will take many forms including interviewing, determining, and testing samples; performing vulnerability assessments; reviewing policies and procedures; and conducting external penetration tests. Each audit should be viewed as an opportunity to determine the effectiveness of the control framework and potentially modify the existing controls.

Final Thoughts: Control Framework Convergence
Why cannot we have just one standard? On the surface, this appears to be a simple, logical question. As Eckhart Tolle promotes in his book, A New Earth, individuals create stress in their lives by not accepting "what is." The reality is that laws and regulations will continue to emerge from different organizations and as security professionals, adapting to the emerging laws and regulations and applying the appropriate standards and control frameworks will be key. This is not to say that efficiencies cannot be gained, as controls can be implemented which would support multiple control frameworks. Sometimes, a control only needs to be tweaked to satisfy multiple controls/standards.

Over time, the practices that are common do emerge and become generally accepted. Even as recent as a few years ago, laptops were not universally encrypted by companies, with IT departments citing the expense, complexity, lack of necessity, files stored on the network by company policy, etc. So what was the tipping point that changed the practice to companies encrypting the laptops? It was when the veteran's administration lost a laptop containing information on 26.5 million veterans in 2006 which caused public outrage at the situation. Today, few companies would want to admit that they are not encrypting their laptops due to the shift in the herd mentality to encryption. The sheep have headed for the hills, and the slow sheep are vulnerable to being left behind.

Upon reviewing the standards and control frameworks, it is clear that the requirements for protecting "mobile devices and media" were specified prior to 2006. It could be argued that proactive attention to these frameworks would save much in the long run. The Veterans Administration suffered in terms of public reputation and financially ($20 million lawsuit to settle claims), all which could have been avoided. What happened to this government agency could happen to any of our organizations if the controls are not in place. Adherence to the control frameworks and standards increases the likelihood that breaches will not have a devastating effect on the confidentiality, integrity, or availability of the information assets.

Control frameworks and standards provide the roadmap to build a successful information security program. Once in place, continuous review of the policies, standard operating procedures, and implementation of the controls will enhance the effectiveness of the program. Monitoring through audits accompanied by corrective actions and tracking enables refinement of the control framework and standards to reduce the risk of a security event impacting the business in a significant way. Think of the various security control frameworks as each contributing in some way to the infrastructure of a super 6-lane freeway. Rather than managing your security programs by yourself, on an old gravel road at 20 miles per hour, it is time to get on the superhighway supported by the strong plethora of control frameworks and standards and enjoy the ride!

Related Reading

Compliance Frameworks

Why Are Information Technology Controls and Audit Important?

Ten Steps to Sarbanes-Oxley Compliance

From Logs to Logic: Best Practices for Security Information Management

Creating a Culture of Compliance: The Responsibility of Every Member of an Organization

About the Author

Todd Fitzgerald, CISSP, CISA, CISM, is the director of systems security and systems security officer for United Government Services, LLC, Milwaukee, Wisconsin.
This chapter is from Information Security Management Handbook, 2010 CD-ROM Edition edited by Harold F. Tipton. New York: Auerbach Publications, 2008.
Subscribe to Information Security Today

Powered by VerticalResponse

© Copyright 2010 Auerbach Publications