ITS 305 - Security Policies and Auditing

Chapter 1, Information Systems Security Policy Management
Chapter 2, Business Drivers for Information Security Policies
Chapter 3, U.S. Compliance Laws and Information Security Policy Requirements

Objectives:

This lesson covers three chapters. It introduces the student to concepts that cover how policies are made and used, and why policies are important to an organization. Objectives important to this lesson:

1. Information systems and information security
2. Quality control and quality assurance
3. Information systems security policies
4. Governance and legal compliance
5. How policies fit in an organization
6. Threat, vulnerability, and risk
   
   
7. Business risks
8. Risk exposure vs. liability
9. Reducing risk
10. Operational consistency
    
    
11. U.S. compliance laws
12. Government drivers to implement regulations
13. Aligning policies with regulations
14. Leading practices
    

Concepts:

Chapter 1

This chapter begins with a definition. Information systems security is about protecting information and the systems that store and process it (Johnson, page 4). This is a little circular, but the meaning is clear. The next sentence is more precise. We protect against risks, because they may allow unauthorized access, use, disclosure, disruption, modification, or destruction of our assets. Perhaps we should review some terms:

• 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; a reason that makes us more likely to suffer damage from an attack
  
• Exploit - a method of attack
• Risk - the probability of a successful exploit, and the impact of that exploit (There are ways to calculate this.)
  
• 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 author tells us on page 5 that his discussions are from the formal perspective of using a life cycle for creating policies to protect our assets. The life cycle used in this discussion is from the Information Systems Audit and Control Association (ISACA). It is described as a framework, which typically means that it is meant to be customized by each user. This framework is called Control Objectives for Information and Related Technology (COBIT). The text tells us that the COBIT information systems security management life cycle consists of four domains. That is a hint to us that each of them is about one phase of the process, and each of them includes many parts.

The four domains:

• Align, Plan, and Organize
• Build, Acquire, and Implement
• Deliver, Service, and Support
• Monitor, Evaluate, and Assess

As you may notice, these four domains apply very well to system development processes, which is helpful. Policies may need to be developed for a system as it goes through the stages of development. The four domains are meant to be done in sequence, each building on the work of the previous domain.

Align, Plan, and Organize (First Domain)

Moving ahead to page 6, the author begins a discussion of the first domain: Align, Plan, and Organize. Note in the graphic on page 6 that this domain is the only one that provides input to more than one successor. It's outputs flow to the second and third domains.

The Align, Plan, and Organize domain is where we learn about the user requirements, the needs of the organization, and the goals of the organization. We should be thinking about new policies that may be needed, about managing the IT assets, and about Service Level Agreements (SLAs). The text stresses SLAs. These are agreements about the services we will receive, and about the services we will provide. In either case, the agreement should specify:

• what service will be provided?
• under what circumstances is it provided?
  
• with what frequency or standard of promptness is it provided?
  
• what level of performance is acceptable?
• how will these criteria be monitored?
• what is the recourse to be followed if this SLA is not met?
  

The text recounts a few details about the Target data breach of 2013. Read the article on Mr. Krebs' web site (you have to scroll a bit to see it) and you will see that the author agrees with the reports when he says that Target did not establish a necessary security control, or did not enforce it. This points out the necessity of having proper controls, and making sure they are being used.

This phase includes identifying the threats, vulnerabilities, and risks associated with this organization and its activities. This knowledge is handed off to the people who conduct the next phase.

Build, Acquire, and Implement (Second Domain)

This domain assumes we have obtained the requirements for our system in the previous phase. The word build might be better understood as design and create. The text points out that creating policies and controls cannot be done without proper input from the previous phase. This phase also is concerned with changes to existing systems, adding new systems, and managing the changes that will take place. The people working on this phase need to plan for and manage the changes that will take place for the systems and the people who use them.

The text lists several outputs for this phase:

• equipment is acquired and implemented
• policies, procedures, and guidelines are written
• controls are built into the systems
• teams are trained
  

Deliver, Service, and Support (Third Domain)

In this phase, risks are minimized. The text tells us that this phase makes changes to any controls, policies, procedures, contracts, and SLAs that are not working, based on observations, reports, and data on operations. This assumes that you can still make changes in contracts and SLAs. Some environments would not have those options once such agreements are in place.

The text lists several outputs for this phase:

• contracts and SLAs may be modified
• daily operations are monitored, managed, and supported
• operational problems, configuration problems, and security issues are examined and resolved

