ITS 3050 - Security Policies and Auditing

Managing Risk in Information Systems
Chapter 10, Planning Risk Mitigation Throughout Your Organization
Chapter 11, Turning Your Risk Assessment into a Risk Mitigation Plan

Objectives:

This lesson presents two related chapters about risk mitigation planning. Objectives important to this lesson:

1. Where to start
   
2. Legal and compliance issues
   
3. Assessing countermeasures and safeguards
4. Operational impacts
5. Cost-benefit analysis
6. Best practices
   
   
7. Reviewing a risk assessment
   
8. Overview of conversion to a mitigation plan
   
9. Prioritizing risks
   
10. Follow up on planning
11. Best practices mitigation planning
    

Concepts:

Chapter 10

The chapter begins by reminding us to identify assets. Having made an inventory and rated each asset on its importance to our organization, we might want to do some house cleaning by removing assets that are not serving our needs, replacing them as necessary with assets that contribute to reaching our goals.

The author takes a long winded approach to saying that he recommends that we use NIST SP 800-53 as a reference book. Examine controls that apply to our organization, and match appropriate controls to identified threat/vulnerability pairs.

Under the topic of determining the scope of your mission to mitigate risks, the author tells us to consider several related topics that can be thought of as a ladder to reach our goal:

• What are our critical business operations? - These are the activities that must be supported to keep our business open and operating.
  The author reminds us to do a Business Impact Analysis, which was mentioned in the last lesson. We need to identify what operations are critical, and how long they can be down before the outage affects the company. This downtime is referenced by several names: maximum acceptable outage (MAO), maximum tolerable outage (MTO), and maximum tolerable period of disruption (MTPOD).
  
• How do we deliver services to our customers? - The text is recommending that we have service level agreements (SLAs) with our customers, so that we can tell when we are not meeting, meeting, and exceeding expectations. A SLA gives us a measurable level that we can't fall under.
  
• What are the mission-critical systems, applications, and data stores that support the two areas above? - Okay, so now we have a list of what we have to do for ourselves and for our customers to stay in business. Match that information with the systems and assets needed to meet those goals. More buzz words: critical business functions (CBFs), and critical success factors (CSFs). In this case, a factor is anything needed to perform a function.
  The text offers an example. To run an Internet business, we need for our customers to make purchases. This means that we need to maintain our Internet presence, including the web servers, database servers, and payment servers that the customers use (often without knowing so). In addition, we need to maintain our ordering and shipping services, which includes our warehouse operations, customer service operations, and restocking operations.
  
• How can we categorize our identified IT assets in the seven domains, since the author thinks everything depends on that? - I think that the domain concept is meant to break a complex problem into manageable pieces. If your organization uses a different structure scheme, use that instead, but break the concept down so that individual employees can see where their efforts fit into the big picture.
  
• Where are our assets unprotected? - The point in this step is to make sure that we find the gaps and take action to fill them. We want to be protected so we can continue to function.
  

The next section of the text is about ten pages long. It concerns federal laws and regulations that require particular compliance. We will see this list again in the second text.

• Federal Information Security Management Act (FISMA, 2002) - mandates that the Federal government and its contractors follow a common set of information security standards. The standards are set by the National Institute of Standards and Technology (NIST).
  
• Health Insurance Portability and Accountability Act (HIPAA, 1996) - Establishes a large, complicated rule set for storing health information in a common format, making it sharable, and making it a crime to share it with people who should not have it.
• Sarbanes-Oxley Act (Sarbox, 2002) - a reaction to corporate fraud and corruption; provides penalties up to $5,000,000 and 20 years in prison for officers who file false corporate reports. It also requires the protection of financial data.
  
• Family Educational Rights and Privacy Act (FERPA, 1974) - Requires that schools, such as colleges and universities, protect the privacy of their student records, and provide students access to their own records
  
• Children's Internet Protection Act (CIPA, 2000) - A law that means to protect children from obscenity, pornography, and harmful material. This law requires libraries to use filtering software on computers used by minors, and also allows librarians to provide access without the filter to adults who request such access.
  
• Payment Card Industry Data Security Standard (PCI DSS, 2006) - A global standard for processing payments by bank cards, credit cards, and debit cards. It was created in 2006, but there have been updates since then. It requires that an organization taking payments of this type have and use security policies. It also requires that the card processor have a secure network, protect card holder data, manage vulnerabilities, and have strong controls. Obviously, this standard has not always been followed.

The list above only deals with some of the laws in the United States. Other countries have laws that are similar, and laws that are different.

• reduce the impact of a threat to a acceptable level
• reduce a vulnerability to an acceptable level
  

If a control, or a combination of controls, passes one or both tests, it is worth conducting a cost-benefit analysis for it. Realize that we should maintain internal documentation on our controls, and the reasons we are using them. Controls should be reevaluated regularly, and each time a threat or a vulnerability the control is associated with has changed.

In addition to providing fines and other penalties for unlawful disclosure of protected information, we often are obligated by law to maintain and protect the information itself. With that in mind, the text recommends a list of standard controls that should be applied to any organization:

• account management controls such as putting accounts in suspense or deactivating them when employees leave the organization
  
• access controls such as the rule of least privilege
  
• physical access controls such as locks, access logs, and video records of activity
  
