Contents

Introduction
Background
Risk Modeling Methods
Requirements
The Rapid Risk Model
      Risk Calculations
      Risk Levels
      The Process
An Example of Rapid Risk in Use
Results
Conclusion
Acknowledgements

Introduction

The importance of having an integrated information security practice within an enterprise has become self-evident. High-profile incidents, such as Distributed Denial of Service (DDoS) attacks against well-known websites, massive email-borne virus outbreaks, and other examples of high-tech malfeasance routinely make news. Discussions of these issues are no longer limited to the relatively small community of security practitioners. Management teams have traditionally had little knowledge or awareness of security issues, but now they are required to pay attention—both to the number and types of incidents they are seeing, as well as regulatory requirements from laws such as Sarbanes-Oxley, California SB 1386, and HIPAA.

For the enterprise information security ("Infosec") team, this new engagement by business management is welcome, but presents new challenges. The days of an Infosec team being regarded as a roadblock to business operations are rapidly fading. Where once Infosec had to beg development teams to be engaged during a project's development cycle, today the situation is likely to be reversed. Business managers now often require that their technology projects gain Infosec assistance and approval early in development. For a medium-sized or large enterprise, this can result in numerous projects simultaneously requiring security expertise.

To efficiently make use of limited monetary and personnel resources available for project consulting, Cisco Infosec has developed a lightweight risk triage method known as Rapid Risk. Risk triage allows security teams to quickly assess a project's overall security risk without investing the resources required to perform a traditional in-depth risk assessment. Rapid Risk is used when new IT projects are brought in for review, allowing Infosec to focus its efforts on those projects that are most at risk. Additionally, Rapid Risk assists in helping business managers incorporate security concerns into their decision-making processes.

Rapid Risk has also given Cisco the ability to prototype different security risk scenarios. Project teams can now evaluate competing architectures and choose lower-risk options, and when a project team does opt for a higher-risk design, they have made an informed decision.

This paper discusses the need for risk triage and prototyping, how existing risk models do not meet those needs, the development of the Rapid Risk model, and its success at improving information security at Cisco.

Background

Like many similar organizations, Cisco IT has a formal systems development lifecycle (SDLC) program. Under the SDLC, individual business organizations that wish to deploy new applications or technology into the Cisco environment must go through a security review. This early engagement model has the benefit of including security as projects are developing, so that these issues can be identified and mitigated before the project goes into production.

As the SDLC and security engagement became compulsory at Cisco, the Infosec team was challenged to handle the demands placed upon its limited security resources. There was no method to differentiate between a project that required minimal security assistance and a project that required a great deal of assistance. As a result, all projects were treated equally, which overburdened the security engineers and wasted security resources.

Other problems also developed. Individual security architects handled similar projects in different ways. As project managers learned about the individual personalities of the security architects, these project managers would tend to play the security architects off one another in order to minimize changes required for that project. It was also relatively common for business groups to "push back" on the security team if the security architect imposed a requirement that the project team felt was overreaching or limiting.

Lastly, there were communication differences between the security architects and the business managers. Business managers had difficulty understanding the risks to the company in terms of technical security concerns, while the security architects had difficulty understanding a project's business drivers. Consequently, business managers sometimes made ill-informed decisions regarding security, and the security architects were often seen as disrupting the business. Dysfunctional situations like these have created impasses between project members, delayed project timelines, and increased cost.

In order to meet these challenges, Cisco Infosec decided to move to a standardized risk-based approach for IT project engagements.

Risk Modeling Methods

The first step in creating a system to handle projects based on risk was to survey existing security risk modeling methods. Compared to some industries, such as the insurance industry, the field of information security is lacking in risk modeling methods.

Some of the less-mature risk modeling methods examined were ad-hoc and used arbitrary calculations. Often, their computational models were overly complex and depended upon attack probabilities that were difficult to determine. Such probabilities would only have been valid with enormous amounts of historical data that do not exist anywhere in information security.

Other models examined were resource-intensive. In some cases, these models required the security architect to gather large amounts of data about the project under evaluation and to answer hundreds of in-depth questions.

The mature risk modeling methods had a focus that differed from what was desired at Cisco. Some models, such as auditing methods based on ISO 17799 or COBIT, were enterprise-focused, designed to evaluate the overall security risk to a large organization. These models could not scale down to a level required for evaluating individual projects. Other models, such as OCTAVE from Carnegie-Mellon University, were asset-focused, and evaluated threats to a specific set of assets, such as hosts, using an attack-tree methodology. While their scope was more focused, asset-focused methods also did not adapt well to evaluating the security risks inherent in a project.

Table 1. The Cisco Rapid Risk Model Complements Other Risk and Governance Models

Requirements

Since the needs of Cisco could not be easily met by any of the existing information security risk models, a new risk model was necessary. This model required several characteristics:

• Rapid assessment: The risk assessment model had to allow the users to complete the model within a few minutes. All existing assessment methods took hours, days, or in some cases, months to complete. Since the average Infosec architect had between 10 and 50 projects at any one time, the risk assessment model needed to have minimal impact upon the security architect’s time.
• Parity between different interest groups: The assessment model had to incorporate interests of multiple stakeholder groups. This would facilitate cooperation between different organizations, giving all parties a stake in the output of the model.
• Consistency: The model had to use a standard process and be mature enough that similar inputs would generate similar outputs. It also had to be internally consistent, so that failure in one area of evaluation did not automatically render other areas of evaluation meaningless. Such an imbalance would be indicative of a weak model.
• Business-oriented output: One shortcoming of other risk models was that once complete, the user was left with a number, such as "87" or a ranking, such as "high risk," but no context. It was usually left as an exercise to the user to interpret the results. The model needed prescriptive output in clear, non technical language that could readily be understood and acted upon by a decision maker.
• Simple and non arbitrary: The computational aspect of the model needed to be solid. Other models often used mathematics so complex that they were impractical and relied upon probabilities ("What is the probability of an attack against this resource?") that were difficult or impossible to calculate. A model that required this kind of guesswork had to be avoided.
• Use cases: The model had to support several different use cases.
• Risk triage: The model needed to provide a quick risk profile of a project to be used in determining the amount of security involvement. The project would be required to adhere to certain policies, procedures, and standards based on its risk profile.
• Risk prototyping: As a decision support tool, the model needed to be able to evaluate different security scenarios. The results could be used by management for consideration before they committed to a particular course of action.
• Security metrics: By applying the model multiple times during a project’s development cycle, changes in risk could be measured over time. A decrease in risk could be used to demonstrate the value of Infosec engagement.

The Rapid Risk Model

Rapid Risk is a "multivector" security risk modeling methodology that has both quantitative and qualitative aspects. A risk vector describes a specific aspect of risk such as business risk or technical risk, and balances that into an overall composite risk. Each vector is represented by a multiple-choice questionnaire that is independently assessed by the stakeholder for that risk. The questionnaires are weighted with predefined values, summed to produce a risk score for each risk vector, and then used to calculate the final composite risk score. Once calculated, the composite risk score is mapped to one of five risk levels, which allows for various recommendations, standards, or procedures to be applied based on that risk level.

Rapid Risk balances different risk vectors equally into the composite risk score. To achieve this, it is important to design the questions to be of equal value and ensure that there are the same number of questions in each questionnaire. Each question, in turn, needs to have the same number of possible answers and be weighted in the same manner.

Due to the previously mentioned challenges between business managers and security architects, Cisco Infosec chose to use two risk vectors, one representing the business risk and the other representing the technical security risk. Both questionnaires consist of ten questions, with five answers per question. Each question is worth a maximum of ten points, giving the questionnaire a maximum total of 100 points. Since this is a risk triage model and not an in-depth risk assessment method, it is important to choose questions that are specific enough to provide useful information without being so specific that hundreds of questions are needed to arrive at a conclusion, as other methods do. It was determined that if the “right” 20 questions were asked, an equally valid understanding of overall risk would be achieved.

The first questionnaire, which determines overall business risk (B), represents how critical the project’s business process or data is to the overall ongoing operations of the enterprise. These questions are created by a person representing all of the business groups. This questionnaire is answered by the business owner of the project, or the data steward for a specific project. It is important to the validity of the Rapid Risk model that a business representative determines the business risk, just as it is important to have a security architect determine the technical security risk.

The technical security risk (T) represents the likelihood that an attack launched against the project’s infrastructure would succeed. These questions are defined by the Infosec team and are answered by the Infosec security architect assigned to evaluate the project. Where other models attempt to guess how likely an attack is to happen against a particular project’s infrastructure, Rapid Risk assumes attacks will happen. There are a number of reasons for this. Unlike insurance companies, information security has not had hundreds of years of history to compile statistics on how likely an event is to happen. The other main reason to avoid guessing the probability of an attack is that attack technology and methods evolve, creating new security threats that previously did not exist.

In the questionnaires, every question has five possible answers with varying degrees of severity, each representing one of the five risk levels. In this case, answer (a) for every question represents a “severe risk” answer, while answer (e) represents a “low risk” answer. Failure to do this would allow one question to have more clout than the other questions, and would prevent the model from equally balancing the risk across all of the vectors.

Once the questions are designed, the answers must then be weighted (Table 2). The weights are determined by the boundaries of the five risk level categories. For example, if each question is worth a maximum of ten points and there are ten questions in a questionnaire, answering (a), the severe risk answer for all ten questions, would result in a score of 100, placing the project at the top of the severe risk category.

Table 2. Weight Values

Risk Calculations

Once weighted, the risk score for each questionnaire is calculated in the following manner:

Assume R1 is the business risk vector score computed from the business questionnaire. It is calculated by the formula

R1 = (Bw1 + Bw2 + Bw3 + …. + Bwm)