Monitor, Evaluate, and Assess (Fourth Domain)

Controls are tested and monitored in this phase. Testing takes place on the entire environment. We determine whether the controls are serving the big picture goals (business requirements, strategic goals) of the organization. The system is assessed and audited several ways:

• Self-assessment - usually performed by internal quality assurance and quality control staff
• Internal Audit - people inside the organization perform the audit and report to a controlling body or committee
• External Audit - an outside entity performs the audit, concentrating on organizational aspects that require an independent agent's view
• Regulator Audit - done when aspects of the organization fall under government regulation or legal requirements

Information Assurance

The text introduces a new concept on page 9. We are told that Information Systems Security (ISS) is concerned with protecting all of our organization's information. We are also told that Information Assurance (IA) is a subset of ISS. IA is concerned with protecting information that is being processed or being used. Why do we care about that subset? The text makes it a bit clearer by listing the "five pillars of the IA model". You will recognize most of them:

• Confidentiality - a concern of ISS and IA
• Integrity - a concern of ISS and IA
• Availability - a concern of ISS and IA
• Authentication - a concern of IA
• Nonrepudiation - a concern of IA

This makes no sense, because we have already been told that IA is part of ISS. There seems to be agreement on lots of web sites, including the Department of Defense, that IA does embrace these five concepts. So, what about the two new ones?

• Authentication - making sure of a user's identity
• Nonrepudiation - keeping records of what users do on the system

The two concepts, when taken together, mean that we have confidence about who we have allowed into our system, and we are tracking what they do, so there is no denying (repudiating) their actions. The text continues with a longer disscussion on each of the five points.

• Confidentiality - the text uses the phrase "need to know" as a measure of this concept; we do not allow access to any resource unless there is a reason for that access
• Integrity - making sure that no one changes data who has not been authorized to do so; this may be done by imposing limits on access, or by limiting the kinds or level of changes a user is allowed to make, such as restricting a user's view to data they actually own
• Availability - data must be available to authorized users when they need it
• Authentication - the security needs of the system must be matched by the level of confidence we have in a user's identity, perhaps requiring multifactor and biometric ID in some cases
• Nonrepudiation - tracking of events and files must prove that a particular user took action, authorized access or payment, or simply was on the system; this can include digital signatures being placed on everything a user processes

Governance

Governance is usually implemented as a process of approval or disapproval of all significant changes to a system. As the text explains, a good governance process will examine the rules that it enforces and recommend changes to them when they do not, should not, or should no longer apply to the requests that are being turned down. The text also points out that when the process of approval/denial takes place before an action is taken, that makes it a Quality Assurance process. If the process of approval/denial takes place after an action is taken, that makes it a Quality Control process.

A typical governance process will consist of several layers, attempting to coordinate requests with the operational and strategic needs of various elements of the organization. It is often true that a request will have to go through several layers of approval before it runs into a need that creates a conflict. Examiners on committees at each level need to have an understanding of the big picture, and of the needs of their specific organizational areas. Governance is especially important when processes are examined by government auditors, and can show that an organization is making the best effort possible to comply with laws and regulations.

Policies

I think the author started on the wrong track this time. A policy is not a document, or even a series of them, although a policy is often stored that way. A policy is a rule, or a set of rules, that affects how we want our organization and its employees to function. As the text states, 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. The list on page 16 shows us a hierarchy of 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

The set of related concepts above needs a name, so the text refers to the set of all such items that relate to each other as a policy framework. Note that the items near the top of the list are more general, and they become more focused and specific as we move down through the first four bullets. The text spends several pages telling us why policies (and the other items in a policy framework) are important and needed.

• They are the first line of defense from internal and external attacks.
• They control and manage changes to our systems.
• They provide a statement about who does what in an emergency.
• They reduce the cost of wasted or counterproductive efforts.
• They provide a means to comply with laws and regulations.

The text warns us that simply making a policy does not guarantee it is a good policy. Policies should be reviewed before and after they are put in place. New policies or revisions may be needed when processes are changed, when systems are changed, when "improvements" are made, and when problems are being resolved.

Chapter 2

Chapter 2 begins with discussion of business drivers, The most obvious one is money. The chapter presents some examples of data breaches that caused companies to spend millions of dollars in reparations to customers whose personal data were exposed. In a case like that, there is also the loss of good will and customer loyalty to be considered, which will affect future earnings for the company. When a breach is the result of improper or missing precautions, the company may be subject to fines from the government as well.

