SOMOS NEMO Y BUSCAMOS

Feel free to customize these worksheets to include more questions and pointers related to your particular needs. Electronic copies of the worksheets included in this book are available from the Web site maintained by the author at www.criticalsecurity.com or from the book’s companion Web site at www. wiley.com/compbooks/greenberg.

are provided, directly correlating with our security template. The first work- sheet, Quality Management (see Worksheet 3.1), is somewhat different from the other four. It is “generic,” in that it applies equally to all security elements. You can, of course, modify the worksheet to meet your particular needs. In some cases, you might find it useful to develop several different customized quality management worksheets depending on the needs of your organiza- tion. But in all cases, you will want to complete at least one quality manage- ment worksheet for every security element. To help you fill out the Quality Management worksheets, look at Table 3.1, where column 2, Security Plan, details how to address each item in column 1.

Each of the other four worksheets is preceded, first, by a summary and, sec- ond, by a special figure called Key Relationships. The summary provides a simple recapitulation of the important issues to keep in mind as we examine the particular security element. The Key Relationships figure summarizes the top four security elements tied to the one currently undergoing study. Follow- ing the summary and the Key Relationships figure is a series of guidelines, cat- egorized to correspond to the template, outlined as follows:

Quality Management Security Stack ■■ _Physical ■■ Network ■■ _Application ■■ Operating system Life-Cycle Management ■■ Technology selection ■■ _{Implementation} ■■ Operations ■■ _{Incident response} Business ■■ Businesspeople ■■ _Employees ■■ Customers ■■ _Owners ■■ Suppliers ■■ _Partners ■■ Information ■■ _{Infrastructure}

Selling Security ■■ _Executive

■■ Middle Management

■■ _Staff

There is, necessarily, a certain amount of overlap in these guidelines. For example, under Business, we examine the security element first from the per- spective of information, then from the perspective of infrastructure. Why? Because our objective is completeness; we don’t want to miss anything. By tak- ing an alternate view on a problem, we often discover something new about it. We’re looking for what we might have missed. Think about it: This is precisely what the hacker does—he or she looks for what we might have missed. As I said in Chapter 1, security is a way of thinking, and we need to think it through better than our adversary.

Table 3.1 Quality Management

QUALITY

MANAGEMENT SECURITY PLAN

Revision number Uniquely identify each revision of the security element worksheet plan with a number (e.g., revision 2.1).

Revision date Include the date the revision was made. Change summary Record changes made for each revision (i.e.,

maintain a revision history). For each revision, ensure that an adequate peer review is conducted. Author(s) Document the name(s) of the author(s) of this

element of the security plan. This refers to those who actually wrote the plan, notthe managers who, for example, oversaw the effort.

Owner In most organization’s this will be the manager or team leader who is coordinating the input of the authors of the plan.

Configuration-management Configuration-manage the state of all

status documentation, system configurations, hardware, and software relating to the security element. For more on this, refer to the Configuration Management security element worksheet in Chapter 4.

Table 3.1 Quality Management(Continued)

QUALITY

MANAGEMENT SECURITY PLAN

Budget Our security expenditures begin with a budget driven by our impact analysis. The budget represents an up-front estimate of the cost to implement a particular aspect of the security plan. Obviously, sometimes our estimates aren’t precise— sometimes we’re over-budget, sometimes under. The purpose of this quality management metric is to track, over time, how close we are able to stay to our original budget estimate. You should track your original budget estimate over time and periodically as determined by your organization, such as monthly, and you should note the current amount of money spent thus far. Finally, you should project what you think the new budget will be, based on what you now know. For example, if you allocated $10,000 for a security element plan and have spent $8,000 and you’re not nearly complete, then it’s reasonable to expect that your projected budget may be over $10,000 unless you can find some way to reduce cost.

Schedule Track how closely you stay on schedule as the implementation of your security plan proceeds; after the implementation is complete, record how accurate your initial estimates were.

Business value metrics How does security bring value to your organization? How does it detract from it? Establish a set of metrics for measuring the business value of this element. These metrics are directly related to the way security is “sold” within your organization. For more on this, refer to the Selling Security

worksheets in Chapter 4.

Training effectiveness Track participation and effectiveness of security training programs. One way is to run security audits and drills (simulated security incidents) to verify that people and technology respond as intended. Track attendance and work to measure the effectiveness of training relating to this security element. The security worksheets provided in this chapter and the next frequently provide suggested security auditing and drill approaches. You can customize this quality management worksheet to include metrics for those approaches.

Table 3.1 Quality Management (Continued)

QUALITY

MANAGEMENT SECURITY PLAN

Coordination Define key handoff deliverables and organizational interfaces for security life-cycle management. Security planning requires coordination and handoff of respon- sibilities across multiple groups, both internal and external to your organization. Define key handoff deliverables and organizational interface and coordination requirements for security element life-cycle management. Incident frequency If an organization is overrun with security incidents,

then it stands to reason that it may be doing

something wrong. Therefore, we need to keep track of incidents. Maintain a count of the total number of incidents relating to a particular security element. Incident Impact By keeping track of incident frequency, we are well on

our way to using quality metrics to drive improvements in our security plan. If we associate incidents with potential deficiencies in our security element plan, then we can learn from our mistakes, revise our plan, and reduce the number of incidents going forward. We accomplish this by calculating an incident impact for each recorded incident. If the impact of the incident on the organization is exceptionally high, we work to reduce it by revising our plan. If we have many high- impact incidents, then we know we need to make more aggressive changes to our security plan. Using the impact analysis variables introduced in Chapter 1, we can estimate the impact of a given incident on our organization. For each incident the security planning team should estimate the following:

