ITS 3050 - Security Policies and Auditing

Managing Risk in Information Systems
Chapter 1, Risk Management Fundamentals
Chapter 3, Maintaining Compliance

Objectives:

This lesson presents an overview of risk management in chapter 1, and material about compliance with laws, regulations, policies, standards, and guidelines. In chapter 3, the text discusses required compliance with various laws and company rules. Objectives important to this lesson:

1. Terms associated with risk management
2. Components of risk
3. Importance of risk management
4. Risk identification
5. Risk management techniques
   
   
6. US laws about compliance
7. Regulations
8. Organizational policies about compliance
9. Standards and guidelines

Concepts:

Chapter 1

Our first text defines risk as the likelihood (probability) that a loss will occur. This could be a data loss, a financial loss, an equipment loss, or any other kind of loss of an asset that our organization cares about. Realize that a loss may be complete or only partial, permanent or only temporary. Here are some of the terms the author uses in this discussion:

• Asset - information, property, people or anything else that we care about
• Threat - a potential form of loss or damage; many threats are only potential threats, but we plan for them because they might happen
• Threat agent - a vector for the threat, a way for the threat to occur; could be a person, an event, or a program running an attack
• Vulnerability - a weak spot where an attack is more likely to succeed
• Exploit - a method of attack
• Incident - a threat that has actually become a reality, an event that is or has caused loss to our organization
• Probability of occurrence - the odds that a particular threat will exploit a particular vulnerability successfully
• Impact - the kind (e.g. money, productivity, customer confidence) and scale (usually expressed in dollars) of loss that an occurrence would have on an organization; a high score here means we should concentrate some of our limited budget on protecting a particular asset
• Risk - A more formal definition of risk uses some of the terms above. It says risk is the probability that a particular threat will exploit a vulnerability causing harm to an organization.
  
• Control - A process that we put in place to reduce the impact and/or probability of a risk
• Policy - a plan that influences decisions;
  a guiding principle for decisions and actions;
  a set of rules about what actions are acceptable and what actions are unacceptable

The chapter continues with a discussion of types of risk and associated losses that may occur when those risks become reality, when associated business functions are compromised. Page 4 discusses several business functions that have a risk of loss. Each may have other risks associated with it, in addition to the ones mentioned in the text's examples.

In the image below, we see an NIST chart showing an application of several terms associated with risk management.

Page 5 discusses compromises that can occur to business assets. As asset is further defined in this section as anything that provides value to the organization. Two value types are mentioned:

• tangible values - usually expressed as a dollar (or other currency) value, the amount of income that assets produce over a specific time are tangible; values are generally tangible if you can associate a specific cost to their loss
  
• intangible values - There is a value to having a good reputation, to having happy customers, to having employees who are proud to work for you, but each of these is hard to assign an actual profit or loss value. These are intangible values. We recognize that they exist, but we are not sure of their worth. Organizations seem to either put faith in these values and cultivate them, or pay no attention to such things and pursue only tangible rewards.
  

Assets themselves can be classified as tangible (physical assets, including data and intellectual property) or intangible (reputation, service ratings, customer loyalty, service to prestigious customers). Note that assets of both types can have values of both types.

The text discusses the cost of controls, processes and procedures that protect our assets and reduce or remove risks. The text also calls controls countermeasures, which may explain the idea more clearly to some of you. Sometimes you institute controls, and sometimes you don't, depending on the costs incurred with each option. When protection costs more than you were going to lose by leaving things alone, you may have to write the loss off as the cost of doing business. Some related terms from page 6:

• profitability - revenues minus costs; what will we bring in, less what it costs us to do so
• survivability - can the organization survive the loss that a particular event will incur?
• out of pocket cost - the cost to reduce a risk with a particular control
• lost opportunity cost - if money is spent on a control, that same money cannot be spent for another purpose, which becomes the lost opportunity, the thing we did not do because we did not have the money to do it
• future cost - the cost to maintain the control over time, which may come from licensing, subscription, or maintenance of a system
• client/stakeholder confidence - think of this as related to customer good will, which can be lost if our organization has a documented loss due to an attack
  

The chapter continues with the idea that we can consider an IT infrastructure to have seven parts, each of which may address the needs of different parts of the organization, or the needs of different kinds of users. The text refers to these seven parts as seven domains.

• User domain - any user of our systems falls in this domain, whether inside or outside our organization
  
• Workstation domain - not just computers, but any device our users use
  
• LAN domain - each LAN and the devices that make a LAN work
  
• WAN domain - the system that links devices across long distances; typically this is the Internet which is used by most businesses
  