• personnel policies, such as separation of duties, job sharing, and audits
• security awareness training for all staff
  

The text repeats its advice to do cost benefit analysis, giving us two simple formulas.

• Loss without a control - loss with a control = projected benefits
  

The formula above tells us if a control is effective. Does using this control reduce losses?

• Projected benefits - cost of control = control value
  

This formula tells us if the money saved by using the control justifies the cost of using that control. Be careful with this one. Sometimes there are other losses that are reduced by the same control, so they should be considered. And sometimes we are obligated by law or ethics to do something to reduce our risks.

Finally, the chapter offers some best practices regarding mitigation plans.

• review historical documentation - the history of risk management in your organization gives you insight into your current situation
• use a narrow focus,and a broad focus - focus on the project you are doing, but don't lose sight of the big picture
• make sure you are compliant with laws
• when a control changes, do a new risk assessment
• provide a cost-benefit analysis to management
  

Chapter 11

As our text keeps doing, it takes a couple of steps back when it starts chapter 11. I wonder if these chapters were published in a serial format, such as in a magazine, which may have caused the author to want to remind the reader where he left off in the last article. Assuming we handed in our risk assessment recently (in the last chapter), we should review it for comments when it is returned to us by upper management. The text points out three items to review:

• in-place countermeasures - are these controls staying in place, being replaced, or no longer being used?
  
• planned countermeasures - the text says that these are new controls, ones proposed by us or by someone else, that have just been approved, so they may need to be purchased, installed, etc.; the implication is that these are new approvals that we need to put in the installation pipeline
  
• approved countermeasures - these are controls that have been approved previously, but have not yet been installed; the text implies that these are old approvals that need to be implemented
  

The author could have chosen clearer labels, but this appears to match his points.

In the section that follows, the text suggests that we look for overlap, or double coverage, in our growing list of controls. One might consider looking for a way to save money by applying fixes that help us in more than one area, and choosing not to buy the second defense. The text advises us that this is not always a good idea. Having more than one kind of defense for a particularly nasty threat/vulnerability pair can be very helpful. If an exploit is found that bypasses one of them, the other may still defend us if it uses a different method. This is a good reason to seek out multiple defenses against loss, generally called using a defense in depth strategy.

A few pages are devoted to discussing a password management policy, including a list of features that are commonly spelled out for users and administrators. This is good information, but outside the scope of this chapter, so we should proceed to page 289, where the discussion of converting an assessment to a mitigation plan begins.

The text is concerned about three major effects of a mitigation plan, listed on page 289 and detailed in the pages that follow.

• cost to implement the countermeasures - The text reminds us that some countermeasures have associated costs. The initial cost of the hardware/software to be used, the cost to house the equipment and staff who will use/maintain it, the cost of installing the equipment and additional equipment (such as racks, power runs, air conditioning changes, and UPS units), and the cost of training staff to use and maintain it are common costs associated with countermeasures, just as they are with any new technology.
• time to implement them - We should consider the time it costs our staff to achieve implementation, as well as the time that we are still exposed before implementation is achieved.
• operational impact of the countermeasures and of the implementation - Will the countermeasures raise operational costs in terms of time to do one's job, time spent doing things in harder ways, time spent venting frustration because what we could do before can't be done now? Will staff be tied up during implementation, causing a loss of productivity with regard to their regular jobs?

The text opens a new topic on page 297, making us wonder if a project we work on in this way will ever be completed. It introduces another chart that can be used to develop priorities for our organization. The two charts on pages 298 and 299 represent one concept, but they do not appear to be doing so. It is easier to understand if we start with the second chart, and think of it in terms of something we discussed in chapter :

Risk Level = Probability that an exploit of a vulnerability will succeed x Impact of that occurrence on the organization

• The chart on page 299 has threat descriptions in its first column.
• The second column contains a score for the probability that each threat will be realized in a successful exploit. These scores are only ballpark guesses, so our hypothetical analyst is assigning scores of 100% for high probability, 50% for medium probability, and 10% for low probability.
• The third column contains impact scores, based on guesses about the impact an occurrence of the threat would be to our company. This column has raw scores of 100 for high, 50 for medium, and 10 for low.
• The fourth column shows risk level, expressed as the result of the formula above. The text proposes that we use the scores in this column to prioritize the actions we will include in our mitigation plan.

Note that in this evaluation scheme, the composite scores for the first two rows are the same. Each is rated high on one factor, and medium on the other. In the next couple of pages, cost benefit evaluations are done, a recommendation is sent to upper management.

One page 304, we see that a risk mitigation project is being planned. The text cautions us to watch two things carefully: schedule and budget. This is good advice for any project, and it is most important for this one because protection and risk reduction affect the entire organization. With regard to project costs, make sure to account for the costs that are listed above, and again on page 304. Regardless of cost increases, staying on schedule is most important. It would be hard to explain falling victim to an exploit that we should have already had protection against.

The text advises us to follow up on our plan, after it is carried out, as well as while it is being carried out. We should make sure that the controls we asked for have been implemented correctly, that they are operating as needed, and that they are effective against the risks we want them to protect us from.

The chapter ends with some recommendations for best practices:

• stay within scope
• redo CBAs (and other assessments) as needed
• prioritize countermeasures
• include current countermeasures in our analysis
• watch for cost changes, especially in controls
• control the schedule
• follow up