Introduction
The growth in the quantity of sensitive data collected and processed by public and private sector entities has moved information security to the forefront of public policy. Security breaches and system damage involving sensitive data can result in costs to recover data and ensure that it is not used for illegitimate purposes. In addition, both public and private sector entities can suffer from a loss of public trust that can result in financial losses due to decisions to take business elsewhere, as well as a general diminishing of public faith in the government that is supposed to serve the best interests of the public. Sensitive data can be used for activities such as identity theft or making adverse employment decisions based on medical history, for example, all of which damage the individuals to whom the data relates.
This increase in the amount of sensitive data, combined with a series of embarrassing and injurious security lapses in both the public and private sector, has led to the passage of a series of laws in the United States and internationally intended to address the need to ensure that sensitive data is kept private and secure. While these laws provide guidance and minimum standards for public and private sector entities to follow in securing their systems, they also add an increased managerial and financial burden of ensuring compliance. Implementing additional security controls also increases the costs associated with managing systems and achieving business objectives. Management's task then, is to implement a system of controls that keeps sensitive data secure in a cost-effective manner by matching the level of risk associated with a system and its data with the cost of the controls implemented. As organizations attempt to improve security and bring their systems into compliance with new legislation and other requirements, risk assessment tools taken from project management are valuable in ensuring that these projects achieve their objectives.
Security Risks
Risks to information security can be divided into external threats that come from outside of the organization, and internal threats that come from inside the organization. External threats include, for example, viruses and other malware introduced to an organization's network through email or web browsing, hack attacks, and social engineering by outsiders. Internal threats include sabotage or fraud affecting information systems by employees, vendors, or contractors of a company, and errors and negligence, including failure to adhere to established procedures. In the 2007 Computer Crime and Security Survey, the Computer Security Institute, in cooperation with the Federal Bureau of Investigation, found that 37% of respondents to the survey attributed more than 20% of their organization's financial losses from security incidents to insiders (CSI/FBI, 2007, p. 11). The CSI survey reported a total of $66,930,950 in losses for 2007 from 194 respondents (CSI/FBI, 2007, p. 15). Financial fraud was the category with the highest dollar amount lost ($21,124,750), followed by virus contamination ($8,391,800) (CSI/FBI, 2007, p. 15). The most common categories of incidents among 436 respondents were abuse of Internet access by insiders (59% of respondents reporting such incidents), virus incidents (52%), and theft of mobile devices, including laptop computers (50%) (CSI, 2007, p. 13).
Survey of Legislation
The European Union and the United States have adopted different approaches to legislation on information privacy and security. The United States has favored passing legislation in a somewhat reactive manner in response to specific problems or crises. This has resulted in a patchwork of legislation that strives to protect the security of certain kinds of information. The private sector is largely allowed to regulate itself according to market concerns and profitability. The majority of government-issued legislation and guidance on information security applies primarily to government agencies (Salbu, 2002, pp. 665–667). President Bill Clinton and Vice-President Al Gore laid out in their 1997 document, A Framework for Global Electronic Commerce, general principles under which the United States should participate a global technological business infrastructure, among them that the private sector should lead the effort, and that governments should avoid undue restrictions on electronic commerce (Clinton & Gore, 1997).
In contrast to the legal patchwork the United States has put into place to guide information security efforts, the European Union's legislative approach to information security is founded on a single directive, “Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data.” The European Union issued this directive in 1995 in response to the increase in the amount of data being collected and in anticipation of further increases, as well as the need for transport of this data across national boundaries within and outside of the European Union in pursuit of advancement in the scientific and business worlds. Directive 95/46/EC seeks to provide a minimum acceptable standard for ensuring security of data. Member states are then responsible for passing and implementing national laws that meet or exceed these standards (European Parliament, 1995).
Significant Security and Privacy Legislation (United States)
Health Insurance Portability and Accountability Act (HIPAA)
The Health Insurance Portability and Accountability Act was passed by the United States Congress in 1996. The Act directed the Secretary of Health and Human Services to “adopt standards for transactions and data elements for such transactions to enable health information to be exchanged electronically,” and to adopt security standards and safeguards for keeping private data private (HIPAA, 1996).
The requirements of HIPAA apply to covered entities, which include:
- Health plans
- Health care clearinghouses
- Health care providers who transmit electronic health information (Federal Register, 2003, p. 8375).
Enforcement of HIPAA is through two regulations, the Privacy Rule and the Security Rule. The Privacy Rule applies to all individually identifiable health information, whereas the Security Rule applies only to health information stored in electronic format (EPIC, 2007).
Gramm-Leach-Bliley Act (GLBA)
The Gramm-Leach-Bliley Act was primarily designed to modernize financial services through abolishing and relaxing regulatory restrictions on merging commercial banks, stock brokerage, and insurance services under one company. It was also passed in part to allay concerns from the European Union about the risks associated with member states exchanging data with United States companies who may have more lax security procedures under the US regulatory framework. GLBA applies only to financial institutions, meaning businesses that are involved in banking, insuring, stocks and bonds, financial advice, and investing (EPIC, 2005).
GLBA makes three main requirements related to security. The requirements apply only to disclosures and sharing of consumer information. They do not apply to information relating to other businesses. The requirements are:
- Financial institutions must keep personal financial data secure.
- Financial institutions must provide notice to consumers prior to sharing financial information with any unaffiliated party or business, and provide an option to opt out.
- Financial institutions must disclose their privacy policies to consumers (GLBA, 1999).
The Sarbanes-Oxley Act (SOX)
While Sarbanes-Oxley has in part fueled an extensive interest in information technology controls and information technology audit after its passage, the law in fact makes no specific requirements related to information security. SOX section 404 requires a company's annual report to include a statement of management's responsibility for establishing and maintaining an adequate system of internal control for financial reporting, and to “contain an assessment of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.” (Public Law 107-204, 2002). Rules promulgated by the Public Company Accounting Oversight Board further require auditors to consider the effect of information technology controls on the overall adequacy of the internal control structure over financial reporting. However, specific directives on controls that should be implemented are left to the judgment of the auditor in consultation with management (PCAOB, 2007, p. 406).
Federal Information Systems Management Act
The Federal Information Systems Management Act was passed in 2002. The Act established requirements for the implementation of information security controls on the basis of risk assessments for systems managed by Federal agencies and for Federal programs. The Act further requires annual assessments of the efficacy of the security controls in place, and for agencies directors to report the results of their assessments to the Director of the Office of Management and Budget (OMB) for systems that are not classified as national security systems. Reports must be issued to the Director of the Central Intelligence Agency or the Secretary of Defense for national security systems. FISMA also requires Federal agencies to comply with National Institute of Standards and Technology guidance, including a certification and accreditation process (Public Law 107-347, 2002).
European Union Privacy Directives
Directive 95/46/EC, which is the basis of the European Union's approach to information security, grants privacy as a specific right to citizens of the European Union and seeks to provide a minimum acceptable standard for ensuring data security. It specifies several rights of individuals regarding their personal data, and responsibilities for the entities that collect and process it. The Directive requires that entities that collect and process personal data must do so only for specified and legitimate purposes, must take measures to ensure the data is accurate, and must keep the data secure (European Parliament, 1995).
In 2000, the European Union passed Decision 2000/520/ED to address concerns about the differing, and generally weaker, security standards in place in the United States. Because European Union Member States can only transfer data to a country outside the European Union if that country has security measures in place to ensure the same standard of protection to the data as in the European Union, the European Union was concerned that the requirements of Directive 95/46/EC might damage trade between Europe and the United States. The Decision provides that US companies who comply with its provisions may be regarded as a safe harbor for the transfer of data from European Union member states (European Parliament, 2000)
Directive 2002/58/EC of the European Parliament built on 95/46/EC to clarify the data security rights related to the processing of personal data and the protection of privacy in the electronic communications sector. The Directive requires member states to prohibit collecting and retaining location or traffic data related to communications by electronic means that would allow the persons participating in the communications to be identified (European Parliament, 2002).
Risk-Based Approach to Information Security
Public and private organizations may have responsibilities to comply with multiple laws and regulations. Further, they may have either legal or pragmatic obligations to ensure that their business partners and contractors comply with security requirements related to one or more laws and regulations. The costs associated with weak security can be quite high when a lapse occurs, due to the costs of responding to the breach, complying with regulatory requirements for disclosing and reporting the breach, the loss of reputation and trust among customers or constituents, and loss of business. Implementing an effective security program can be very expensive, especially for larger organizations, due to the need to acquire hardware and software to implement technical security measures, as well as staff to manage the administrative and technical aspects of security. The task of security management, then, is to strike an appropriate balance between the cost of the security controls implemented and the risks associated with the data and systems protected. In order to ensure this appropriate balance, security programs should be developed on the basis of a risk assessment.
Before discussing how to conduct a risk assessment, it is necessary to understand what is meant by risk. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines risk as “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives” (PMI, 2004, p. 373). While this definition gets close to what is needed for this discussion, it is not entirely adequate.
The Information Systems Audit and Control Association's IS Auditing Guideline: Use of Risk Assessment in Audit Planning lays out a commonly used framework for considering risk in performing audits. This framework divides risk into three components, of which two are useful for the current discussion. The first type of risk is inherent risk. According to the Auditing Guideline, inherent risk is “the susceptibility of an [area] to error which could be material, individually or in combination with other errors, assuming there were no related internal controls” (ISACA, 2000). To provide a couple of examples to make this concept clearer, an information system containing Social Security numbers, addresses, bank accounts numbers, and medical records for several million customers would be regarded as having a high level of inherent risk. That is, if the system were breached, the consequences would be severe. A single user database containing telephone and email contact information for a few hundred business contacts for an executive would have a much lower level of inherent risk.
The second type of risk identified by the Auditing Guideline is control risk. The Guideline defines control risk as “the risk that an error which could occur in an [area], and which could be material, individually, or in combination with other errors, will not be prevented or detected and corrected on a timely basis by the internal control system” (ISACA, 2000). In essence, control risk as it relates to information security is a function of the quality of your security processes. For example, a system which allows users to connect without the user of a uniquely identifiable user ID or a password, makes no record of connections, and is accessible from terminals in uncontrolled public areas would be regarded as having an extremely high level of control risk. A system with login possible only from specified terminals kept physically secure with a controlled access system, requiring login with a unique user ID, a complex password that must be changed every 45 days, and that creates logs of all access attempts that are regularly reviewed would be considered to have a low level of control risk, assuming other controls were also strong.
A more intuitive explanation of risk comes from the Institute of Internal Auditors' Standards for the Professional Practice of Internal Auditing. The IIA defines risk as “the possibility of an event occurring that will have an impact on the achievement of objectives. Risk is measured in terms of impact and likelihood” (IIA, 2007). This can also be simply expressed as a formula:
RISK = (Probability of a loss) X (Consequences of a loss)
While the probabilities and consequences often cannot easily be expressed in quantitative terms to allow actual calculation of the formula, this provides a useful framework for considering the concept of risk as it relates to a security risk assessment.
Identify all data under the organization's control: The first step in performing a risk assessment is to identify all data under the organization's area of responsibility. In organizations with centralized information systems operations and with a minimum of outsourced services, this may be a simple task. In other cases, where responsibility for managing information technology or business functions have been outsourced to vendors, or individual departments have total or partial responsibility for developing and managing their own systems, the task can become much more complicated. The risk assessment team may need to query information systems management and business function management. Review of existing documents may also provide valuable information on the systems that are in place. In instances where services have been contracted out, the ability of the entity to influence the security controls will be more limited, and will need to be primarily accomplished through writing security requirements into the contract, along with a process for monitoring adherence to contractual requirements.
Assess the effect of a loss if a breach were to occur: This step corresponds essentially to determining the level of inherent risk associated with each system or data set. Ideally, one would like to express the effect of a loss in terms of dollars or another monetary unit, for the sake of comparability. However, a monetary figure may be hard to arrive at, and in truth may misstate the actual losses associated with an actual security failure. The effects of public relations disasters and the time spent responding to them, as well as the negative effects on constituents if lost data is obtained and used for criminal activity need to be considered in assessing the risk level associated with a data set or system. This paper will not go into a detailed discussion of possible methodologies for measuring and quantifying security risks. A subjective determination of the risk level as high, medium, or low is often adequate.
Assess threats and vulnerabilities: According to the National Institute of Standards and Technology, a threat is “the potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability” (NIST, 2002, p. 12). More simply, a threat is something that could cause damage to a system or a business function it supports, including unauthorized access to data. A vulnerability is “a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy” (NIST, 2002, p. 15). In other words, a vulnerability is a weakness in security controls that allows a threat to cause damage. This step is roughly equivalent to determining control risk.
Developing a list of threats and vulnerabilities for each system and that system's associated level of control risk should be undertaken with the cooperation of security management, information systems management, and business function management. Outside consultants or auditors may also be engaged.
Determine residual risk and prioritize risks: Residual risk for the purposes of this discussion is the risk that the exercise of a threat will result in a significant adverse impact on information systems or business operations. Residual risk is stated by NIST as the risk that remains after the implementation of controls (NIST, 2002, p. 39)
The process of determining residual risks and prioritizing risks should be virtually synonymous with determining which systems the organization will put its emphasis on when developing policies and implementing controls. Table 1 shows how residual risks might be assigned to systems and resources devoted to improving security using a simple high, medium, low system for rating risk levels. For example, if a system has been rated as having a high level of inherent risk, and a high level of control risk, the organization should want to invest significant resources into enhancing the security controls over that system in an effort to reduce the level of control risk by eliminating vulnerabilities. If a system has been rated as having a low level of inherent risk and a low level of control risk, it is probably not worthwhile to invest additional resources to improve the security of that system. In making resource allocation decisions, the organization should attempt to ensure that their allocation will ensure compliance with all relevant laws, regulations, and contract requirements.
Table 1 – Determination of Residual Risk
| Inherent Risk | ||||
| Control Risk | High | Medium | Low | |
| High | High residual risk: Focus resources here | Medium residual risk: Devote resources here next. | Low residual risk: Devote few, if any, resources here | |
| Medium | Medium residual risk: Devote resources here next | Medium residual risk: Devote resources here next | Low residual risk: Devote few, if any, resources here | |
| Low | Low residual risk: Devote few, if any, resources here | Low residual risk: Devote few, if any, resources here | Low residual risk: Devote few, if any, resources here | |
Develop a policy framework: While often viewed as an onerous exercise in generating paperwork for auditors, developing and communicating policies and procedures is an important part of establishing an effective security program.
The value of having written, complete policies and procedures is simply that if your users do not know what is expected of them, they probably will not do what is expected of them. The policies and procedures provide a basic standard against which security features will be configured, and provide guidance to users on how to use systems.
Procedures must be communicated to be effective. They should be easily available to all employees who are responsible for following or enforcing them. Training on security policies and procedures should also be considered and implemented, along with requiring employees to acknowledge through written certification that they have read and understand the procedures.
Develop and implement technical solutions to protect data: This step involves the selection of hardware and software solutions that both accomplish the business objectives for which the systems were designed and provide an adequate and cost-effective means of meeting security objectives. The comparison of the adequacy of any specific products for security is beyond the scope of this paper, and will not be attempted here. The main point to take away from this discussion is that specific technical solutions should only be selected after a risk assessment has been conducted to ensure that the solutions implemented are in line with the security objectives of the organization.