• LAN-to-WAN domain - the infrastructure and devices that connect our organization's LANs to the WAN system
• Remote Access domain - the technologies used by our mobile and remote users to connect to their customary resources; can include VPN solutions and encryption technology
• System/Application domain - technologies used to actually conduct business functions, as opposed to making connections of various types

The text continues on page 12 with an introduction to the most common acronym in security: CIA, In this case, it does not stand for the name of a federal agency.

• Confidentiality - information should only be accessible to users who have been granted access to it for valid reasons. Only authorized users can access data if it is protected properly, and if authorized users do not violate security policy.
• Integrity - data may not be changed except by authorized users or processes. This means that data must be protected from alteration, deletion, or other changes to its intended form.
• Availability - authorized users can access data when they need to do so. Availability includes the idea that proper access methods are provided to only to authorized users, not to everyone.

The text discusses vulnerabilities in the context of their being weak spots in a system that can be used to attack one or more of the big three aspects (CIA) of that system. As noted above, the word impact means the level of damage that is done to the organization by an attack. On page 13, the text presents a list of five terms used in the National Institute of Standards and Technology's Special Publication 800-30. The terms and their definitions are used to classify the severity of a an attack's impact.

• very low - negligible adverse effect; the effects are small and not noticable
• low - limited adverse effect; damage is minor and critical business functions are degraded
• moderate - serious adverse efffect; damage may be significant and critical business functions are significantly degraded
• high - one severe or catastrophic effect; there may be major financial loss and and/or serious injury to staff
• very high - multiple severe or catastrophic effects; see above
  

The effects and the causes of risk are concern for everyone in an organization. The systems, the users, the policies, and the threat agents all affect whether there will be a successful attack on our organization. Note in the graphic below that there are many hazards that can affect an organization, some of which do not involve the actions of an attacker.

Page 14 reviews a common process flow that leads to what we hope is a protected state for our organization. Different texts will have different versions of this, but they all have the same intentions.

• assess risks
  • identify assets, including IT assets
  • identify and prioritize threats and vulnerabilities
  • identify liklihood that each vulnerability will be successfully exploited by each threat: risks
  • identify the impact of each risk
• identify risks to manage
• select controls
• implement and test controls
• evaluate controls over time

The text elaborates on the steps above, noting that some risks have a very small impact, a very small probability of occurrence, or both. We should not assign a high priority to protection against such risks, especially if the cost of such protection is high. Security budgets, like any other budgets, have limitations, so we must protect the most valuable assets first, against the most likely risks, and work our way down the list until we run out of money.

Page 15 offers a simplified method of assigning a score to a threat that puts an asset at risk. Assign the threat a probability of occurring, which will be a percentage. Assign the asset a relative value, say on a scale of 1 to 100. Multiply the two values, and you get a relative impact score for that combination of threat and asset.

On pages 16 and 17, the text discusses different views of risk that vary according to a person's role in an organization. This is not terribly useful expect to note that some people care more about it than others.

Page 20 gives us a short list of sources of information that may tell us about vulnerabilities and attacks against them.

• audits
• certification and accreditation records
• system logs
• prior events
• trouble reports
• incident response team records

The text also offers some advice about common problems associated with each of the seven domains mentioned in the beginning of the chapter:

• User domain - social engineeering attacks begin with people, such as any of our system users
  
• Workstation domain - computers that are not patched, and those whose antivirus or antimalware programs are not regularly updated are vulnerable
  
• LAN domain - network data needs protection, typically with access controls as the first line of defense
  
• WAN domain - this domain contains our public facing devices, such as our web servers, which are primary targets for attackers
  
• LAN-to-WAN domain - this domain provides our users with access to the Internet, including all the dangers that lurk in it
• Remote Access domain - remote users may be using their own equipment (such as storage media, smartphone, and personal computers), which may have been exposed to viruses and malware without the user knowing about it
• System/Application domain - a common attack ploy is to inject SQL code into forms, web pages, and entry fields in programs that our users and customers are meant to use

Starting on page 22, the text closes the chapter with a discussion of some classic methods of handling risks. An organization need not use the same method for every risk. A mixture of methods may be best when there is reason to use one. These methods are not the only ones ever used, but they represent four well known strategies.

• Risk avoidance - make every effort to avoid your vulnerabilities being exploited; make the attack less possible, make the threat less likely to occur; avoid risk by avoiding the activity associated with the risk, and by providing an active defense against it; the text calls this a business decision
  
• Risk transference - in general, letting someone else worry about it
  In the ITIL model, this is included in the definition of a service:
  "A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." 
  A reader might misunderstand this statement, thinking that the customer does not pay anything. That is not the case. An IT service provider would assume the costs and risks of an operation in return for the customer's payment for the service. This can be done in-house or by outsourcing.
  
