If SOX, PCI, and COBIT are acronyms you have heard but don't truly understand, here's a primer on what they mean and how they apply to your organization.
Editor's note: This article has been extracted from the white paper "Laws and Regulations and Standards…Oh My!" available for free download at the MC White Paper Center.
When you look at all of the laws, regulations, and standards that drive security and compliance requirements, your head can start to swim.
First let's define two terms: information security and compliance.
- The generally recognized definition of information security is protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction.
- According to Merriam-Webster, compliance is conformity in fulfilling official requirements.
Keeping these definitions in mind, let's see how these laws, regulations, and standards either drive or contribute to information security and compliance within your organization.
Payment Card Industry (PCI)
Every organization that stores credit card information has heard of the PCI's Data Security Standard (DSS). In 2006, Visa, MasterCard, American Express, Discover, and JCB formed the PCI Security Standards Council and, with minor changes, adopted the Visa PCI standard and made it the PCI Data Security Standard. The Council has turned into a consortium that includes security experts, vendors, and others interested in keeping cardholder data secure.
PCI DSS has to be interpreted for each operating system and technology to which it's being applied. For example, rather than specifically list the settings for an AIX system running an Oracle or DB2 database, it states that access to cardholder data be "deny by default." And, like the ISO standards, the DSS is very broad, addressing the need for an information security officer, a security policy, network security, access controls, encryption, application development security standards, testing, monitoring, incident response, and regular security assessments. The PCI DSS provides a good example of one industry's view of security best practices.
Security Isn't a One-Time Event
While compliance with PCI has caused cardholder data in most organizations to be less vulnerable, several high-profile thefts (Hannaford and Heartland Systems) have shown that PCI compliance is not sufficient in all cases to ensure the security of cardholder data. The intent of the ISO 27000 series is to establish a model for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an information security management system (ISMS). In other words, security management is not a one-time event. Security management is a process. Part of the ISO standard addresses the discovery of flaws and the need to continually seek ways to improve the security posture of the organization.
ISO 27001 addresses all parts of the organization: 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, and compliance. Only 27001 and 27002 have been published. The others are placeholders for topics such as ISMS implementation (27003), information security management and metrics (27004), information security risk management (27005), and guidelines for organizations offering accreditation (27006).
Control Objectives for Information and related Technology (COBIT)
Control Objectives for Information and related Technology (COBIT) is a set of best practices for information technology (IT) management. It was created by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI) in 1996. COBIT is a methodology for evaluating and managing risk in the IT organization. So if your security policy is thorough and your COBIT process supports the requirements of your policy, your organization has a better chance of having addressed the issues that may have caused a gap in your security scheme.
For example, when IT is implementing a new technology or designing a new application, security can be an afterthought. Following a well-disciplined process that includes a review of the security implications of each project will help ensure security is not ignored. Then, following rigorous testing and implementation processes will ensure security remains in focus for the entire project.
Of course everyone's heard about—and most of you have been affected by—the Sarbanes-Oxley Act (SOX). It was enacted to make sure that there are sufficient controls and processes in place to ensure that corporate financial statements are accurate and reflect reality. Contrary to popular belief, SOX says absolutely nothing about IT security. However, it cannot be argued that the need for information security is at least heavily implied.
As COBIT gained popularity during the height of the SOX compliance push, compliance with SOX—in some peoples' minds—became synonymous with being in compliance with COBIT.
One requirement that more organizations are talking about is a SAS70 audit. This standard is defined through the American Institute of Certified Public Accountants (AICPA) and has been in existence for some time. Its official title is "Reports on the Processing of Transactions by Service Organizations." SAS70 specifies audit requirements for organizations that perform outsourced services or organizations that are using outsourced services. Like SOX, the requirements for passing a SAS70 audit specify nothing specific about security requirements. While the requirement for good security practices may be implied by SAS70 (certainly, a good security scheme supports many of the SLAs outsourcers provide), it's really up to your organization's requirements of the outsourced service to impose security requirements on an outsourcer.
Impact of Regulations and Standards
Laws, regulations, standards, and audits directly impact your organization's security policy. Resist the temptation to have a security policy that is a generic template that could apply to any organization. In other words, make it meaningful for your organization so that it is an actual reflection of your organization's security requirements. While your policy will document your organization's security requirements, it's the implementation of this policy that will determine whether your organization is in compliance.
The white paper "Laws and Regulations and Standards…Oh My!" is available for free download at the MC White Paper Center.