So, what do we do? As the text has already explained, we need useful security policies. We also need security policy compliance: the people in the organization need to follow the policies. People are not always thinking about security, so we need to create security controls which can be devices, procedures, or policies that are meant to increase security for an enterprise. Increasing security can also be described as decreasing risk. The text begins by saying that we could classify security controls as one of three types:

• Physical controls - These include any physical barrier, like a locked door or a fence, as well as security cameras and guards
  
• Administrative controls - These include the procedures to create security policies and the security policies themselves. Security policies are  rules about "the actions that users may do, must do, and cannot do".
  
• Technical controls - Actions that are performed by devices (technical solutions), such as firewalls denying packets.
  

The author goes on to explain that all three types of controls have the same subtypes. Deterrent and Compensating controls are not listed in this text.

• Deterrent controls - used to discourage attacks; applied before an attack; example: warning attackers that we are protected
  
• Preventive controls - used to prevent attacks; applied before an attack; example: using a firewall to block traffic for specific ports; these controls are typically automatic controls
  
• Detective controls - used to detect an attack or intrusion;; applied during an attack; example: using a Intrusion Detection System; these controls are typically manual controls
  
• Corrective controls - used to reduce damage and restore to service; applied after an attack; example: using an emergency cleaning program on a USB memory stick, so that a computer can be usable
• Compensating controls - alternative controls that are used when normal controls are not possible; applied during an attack; example: disabling switch ports to isolate devices or LAN segments
• Mitigating controls - any type of control may be a mitigatinng control if it finds or notices errors and presents a method to correct them
  

The text warns us to avoid having too many policies and too many controls. People will be lost if there are too many to remember, and they will have little chance of complying if the the policies and controls are too hard to follow. Make fewer policies, and make controls easy to use to get better compliance.

The text tells us that we will benefit from a security awareness program for our employees. Employees whose daily jobs do not address security issues need to be reminded about the rules we need them to follow. The text offers a list of principles that apply to employee training and awareness programs:

• Repetition - reminding users about security issues from time to time helps them stay aware of them
• Onboarding - new hires should be made aware of security policies when they start their jobs
• Support - policies should be supported from all levels of the organization, starting at the top
• Relevance - tell employees why we have rules, not just that we have them
• Metrics - measure your success by asking employees what they know or have learned
  

The text explains that a reduction in risk will occur with a successful security awareness program.

The text spends some pages talking about various kinds of assets to protect. We should assume we want to protect all of them. Let's skip to another objective on page 45. We are told that a business liability happens when a business cannot meet its obligations. These obligations come in two types: legal obligations and promised commitments. Legal obligations are, of course, things the organization is required to do by law. Promised commitments are related to explicit or implicit contracts, such as failing to provide a promised product or service.

The text tells us we should have policies to protect the company from the actions of employees that may create a liability. There are five recommended steps on page 46 that support this concept:

• Policy - Have clearly stated policies about customer information that inform our employees of their responsibilities.
• Enforce - The text says to "express strong disapproval when policy is not followed". I think we need to clearly state that  there is progressive discipline that will be applied when employees do not follow policy.
• Respond - Incidents that cause a breach of security require a quick and effective response to limit damage, and to correct problems when they arise.
• Analyze - Determine the cause of problems, and resolve those causes.
• Educate - Train employees in their duties, and in security concepts that affect their jobs.
  

One of the critical policies you should have is an Acceptable Use Policy, which tells employees what they are and are not allowed to do with the assets of the organization, such as telephones, cameras, computers, and links to the Internet.

The chapter ends with some thoughts about operational consistency. There should be policies that address doing things well and doing them the same way every time (assuming we have the kind of operation that needs such a policy).

• Manage - Manage how processes are done, and respond to deviations from processes
• Measure - Measure our outputs, such as volume, consistency, quality, waste, production cost
• Review - Assess processes and products to make sure both are acceptable
• Track - Report, analyze, and record defects, errors, and incidents
• Improve - Make changes to policies and procedures as needed
  

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 the following pages, the text recommends the selection of an approved security framework, or model, on which to base the creation of the framework that will be used in your organization. It mentions COSO, COBIT and ITIL.ITIL is also the last topic in the chapter. It is recommended for its relevance to IT organizations in general.

Before the end of the chapter, we are shown a few industry 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.