• Risk mitigation - this method seeks to reduce the effects of an attack, to minimize and contain the damage that an attack can do; Incident Response plans, Business Continuity plans, and Disaster Recovery plans are all part of a mitigation plan
  
• Risk acceptance - this counterintuitive idea makes sense if the cost of an incident is minimal, and the cost of each of the other methods is too high to accept; the basic idea here is that it costs less just to let it happen in some cases, and to clean up afterward; this can also be the case when the risk cannot be managed other than to be aware of it; the text says this is either a business or a technology decision
  

Chapter 3 

The text discusses a few laws that are relevant to information system security. Be aware that there are many others.

• 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.
• Gramm-Leach-Bliley Act (GLBA, 1999) - also called the Financial Services Modernization Act; deregulated banks and financial services, allowing each institution to offer banking, investments, and insurance services
  Included three rules that affect privacy. The Financial Privacy Rule allows people to opt out of having their data shared with partner companies, but it is usually implemented so that it is easier to allow the sharing. The Safeguards Rule requires that companies have data security plans. The Pretexting Rule tells institutions to implement procedures to keep from releasing information to people who are trying to gain information under false pretenses (pretexting). (They had to be told to do that?)
• 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
• 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.
  

There are many other such laws. The list above only deals with some of the ones in the United States.

In addition to laws, there are regulations that must be followed. What is the difference between a law and a regulation? You might have to be a lawyer to care, but I will try. In the United States, most laws are created by legislative branches of government, either at federal level or by the legislature of a state, its senate and house of representatives. Regulations are created by agencies in the executive branch of government, and often they are rules about the enforcement of a law. Regulations must be followed as laws must be followed, so it is important to know about the ones that affect your business and your life.

The text mentions that the IT industry is subject to regulations created and enforced by several entities listed on page 64:

• Securities and Exchange Commission (SEC, federal)
• Federal Deposit Insurance Corporation (FDIS, federal)
• Department of Homeland Security (DHS, federal)
• Federal Trade Commission (FTC)
• State Attorneys General (AG, in each state)
• U.S. Attorney General (U.S. AG, federal)
  

A policy is a rule, or a set of rules, that affects how we want our organization and its employees to function. The idea behind a policy may start with a principle, which is often a broad, general statement of what we believe to be right, true, or beneficial. A policy is more detailed, and more specific about what we expect our people to do. Related concepts:

• Principle - a general statement about what we believe or require in our area of authority (we will use only two computer vendors at a time); what we expect
• Policy - rules about the conduct of our organization with regard to particular actions (we will limit ourselves to particular models chosen by the IT department); how we will approach the expectation
• Standard - a method or process that may be procedural or technical (orders are to be placed by approved requesters within each work area); what steps are to be followed to assure general compliance with policy
• Procedure - a detailed set of steps to follow to be in compliance (requests are to be made to your manager, who will forward approved requests to your authorized requester); variations or limitations that apply to specific work areas, to be followed if they apply to your area
• Guideline - a suggested addition to any of the items above that is recommended but optional (submit your requests two weeks before the end of a quarter to allow processing time); do this to make it work better
• Definitions - when there is room for misinterpreting any of the above items, definitions should be offered to clarify their language and intent; if you didn't understand something, read this

It is important to know which kind of constraint you are bound by, as explained by Captain Barbossa.

Policies can also be suggested (or required) by trade associations and influential groups who propose them to the general public. They have the power of policies if they are adopted as suchby an organization, but they can be implemented as standards that associate with an existing company policy. On page 69, the text lists several standards proposed by several different entities, and several entities associated with standards.

• 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 cardholder data, manage vulnerabilities, and have strong controls. Obviously, this standard has not always been followed.
• Statement on Standards for Attestation Engagements No. 16 (SSAE16, 2010) - A standard for audits that includes standards for security controls. A Type I audit reviews controls, but a Type II audit tests the controls as well.
• COSO - a financial view of risk, useful for accounting firms or departments
• COBIT - connects business requirements to technology controls, but is not specific about implementing those controls
• ITIL - created by the British government to manage their IT needs, it is focused on the way an IT organization delivers services; it has grown in recent years to cover more types of organizations
• ISO - contains rules and procedures for multiple industries; it is a good choice for most enterprises, being specific about IT controls, but it is less detailed about management of them
• NIST (National Institute of Standards and Technology) - Guidelines from the federal government for government agencies and others
• Department of Defense (DoD) Information Assurance Certification and Accreditation Process (DIACAP) - A hideous acronym offered in the text that has been replaced by the DoD Risk Management Framework (RMF). See this page for information about the newer RMF process.
  

You should review the information on the items in this list that fills the rest of the chapter