Once you have derived a list of threats, you should systematically prioritize them so that they can be addressed efficiently. Over-commitment of resources to mitigate low-risk threats can be just as damaging to an organization as under-spending on high-risk mitigations, so it’s important to get this step right.
Numerous systems can be used for quantifying and ranking security risk. A classic and simple approach to risk quantification is illustrated in the following formula:
Risk = Impact × Probability
This is a simple system to understand, and it even enables greater collaboration between business and security interests within the organization. For example, the quantification of business Impact could be delegated to the office of the chief financial officer (CFO), and the Probability estimation could be assigned to the chief security officer (CSO), or their equivalents. This produces a smart division of labor and accountability when it comes to managing risk for the organization overall.
In this system, Impact is usually expressed in monetary terms, and Probability as a percentage likelihood between 0 and 100 percent. For example, a vulnerability with a
$100,000 impact and a 30 percent probability has a risk ranking of $30,000 ($100,000 × 0.30). Hard-currency estimates like this usually get the attention of management and drive more practicality into risk quantification. The equation can be componentized even further by breaking Impact into (Assets × Threats) and Probability into (Vulnerabilities × Mitigations).
We’ve seen risk models that factor components further. For example, if system component A has 3 high-impact vulnerabilities, but component A is connected to another system in a fully trusted configuration that has 12 vulnerabilities, you could calculate a total vulnerability surface of (3 + 12)2, or the square of the sum of vulnerabilities.
Other popular risk quantification approaches include Microsoft’s DREAD system (Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability), as well as the simplified system used by the Microsoft Security Response Center in their security bulleting severity ratings. The Common Vulnerability Scoring System (CVSS) is a somewhat more complex but potentially more accurate representation of common software vulnerability risks. (We really like the componentized approach that inflects a base security risk score with temporal and environmental factors unique to the application.) Links to more information about all of these systems can be found at the end of this chapter in “References and Further Reading.”
We encourage you to tinker with each of these approaches and determine which one is right for you and your organization. Perhaps you may even develop your own, based on concepts garnered from each of these approaches, or build one from scratch. Risk quantification can be quite subjective, and it’s unlikely that you’ll ever find a system that results in consensus among even a few people. Just remember the main point: Apply whatever system you choose consistently over time so that relative ranking of threats is consistent. This is after all the goal—deciding which threats will be addressed in priority.
We’ve also found that it’s very helpful to set a threshold risk level, or “risk bar,” above which a given threat must be mitigated. There should be broad agreement on where this threshold lies before the ranking process is complete. This creates consistency across assessments and makes it harder to game the system by simply moving the threshold around. (It also tends to smoke out people who deliberately set low scores to come in below the risk bar.)
Policy
Clearly, the optimal thing to do with the risks that are documented during the assessment process is to mitigate or eliminate them (although other options exist, including transfer of the risk via purchasing insurance, or acceptance as-is). Determining the mitigation plan for these risks is the heart of the Planning phase: policy development.
Policy is central to security; without it, security is impossible. How can something be considered a breach of security without a policy to define it? Policy defines how risks to assets are mitigated on a continuous basis. Thus, it should be based firmly on the risk assessment process.
That said, a strong organizational security policy starts with a good template. We recommend the ISO 17799 policy framework, which has become quite popular as a framework for security policy since becoming an international standard. ISO 17799 is being incorporated into the new ISO 27000–series standards, which encompass a range
of information security management standards and practices (similar to the widely used ISO 9000–series quality assurance standards). ISO 27001 includes a controls framework for implementing and measuring compliance with the policy standards. Other popular control frameworks include COBIT, COSO, and ITIL. (See “References and Further Reading” for links to information on these standards.)
Another great dividend that arises from basing your policy on widely accepted standards such as ISO 17799 is the improved agility to meet evolving compliance regimes such as these:
• Sarbanes-Oxley Act of 2002 requiring U.S. publicly held companies to implement, evaluate, and report on internal controls over their fi nancial reporting, operations, and assets.
• Basel II: The International Convergence of Capital Measurement and Capital Standards:
A Revised Framework that revises international standards for measuring the adequacy of a bank’s capital based on measured risk (including operational risk, such as information system security).
• Payment Card Industry Data Security Standard (PCI DSS) for any entity that processes, stores, or transmits credit card information from major issuers such as Visa, MasterCard, and American Express.
• Health Insurance Portability and Accountability Act of 1996 (HIPAA), which specifi es a series of administrative, technical, and physical security procedures for covered entities to use to assure the confi dentiality of electronic protected health information.
• Gramm-Leach-Bliley Act of 1999 (GLBA) regulating U.S. consumers’ personal fi nancial information held by fi nancial institutions.
• Security breach notifi cation laws evolving in many U.S. states today (such as California’s SB 1386).
Even if your organization isn’t covered by one of these regulations (and we bet you are somehow!), it’s probably only a matter of time before you’ll need to be compliant with their statutes in one form or another. If you even think your organization needs to meet some sort of regulatory compliance requirements, we cannot emphasize enough the efficiency gained by re-using one security program framework for meeting the evolving alphabet soup of compliance requirements facing modern business today. And we’ve got the scars to prove it, having personally designed and implemented an ISO 17799–based security policy that successfully passed audits of compliance for SOX, GLBA, PCI, and other one-off regulatory enforcement actions by the U.S. government.
Although the importance of meeting evolving compliance requirements can’t be overemphasized, smaller organizations with more narrowly scoped needs may find ISO standards and supporting frameworks burdensome to plan and implement. For organizations of all sizes, a good (but expensive) collection of prewritten security policies is Charles Cresson Woods’ Information Security Policies Made Easy (Information Shield, 2005). We’d also recommend reading RFCs 2196 and 2504, “Site Security Handbook” and
“User Handbook,” respectively, for great policy ideas. A simple Internet search for
“information security policies” will also turn up some great examples, such as at many educational institutions that publish their policies online.
A discussion of organizational security policy development and maintenance lies outside the scope of this book. However, here are a few tips:
Understand the Business Security practitioners must first understand the business that they are there to help protect; understanding business operations creates the vocabulary to enable a constructive conversation and leads to being perceived as an enabler, rather than a hindrance. In our experience, security practitioners generally need to become more mature in this department, to present information security risk in appropriate business terms. Focusing on collaborative approaches to measuring risk and implementing measurable controls is always a smarter way to get resources from business leaders, in our experience.
Cultural Buy-in Convince management to read thoroughly and support the policy.
Management ultimately enforces the policy, and if managers don’t believe it’s correct, you’ll have an extraordinarily difficult time getting anyone in the organization to follow it. Consider creating a governance body that comprises key organizational stakeholders, with defined accountabilities, to evolve and enforce the policy long-term.
At the same time, recognize that executive buy-in is useful only if company personnel listen to executives, which isn’t always the case in our experience. At any rate, some level of grassroots buy-in is always necessary, no matter how firmly management backs the policy; otherwise, it just won’t get adopted to the extent required to make significant changes to security. Make sure to evangelize and pilot your security program well at all levels of the organization to ensure that it gets widespread buy-in and that it will be perceived as a reasonable and practical mechanism for improving organizational security posture (and thus the bottom line). This will greatly enhance its potential for becoming part of the culture rather than some bolt-on process that everybody mocks (think TPS reports from the movie Office Space).
Multi-tiered Approach Draft the actual policy as a high-level statement of guiding principles and intent, and then create detailed implementation standards and operational procedures that support the policy mandates. This multi-tiered, hierarchical approach creates modularity that eases maintenance of the policy in the long term by providing flexibility to change implementation details without requiring a full policy review and change cycle.
Process for Exceptions, Change The only constant is change, and that goes for security policies, too. Expect that your organization will make policy exception requests and will want to change the policy at regular intervals. You will need to create a process by which this is accomplished. We recommend at least annual reviews and also a special process for exceptions and emergency changes. You can make these processes as cumbersome as you’d like to discourage frequent exception requests and/or changes to the policy (grin).
Awareness We’ll talk about training and education in the next section of this chapter when we talk about the Prevent phase of the security wheel, but making sure that everyone in an organization is aware of the policy and understands its basic tenets is critical. We have also found that performing regular awareness training for all staff typically generates great practical feedback, leading to a stronger security program over the long term.
With a policy defined and implemented, we can continue on around the security wheel defined in Figure 1-1.
Prevent
The necessity for several preventive controls will likely become obvious during the risk assessment and policy development process. This book will list specific technical countermeasures to all of the attacks we discuss, but what sort of broader proactive measures should be in place to mitigate risks, enforce security policy, deter attackers, and promote good security hygiene? Consider the following items:
• Education and training
• Communications
• Security operations
• Security architecture
Education and training are the most obvious ways to scale a security effort across an organization. Communications can assist this effort by scheduling regular updates for line staff and senior management as well as keeping the information flowing between the rest of the organization and the security group. (Remember that no security exists in a vacuum.)
Security operations include general security housekeeping, such as security patch management, malware protection, access control (both physical and logical), network ingress/egress control, security monitoring and response, and security account/group management. We will touch on best practices throughout all of these areas in this book.
Finally, and perhaps most importantly, some part of the security organization needs to adopt a proactive, forward-looking view. The work of a security architect is particularly relevant to application development, which must follow strict standards and guidelines to avoid perpetuating the many mistakes that unavoidably occur in the software development process. In addition, this role can perform regular evaluations of physical, network, and platform security architecture, benchmarking them against evolving standards and technologies to ensure that the organization is keeping pace with the most recent security advancements.
Detect
A policy document is great, but what good is a policy if you can’t figure out whether anyone is following it? Much of the material in this book focuses on the Detect part of the security wheel, since finding and identifying security vulnerabilities is a critical part of
detecting violations of security policy. Other processes that fall into the Detect sphere include the following:
• Automated vulnerability scanning
• Security event and information management (SEIM)
• Intrusion detection systems (IDS)
• Anomaly detection systems (ADS)
• Security audits (including penetration testing)
This is not a book on the art of intrusion detection or forensic analysis, but we do make several recommendations for Windows configuration settings throughout this book that will enable a strong detective controls regime. Don’t forget to review the logs you keep in a timely fashion—there’s no point in keeping them, otherwise.
Respond
Continuing around the security wheel, we arrive at Respond. Assuming that a security vulnerability—or, egads, an actual breach—is identified in the Detect phase, the next step is to analyze and act (possibly quite quickly!). Some of the key elements of the Respond portion of the security lifecycle include the following:
• Incident response (IR)
• Remediation
• Audit resolution
• Recovery
We’ll talk in detail about vulnerability remediation, resolution, and recovery in the course of describing how to avoid getting hacked. We will not spend much time discussing what to do in case you do get successfully attacked, however, which is the discipline of security incident response (IR). IR describes many critical procedures that should be followed immediately after a security incident occurs to stem the damage, and these procedures should be in place in advance. We also do not cover business continuity planning and disaster recovery (BCP/DR) issues in this book. We have listed some recommended references on these topics in the “References and Further Reading” section at the end of this chapter.