In my previous articles, I have covered specific topics (log management, incident response, intrusion detection, and computer forensics), but now it's time to take a step back and look at the forest rather than the trees. Those specific subjects are all covered by the same broader umbrella: the corporate security policy.
A properly drafted and implemented security policy serves to protect information, systems and even people; it sets guidelines for expected employee behavior, and authorizes security personnel to monitor, probe, investigate, define, and determine the consequences of violating the policy.
More generally, security policies help define the company's overall stance on security issues and minimize internal and external risk exposure. What is even more relevant for this article is that a policy will also incorporate guidelines from various corporate regulations.
Of course, simply having a security policy is only half the battle. A study conducted by the Ponemon Institute (and mentioned in a December Computerworld article,) found that many IT professionals either knowingly ignore their company security policies or inadvertently break the code because they are simply unaware of the guidelines.
For example, more than half of the 890 respondents said that they had copied confidential company information onto USB memory sticks, even though 87% of them admitted they knew this action is explicitly disallowed by their company's security policy. Of course, no less disturbing is that 33% of respondents had sent workplace documents home as e-mail attachments, even though almost half of them had no idea whether or not that practice violated their company's security policy.
Thus, the other half of the battle in implementing security policies is ensuring that all employees are aware of the policy's stipulations and that the policy includes a chain of responsibility for implementation and enforcement. Moreover, some evidence points at the fact that security pros are no better than regular IT users about complying with policies that they see as "stupid." Recently, even major publications such as the Wall Street Journal have published tips that would violate security policy at most organizations.
Overall, there is a chasm between drafting a security policy -- a process which is relatively straightforward -- and having a living policy that evolves with the organization and that is actually being enforced and followed. Many policy initiatives die right after the initial policy creation phase. We will explore this phenomenon in an upcoming article "Five Mistakes of Security Policy."
Let's take a look at what our usual regulations say about security policies.
The Federal Information Security Management Act of 2002 (FISMA)
FISMA defines three information security objectives: confidentiality, integrity, and availability. FISMA's security policy muscle come broadly through The NIST Risk Management Framework (RMF) and specifically through NIST 800-53 ("Recommended Security Controls for Federal Information Systems").
The RMF gives eight steps outlining the mandatory creation of a security policy:
- Categorize the information system (for FISMA, this can be done using the Federal Information Processing Standards Publication 199, or FIPS 199)
- Select (based on the FIPS 199 categorization) and tailor minimum security controls
- Supplement certain security controls based on risk assessment
- Document security controls in a system security plan
- Implement the security controls in the information system
- Assess the security controls for effectiveness
- Authorize information system operation based on minimizing risk
- Monitor and assess security controls on a regular basis
NIST 800-53 ("Recommended Security Controls for Federal Information Systems") takes a more granular approach to federal information security, calling for the creation of specific policies within the general security policy. Such specific policies include the development, dissemination, and review of security awareness and training procedures, personnel security procedures, risk assessment procedures, audit and accountability procedures, contingency planning procedures, and incident response procedures.
Both documents facilitate a consistent level of security for federal information systems. Importantly, they also offer the needed flexibility to tailor the controls based on specific organizational policy and requirements documents, conditions and circumstances, and known threat and vulnerability information.
Those outside federal IT should read the above NIST guidance documents since they contain information that's also useful for creating a security policy for non-government entities. They also focus heavily on making the users aware of the policy -- which is, sadly, a commonly overlooked aspect of security policy implementation.
The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
NIST SP 800-66, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act Security Rule, details HIPAA-related security policy requirements. Section 4.1 ("Security Management") requires that the organization create and deploy security policies and procedures.
This includes implementation of the decisions concerning the management, operational, and technical controls selected to mitigate identified risks, and the creation of policies that clearly establish roles, responsibilities and procedures for the implementation of each security-related tasks. As with FISMA, closely tied to this is the requirement for a sanction policy and a contingency planning policy, among others.
More specifically, Section 4.2 ("Assigned Security Responsibility") requires that a healthcare organization select a security official to be assigned responsibility for HIPAA security. A key element of that assignment is to serve as the point of contact for security policy, implementation and monitoring. As is crucial to security policy success, HIPAA also requires that all employees be proficient in the policy and understand the consequences of non-compliance.
Overall, NIST guidance for HIPAA is useful for other organizations outside of healthcare; they are especially useful for those creating a policy in an environment with lots of sensitive and regulated data.
Payment Card Industry Data Security Standard (PCI DSS)
In the past, we have discussed PCI's Requirement 10 ("Track and monitor all access to network resources and cardholder data") when we have focused on log data analysis. In this article, we focus on Requirement 12 ("Maintain a policy that addresses information security"), which dictates security policy formation for organizations that handle credit card transactions.
Requirement 12 discusses the importance of establishing, publishing, maintaining, and disseminating a security policy that addresses all security-related requirements; that includes daily small-scale and at least annual large-scale reviews to identify threats and vulnerabilities and to formally assess company risk; and that updates when the security environment changes.
Requirement 12 also stresses that the company should assign to individuals or teams a variety of roles related to the security policy, including the distribution of the policy, monitoring, analyzing ,and controlling security alerts and access to data, and administering user accounts (including additions, deletions, and modifications). PCI also requires that a formal security awareness program be implemented to make all employees aware of the importance of cardholder data security. Specific approaches to cardholder data security are outlined in Requirement 3 ("Protect stored cardholder data").
Overall, PCI DSS presents a simple and common sense view on security policy: it is required reading for everybody embarking on a quest to successful security policy.
The above review of regulations suggest that regardless of industry or what regulation a company is subject to, security policies have migrated from being "a good idea" to being "the law" since most of the regulations state that security policy is the foundation of a security program. However, just "having the policy" will not yield nearly any of the benefits of having a dynamic, regularly updated policy that is being enforced and that all users are aware of.
Dr. Anton Chuvakin, GCIA, GCIH, GCFA is a recognized security expert and book author. He's currently Chief Logging Evangelist with LogLogic, a log management and intelligence company. He is the author of Security Warrior and a contributor to Know Your Enemy II, Information Security Management Handbook, Hacker's Challenge 3 and PCI Compliance.