1. Relative value of information or infrastructure component(s) compromised during the incident (V)

2. Degree of public exposure from the incident (P)

3. Denial-of-business effect of the incident (DoB)

4. Ease of attacking the given information or infra- structure components associated with the incident (E)

A value of 0 through 25, as in our impact analysis, can be assigned to each of these variables for a particular incident. After assigning these values, they can, as before, simply be summed up. An incident impact value of 100 means the incident had the highest possible impact and thus is a “showstopper” for the organization. On the other end of the spectrum, incident impact values near zero are far less important.

Table 3.1 Quality Management(Continued)

QUALITY

MANAGEMENT SECURITY PLAN

Incident response time A security incident has a timeline associated with it. First, the incident is discovered in some way, such as by an alarm from your intrusion-detection systems or an alert from a software vendor indicating the software you’re running has a significant vulnerability associated with it. Let’s call this first event incident discovery. Note that if you are forced to patch a system in response to such a software vulnerability notification from a software vendor, this should also be tracked as an incident. More on that in a moment. Returning to our timeline, after the incident has been discovered, the next significant moment occurs when the incident response team actually responds and assigns a resource to solve the problem. Call this second event incident response. Clearly, as an organization managing the quality of the incident response process, we want the time between incident discovery and incident response to be as short as possible. Third, we have the moment at which the organization believes the incident has been resolved and associated vulnerabilities removed. Call this third event incident resolution. Our objective is to minimize the time between incident response and incident resolution. Finally, the incident response team needs to file an incident report and record these quality management metrics. Call this final event incident report. For every incident, all of these times (discovery, response, resolution, and report) should be recorded in your quality management worksheet.

Incidents caused by Track how frequently you must patch systems to problem software prevent incidents. Too many patches are a sign of a

poorly implemented security product, service, plan, process, or procedure. For example, if your company uses an application sold by company XYZ, and if you are patching the application every other day as a proactive response to newly discovered security holes, then, arguably, company XYZ is doing a poor job of writing secure software. Your quality management process needs to track that. Developers of these problem appli- cations must be held accountable. Define a metric to record the number, severity, and difficulty of responding to these incidents. This metric may also reveal problems within your security plan, such as the need to introduce additional levels of protection for difficult-to-secure applications.

Table 3.1 Quality Management (Continued)

QUALITY

MANAGEMENT SECURITY PLAN

Incident response The purpose of this quality metric is to remind us to false-positives keep a count of the total number of incident false

alarms—the number of times we think we have an incident but, in reality, don’t. As will be discussed when we complete the intrusion detection and vul- nerability analysis (IDS/VA) worksheets in Chapter 4, if we have too many incident false alarms, then we have a problem in our overall security plan that we need to address. Record, report on, and analyze the number of false-positives reported. Continually fine-tune your plan to reduce the number of false- positives while reducing the impact of security incidents on the organization that aren’t detected. Performance Define how you measure, report, and analyze the performance impact of security measures on key systems. Often security slows things down. It may also speed things up if, for example, manual processes can be automated thanks to the increased comfort level and, in some cases, increased functionality offered by your security plan. Measure, record, and perform trend analysis on key performance-affected systems relating to each security plan element. There are many tips in future worksheets for potential performance measurements you might make as you implement your security plan. Integrate here those performance measurement tips that apply to your particular organization.

Audits and drills When you run audits and drills relating to your security plan element, you should assess the success or failure of the audit or drill. Because each audit and drill is unique, you should customize this quality management metric for your particular security element plan. As with performance, tips are provided throughout the worksheets indicating when audits and drills might be most beneficial. Suppliers, quality, and Show how you establish, measure, and analyze service-level agreements security quality according to any service-level agree-

ments (SLAs) that have been established internally or with suppliers and partners. For example, if you have agreed with your Web-hosting supplier that you will experience no more than one security incident every six months, and the duration, from incident detection to incident resolution, should be no more than four hours, then track your supplier’s perfor- mance to see if it is living up to the agreement.

Table 3.1 Quality Management(Continued)

QUALITY

MANAGEMENT SECURITY PLAN

Plan violations Record when individuals or technology violates your security plan; analyze related trends. These violations are themselves incidents; however, they are special types of incidents. When we have many of them, we typically have a training problem in our organization. Track incidents such as the use of unauthorized software. Record how many occur over a set time (e.g., number of violations per month). Work to reduce violations over time; if they are not reduced, determine if more training and education are required or if the underlying security element needs to be revised so that it can be more easily adhered to.

You will notice that every worksheet has an Impact Analysis Summary. This is where you should list any impact analyses that relate to this security ele- ment and particular area of planning. In order to keep things simple, I recom- mend that you assign each of your impact analyses a unique identifier (ID), which you can then put in the first column labeled Impact Analysis ID. In the second column, you place the original impact value (before the current version of your security worksheet was implemented). In the Percent Improvement column, insert the percentage of impact improvement you expect after imple- menting your worksheet. For example, if, before implementing your plan, the expected impact was 80 and, by implementing your plan as described in your worksheet, you expect an improvement of 50 percent, then your new impact value would be 40 (see Table 3.2).

Table 3.2 Impact Analysis Summary

IMPACT PERCENT