CHAPTER 14 IT Risk Analysis and Risk Management

Overview

This chapter integrates most of the concepts discussed in previous chapters into an overall framework to deal with information security. The previous chapters have taken a bottom-up approach to security, discussing individual concepts in detail. This chapter takes a top-down approach, beginning with the concerns of society and top management as they relate to information security. These constituencies are less concerned with the technology and more interested in minimizing the economic impacts of information security. The phrase “IT risk management” organizes all issues associated with information security, utilizing inputs from both management and technology experts.

Issues important to top management typically receive lot of attention from many quarters. Since top management cares about risk management,¹ a number of popular IT risk-management frameworks have emerged. We provide a quick tour of these frameworks. We then distill ideas from these frameworks to create a risk-management framework that is consistent with the standard frameworks we have used for other related concepts in earlier chapters. At the end of this chapter, you should know:

• The relevance of risk management to top management
• IT risk-management frameworks
• Risk analysis – identification and assessment
• Risk management – mitigation, preparation, and response

Introduction

Risk is a quantitative measure of the potential damage caused by a specified threat. In prior chapters, we have built up the knowledge base required to analyze and manage risks. In Chapter 6, we have discussed threats in detail. We can build on that idea in this chapter to discuss an issue that draws the attention of top management – risk management.

Since risk management is driven by top management concerns, in this introductory section, we set the topic of risk management within the overall context of managing an organization. We then discuss the standard risk-management framework developed by NIST to guide IT risk-management activities.

Risk management as a component of organizational management

The performance of an organization is assessed using some measure of profitability.² More profitable organizations are more valuable than less profitable organizations. Accordingly, the primary focus of managers is to maximize their organization's profits. We may write this managerial concern as:

Manager's decision problem = max (profit) = max (Revenues − cost)

Managers can accomplish this goal by using some combination of increasing revenues (generally by raising prices or selling more units) or by reducing costs. Much of the management literature and most of the typical MBA curriculum are devoted to guiding managers to reach these goals. However, when running organizations on a day-to-day basis, managers find unusual things happening all the time, many of which can significantly affect the organization's profit-maximizing equation. For example, we have seen earlier how TJ Maxx made provisions for $118 million to deal with the fallout from its credit card incident. Since these incidents can affect the organization's profits, they need to be managed. At a very high level, managing the financial impacts of unusual events is called risk management. To represent this, we can modify the manager's decision problem as:

max (Revenues − cost − Δ), where Δ is the impact of unusual events on the organization.³

There are broadly two approaches to risk management: (1) making risks (Δ) predictable and (2) minimizing and preparing for these risks.

The standard approaches for making risks predictable are insurance and hedging. These are some of the most important activities of the financial sector of the economy. For example, buying flood insurance for your datacenter makes the financial impact of flood events predictable, equal to the annual premium paid to buy the insurance. While the idea sounds unusual, you should know that this is an important component of IT risk management. We (the authors) are not experts in designing and pricing financial instruments, so we leave the details of this approach to the experts in finance. However, we would like to emphasize that top management understands this approach well and always considers it seriously. So, do not be surprised if you hear the term “insurance” in the context of IT risk management.

That leaves us with minimizing and preparing for risks. This is the approach we discuss in the rest of this chapter.

With this background, we will now look at the standard IT risk-management framework developed by NIST.

Risk-management framework

A framework is a structure for supporting something else. In the management literature, frameworks are used when a large number of ideas are to be organized in a manner that can be understood and memorized by many people, i.e., management frameworks support the organization of related concepts to accomplish a goal of interest.

Many frameworks are popular for risk management, including CERT's OCTAVE, ISO 27002 from the International Standards Organization, and the NIST 800-39 guidelines on managing information security risk. In addition, leading vendors such as Microsoft⁹ and Google¹⁰ publish their own recommendations for information security risk management. All of these guidelines present similar ideas and represent the results of the collective efforts of the best minds in the industry to manage IT risks. Any of these guidelines would be an excellent basis to develop an information risk-management plan for your organization.

Our preference in this book is to present ideas in a consistent manner across chapters. We believe it facilitates comprehension and memorability. We find the NIST 800-39 guidelines to be the most suitable for our purpose since it is very compatible with the way we have presented information in earlier chapters. Accordingly, we base the rest of this chapter on these guidelines. We integrate many of the ideas covered in earlier chapters (such as the threat model and the disaster life cycle) within the NIST risk-management framework. For completeness, toward the end of this chapter, we also provide a quick overview of the other popular frameworks.

The NIST 800-39 framework

The NIST recommendations for managing information security risk are published as special publication 800-39.¹¹ The current version is dated on March 2011. The 800-39 guidelines were developed with inputs from the Civil, Defense, and Intelligence Communities to provide an information security framework for the federal government. The 800-39 guidelines (and the discussion in this chapter) are very general and do not attend to the specific concerns of high-security environments such as military bases or special laws such as HIPAA. Those environments will use more stringent procedures than those suggested by NIST 800-39. However, the 800-39 framework is very useful for the majority of commercial and non-profit organizations and hence are suitable for our purposes. If you work in a high-security environment such as a military base or bank, the institution will provide you with additional risk-management guidelines specific to that environment.

IT risk is defined as the risk associated with the use of information systems in an organization. This is one of the many risks facing organizations. NIST recognizes that risk management is not an exact science. It is the best collective judgment of people at all ranks and functions within an organization about suitable measures to protect the organization. The 800-39 framework recommends that senior leadership be involved in IT risk management, and that IT risk management be integrated in the design of business processes.¹²

IT risk-management components

The 800-39 framework identifies four components of IT risk management – (1) the risk frame, (2) the risk assessment, (3) the risk response once the risks are assessed, and (4) ongoing risk monitoring based on the experiences gained from risk response activities. These are organized as shown in Figure 14.1.

The risk frame establishes the context for risk management by describing the environment in which risk-based decisions are made. This clarifies to all members in the organization the various risk criteria used in the organization. These criteria include (i) assumptions about the risks that are important; (ii) responses that are considered practical; (iii) levels of risk considered acceptable; and (iv) priorities and trade-offs when responding to risks. Risk framing also identifies any risks that are to be managed by senior leaders/executives.

Within the context of the risk frame, the risk assessment component identifies and aggregates the risks facing the organization. Recall our definition of risk as a quantitative measure of the potential damage from a threat. Risk assessment develops these quantitative estimates by identifying the threats, vulnerabilities in the organization and the harm to the organization if the threats exploit vulnerabilities. We discuss risk assessment in greater detail in the next section.

Risk response addresses how organizations respond to risks once they are determined from risk assessments. Risk response helps in the development of a consistent, organization-wide, response to risk that is consistent with the risk frame. Following standard business procedures, risk response consists of (i) developing alternative courses of action for responding to risk; (ii) evaluating these alternatives; (iii) selecting appropriate courses of action; and (iv) implementing risk responses based on selected courses of action.

Risk monitoring evaluates the effectiveness of the organization's risk-management plan over time. Risk monitoring involves (i) verification that planned risk response measures are implemented; (ii) verification that planned risk responses satisfy the requirements derived from the organization's missions, business functions, regulations, and standards; (iii) determination of the effectiveness of risk response measures; and (iv) identification of required changes to the risk-management plan as a result of changes in technology and the business environment.

The arrows in Figure 14.1 illustrate the risk-management processes and the information and communication flows among the risk-management components. The activities in the outer circles are performed sequentially, moving from risk assessment to risk response to risk monitoring. The risk frame informs all the sequential step-by-step activities. For example, the threats identified from the risk frame serve as inputs to the risk assessment activity. Similarly, the outputs from the risk assessment component (risks) serve as the input to the risk response component.¹³

Risk assessment

Once the risk frame is established, we can build on the threat model developed earlier to create a risk assessment model.

Risk assessment model

The threat model introduced earlier is reproduced in Figure 14.2. Threats involve motivated agents attacking assets. When conducting threat analysis, we typically do not conduct a formal analysis of the potential outcomes of the threats. Our concern during threat analysis is limited to identifying potential problems.

For example, one of the threats identified was a remote hacker (agents) compromising the user credentials database (asset), by stealing these credentials (action). During threat analysis, we did not consider the potential impact of such a threat. Specifically, we did not worry about what the hacker might do with such information.

Risk assessment can be seen as adding an analysis of outcomes to the identified threats. Our definition of a risk as a quantitative measure of the potential damage caused by a specified threat can be written as:

Since the threat itself is composed of an agent, an action, and an asset, we can write the equation for risk as:

Risk = damage (agent, action, asset)

This is shown in Figure 14.3. We can use this figure to identify risks and write them down as risk statements, which provide all the information necessary to communicate information about risks to concerned parties. Building on our example threat of a hacker stealing user credentials, we can write the associated risks as:

In other words, the same threat may be associated with multiple risks, if the threat can cause multiple forms of damage.

Once the risks are identified, quantitative measures for the risks are developed by estimating the likelihood and potential damage upon occurrence of the risk. We then calculate the risk as the product of the likelihood and the magnitude. Continuing with our example of the hacker, say we estimate the probability of such an attack in the coming year at 1%. Also, say that for risk 2, we estimate the monetary damage from lost sales at $10,000 in profits. We can quantify the risk in this case as:

Risk = likelihood × magnitude = 0.01 × $ 10,000 = $ 100.

By developing similar estimates for all the identified risks, we can prioritize the risks within our risk frame.

Other risk-management frameworks

The NIST 800-39 framework is a very general IT risk-management framework. There are some other information security risk-management framework, with the ISO 27000 series and the CERT OCTAVE being among the most popular. There are many consulting firms which help organizations to implement the recommendations of these standards. We provide a brief overview of these two standards here for completeness.

ISO 27000 series

The International Standards Organization (ISO) has reserved the ISO 27000 series of standards (i.e., standards starting with the digits 27) for information security matters. As of December 2012, this series includes six standards ranging from ISO 27001 to ISO 27006. These standards cover the following topics:

The ISO 27001 standard states that the ISO adopts a process approach for implementing information security. All processes follow Deming's Plan-Do-Check-Act (PDCA) model. During the planning phase, organizations establish policies and procedures to manage information risks. These procedures are operated in the do phase. During checking, process performance is measured against the plan specifications and presented to management for review. In the act phase, review results are used to improve policies and procedures in the next iteration of the plan phase.

You may note the parallels between the NIST 800-39 and ISO 27001 standards. The NIST assess phase maps to the ISO plan phase, the respond phase to the do phase, and the monitor phase to the ISO check and act phases.

ISO 27002 documents a set of security techniques, which map to the controls we have discussed throughout this book. The controls in the standard are divided into the following sections: (i) asset management; (ii) human resources security; (iii) physical and environmental security; (iv) communications and operations management; (v) access control; (vi) information systems acquisition, development, and maintenance; (vii) information security incident management; (viii) business continuity management; and (ix) compliance.¹⁴

ISO 27005 specifies that the information security risk-management process consists of seven sequential steps: (i) context establishment; (ii) risk assessment; (iii) risk treatment; (iv) risk acceptance; (v) risk treatment plan implementation; (vi) risk monitoring and review; and (vii) risk-management process improvement. Following the PDCA recommendation of ISO 27001, ISO 27005 aligns these activities with the four phases as shown in Table 14.1.

As you can see, there is considerable overlap between the ISO and NIST recommendations as they relate to information security.

OCTAVE

Carnegie Mellon University (CMU) hosts the well-known Software Engineering Institute (SEI). SEI is a federally funded organization that has over the years taken the stewardship for coordinating various activities important to the software industry. It started off by developing recommended guidelines for improving the software development process. In recent years, it has taken leadership in information security and maintains the central repository of bug reports released by major software vendors. Another popular initiative of the SEI is the OCTAVE methodology for information security management.

OCTAVE stands for Operationally Critical Threat, Asset, Vulnerability Evaluation. The methodology corresponds to the risk assessment phase of the NIST 800-39 framework. The description of the OCTAVE methodology provided below is adapted from the overview provided at the SEI website:¹⁵

The OCTAVE Method was developed with large organizations in mind (300 employees or more). These organizations generally maintain their own IT infrastructure and have the capability to manage their own information security operation. OCTAVE uses a three-phased approach to examine organizational and technology issues, assembling a comprehensive picture of the organization's information security needs. The three phases are:

OCTAVE is comprised of a series of workshops, either facilitated by outside experts or conducted by an interdisciplinary analysis team of three to five of the organization's own personnel. The method takes advantage of knowledge from multiple levels of the organization. These activities are supported by a catalog of good or known practices, as well as surveys and worksheets that can be used to elicit and capture information during focused discussions and problem-solving sessions.

As you may have observed, there are many parallels between the OCTAVE and other information security risk-management frameworks discussed earlier (NIST 800-39 and ISO 27000).

IT general controls for Sarbanes–Oxley compliance

Thus far in this chapter, we have discussed general information security risk-management frameworks that are usable in a wide range of industries. While these frameworks should be helpful in most contexts, in contexts where the stakes are very high, specific legal requirements for IT risk-management methodologies have emerged. One such context is financial reporting in publicly traded companies. This context has been a big driver of recruitment of freshly graduated information security professionals in the last decade. It has introduced terms such as SOX, section 302, section 404, internal control, and IT general controls into the information security lexicon. Given this importance, we provide an overview of this context in this section.

The Sarbanes–Oxley Act of 2002

In the final years of the 20th century, America witnessed one of the most euphoric rises in stock prices in its financial history. The business potential of the Internet led to investors bidding up the prices of any company associated with the Internet. The phenomenon is now known as the “dot-com boom.” Analysts developed metrics such as “dollars per eyeball” to justify these prices. Whereas companies whose stock prices are over 20 times annual income are generally considered expensive, during this time companies sported billion dollar valuations with no profits and many companies sported valuations in excess of 100 times annual profits. In the late stages of this frenzy, when people began to question these lofty valuations and companies came under pressure to justify their stock prices, executives at some well-known firms forged their account-books either to show sales that did not actually occur (MCI-Worldcom) or to hide costs (Enron). Many of these executives profited personally from these forgeries.

When the cases came to trial, leaders at these companies denied culpability and took the plea that they had signed off on the financial statements based primarily on their trust in their accounting staff and auditors. They argued that the firms' operations were so complicated that it was impossible for them to know all aspects of the financial statements. However, management experts, the public, and lawmakers were convinced that the managers knew exactly what they were doing and the pleas of ignorance were merely attempts to exploit legal loopholes and avoid penalties.

These trials brought to light two important details of stock markets. One, that the retirements of most Americans were tightly linked to stock markets because most retirement funds have no choice but to invest the majority of their assets in the US stock markets to achieve the growth required to help people retire gracefully. When large companies such as Enron and MCI-Worldcom manipulated their statements and eventually collapsed, it hurt the retirement assets of almost every American worker. Two, that firm leaders could push a lot of wrongdoing in their firms through verbal and implicit directions that left no paper trail that could be used during court trials.

Under heavy pressure to do something, Congress passed the Sarbanes–Oxley act in 2002. The act is named after its two primary sponsors, Senator Paul Sarbanes (D-MD) and Representative Michael G. Oxley (R-OH). The voting pattern indicates the overwhelming legislative support at the time for the law. It received 423 of a possible 434 votes in the house and 99 of the 100 possible votes in the senate.

Sarbanes–Oxley – important provisions

From the legal perspective, the law had one major impact. Sections 302 and 906 created a new criminal provision, making CEOs and CFOs of publicly traded firms criminally liable for untrue statements in public filings. CEOs and CFOs are now personally liable for the veracity of financial information presented in public filings. Prior to Sarbanes–Oxley, prosecutors had to establish malicious intent for untrue statements to be considered a criminal offense. For reference, the relevant provisions of the act are reproduced below.

SEC. 302. CORPORATE RESPONSIBILITY FOR FINANCIAL REPORTS.

(a) REGULATIONS REQUIRED.—The Commission shall, by rule, require, for
    each company filing periodic reports under section 13(a) or 15(d)
    of the Securities Exchange Act of 1934 (15 U.S.C. 78m, 78o(d)), that
    the principal executive officer or officers and the principal finan-
    cial officer or officers, or persons performing similar functions,
    certify in each annual or quarterly report filed or submitted under
    either such section of such Act that—

    (1) the signing officer has reviewed the report;

    (2) based on the officer's knowledge, the report does not contain
        any untrue statement of a material fact or omit to state a
        material fact necessary in order to make the statements made,
        in light of the circumstances under which such statements were
        made, not misleading;

    (3) based on such officer's knowledge, the financial statements,
        and other financial information included in the report, fairly
        present in all material respects the financial condition and
        results of operations of the issuer as of, and for, the periods
        presented in the report;

    (4) the signing officers—

        (A) are responsible for establishing and maintaining internal
            controls;

        (B) have designed such internal controls to ensure that mate-
            rial information relating to the issuer and its consolidated
            subsidiaries is made known to such officers by others within
            those entities, particularly during the period in which the
            periodic reports are being prepared;

        (C) have evaluated the effectiveness of the issuer's internal
            controls as of a date within 90 days prior to the report;
            and

        (D) have presented in the report their conclusions about the
            effectiveness of their internal controls based on their
            evaluation as of that date;
…

SEC. 906. CORPORATE RESPONSIBILITY FOR FINANCIAL REPORTS.
…

‘’(c) CRIMINAL PENALTIES.—Whoever—

‘’(1) certifies any statement as set forth in subsections (a) and (b) of
this section knowing that the periodic report accompanying the state-
ment does not comport with all the requirements set forth in this sec-
tion shall be fined not more than $1,000,000 or imprisoned not more than
10 years, or both; or

‘’(2) willfully certifies any statement as set forth in subsections (a)
and (b) of this section knowing that the periodic report accompanying
the statement does not comport with all the requirements set forth in
this section shall be fined not more than $5,000,000, or imprisoned not
more than 20 years, or both.‘’.

SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS.

(a) RULES REQUIRED.—The Commission shall prescribe rules requiring each
    annual report required by section 13(a) or 15(d) of the Securities
    Exchange Act of 1934 (15 U.S.C. 78m or 78o(d)) to contain an inter-
    nal control report, which shall—

    (1) state the responsibility of management for establishing and
        maintaining an adequate internal control structure and proce-
        dures for financial reporting; and

    (2) contain an assessment, as of the end of the most recent fiscal
        year of the issuer, of the effectiveness of the internal control
        structure and procedures of the issuer for financial reporting.

(b) INTERNAL CONTROL EVALUATION AND REPORTING.—With respect to the
    internal control assessment required by subsection (a), each reg-
    istered public accounting firm that prepares or issues the audit
    report for the issuer shall attest to, and report on, the assessment
    made by the management of the issuer. An attestation made under this
    subsection shall be made in accordance with standards for attesta-
    tion engagements issued or adopted by the Board. Any such attesta-
    tion shall not be the subject of a separate engagement.

From a business perspective, section 404 of the Sarbanes–Oxley act introduced the concept of standards-based verification of internal control. Prior to the passage of the Sarbanes–Oxley act, auditing firms used their own battle-tested procedures to verify that firms had robust processes to prevent fraud. However, the events of the dot-com boom revealed that auditing firms could be persuaded through fees and promises of future engagements to compromise on their assessments and certify suspect financial reports. Accordingly, the Sarbanes–Oxley act required that the verification of internal procedures be based on rules that were established by government, not the industry. Section 404 of the Sarbanes–Oxley act is shown below. The directive in the section that is relevant to our purposes is highlighted in bold.

The net result is that, since 2003, firms are required to verify that their internal controls comply with the standards established by the Sarbanes–Oxley act. We provide a high-level overview of standards and associated procedures in the rest of this section.

PCAOB and auditing standards

Sarbanes–Oxley (popularly called SOX) created a body called the Public Company Accounting Oversight Board (PCAOB) to develop the standards to be used for SOX attestations. Adapting from the organization's website,¹⁶

The PCAOB has published standards for all aspects of auditing.¹⁷ The standards of greatest interest to us are AS5 - “An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements” and AS12 – “Identifying and Assessing Risks of Material Misstatement.” AS 5 guides the overall SOX engagement, something you are quite likely to participate in if you join one of the professional auditing firms. Within the SOX audit, AS 12 provides guidance for IT.

Section 21 of the AS 5 standard specified the overall direction of a SOX audit as:

Section 36 of AS 5 directs auditors to paragraph 29 and appendix B of AS 12 to deal with the impacts of IT upon the audit process:

Section 29 of As 12 essentially directs auditors to appendix B of the standard:

Finally, appendix B of AS 12 includes the following:

For convenience, Figure 14.4 shows how the above guidelines for IT audits flow from section to section in the auditing standards.

Internal controls

What is the ultimate goal of all the activity associated with Sarbanes–Oxley? The term used is “internal control over financial reporting.” This is defined by the PCAOB in appendix A of AS 5 as:

Internal control over financial reporting is a subset of the overall control activities at the firm. In the Sarbanes–Oxley domain, control activities are defined as procedures, methods, and policies that responsible persons use to reduce the likelihood of occurrence of risky events to acceptable levels. This definition is consistent with the definition of IT security controls we have used in this book – safeguards used to minimize the impact of threats.

IT general controls

The bulk of the internal control audit activities are performed by auditors and accountants. However, these professionals rely on IT experts to assist in the evaluation of the controls exemplified in Appendix B of AS 12. These activities have traditionally been called IT general controls.

The current versions of the auditing standards do not seem to have a definition for the term “IT general controls.” However, AS 2, which has been superseded by AS 5, included in para 50.¹⁸

While even AS 2 only provided example and did not formally define IT general controls, para 50 suggests a definition. Based on para 50 of AS2, general controls may be contrasted with specific controls in that general controls provide the underlying platform for the accomplishment of many specific controls. For example, if an IT system allows users without passwords to record transactions, the likelihood of fraudulent transactions increases significantly, weakening the effectiveness of specific controls designed to verify different business activities. Therefore, maintaining a secure IT infrastructure through IT general controls is important to reliably verify business activity. Based on this, we define IT general controls as control activities performed by IT that ensure the correct processing of business transactions by the organization.

In a Sarbanes–Oxley engagement, IT experts are involved in the auditing of IT general controls.

Procedure for verification of IT general controls as part of a SOX audit

Following the top-down guiding principle of AS 5, the industry has developed the following procedure for an audit of IT general controls over financial reporting.¹⁹

1. Look at the firm's financial statements
2. Identify material line items
   1. What an average prudent investor reasonably ought to know
3. Identify business processes feeding into these items
4. Identify IT platforms that support these processes – OS, database, applications, web-server, network
5. Verify that IT general control objectives are satisfied for these platforms
6. Report material weaknesses
   1. Deficiency that can result in material mis-statements to occur or remain undetected

This process is repeated annually, to comply with the provisions of the SOX act. For # 5 in the list above, 12 control objectives have been identified based on industry best practices, including items such as managing changes and managing data.²⁰

Compliance versus risk management

The example of Sarbanes–Oxley in the domain of IT general controls over financial reporting that was introduced in the previous section shows that a lot of risk-management activities are mandated by law and regulations. Earlier, we have defined compliance as the act of following applicable laws, regulations, rules, industry codes, and contractual obligations. If the bulk of risk-management work is defined by laws and regulations, you might wonder why any organization should take the effort of developing its own risk-management plan based on NIST 800-39 or ISO 27000. Why not outsource risk management to legislators and industry experts, and simply comply with the laws, regulations, industry codes, etc. that these experts develop?

If you give this some thought, you will realize that compliance is only a subset of risk management, requiring a minimal set of risk-management activities to prevent catastrophe that can affect others. Compliance does not regulate risks that affect only you or your organization. For example, you are entitled to risk your money on lotteries, squander your income on unwise purchases, and consume alcohol within the privacy of your home, etc. Since any adverse outcomes of these actions are limited to you alone, there are no regulations or codes preventing you from performing these activities. However, when you drive on the road, your dangerous conduct can put other drivers at risk. Therefore, we require drivers to comply with safe driving laws and there are stiff penalties for driving under the influence of alcohol.

Similarly, in IT risk management, compliance activities ensure that your organization's conduct does not put investors and other organizations at risk. But you alone are responsible for ensuring that your actions do not put your own organization at risk. Risk management covers everything that you do to prevent harm to yourself.

Selling security

IT security is not an easy sell. Upper management usually thinks in terms of Return on Investments and oftentimes it is difficult to quantify the return on something that “may” happen, like a power failure or a hacker incident. Even though it is easier to justify the expenses based on existing, known incidents, certain organizations are still hesitant to commit resources to security.

One of the best strategies is to try to include a certain percentage to be spent in security in every project started within IT. For instance, a project involving Identity and Access Management may also include the cost of software needed to encrypt personal data such as Social Security Numbers. And if the software agreement is negotiated correctly, the same software may be licensed to include the permission to encrypt other restricted data on other servers as well.

Unfortunately, one of the easiest ways to obtain funds is to capitalize on incidents that happened with other, similar organizations. A leak of Social Security Numbers on nearby Universities will without a doubt raise questions about the internal security of your own University. The students will be asking how protected their SSNs are, and maybe so will the local media. During these times, IT may receive windfalls of funds to improve the security stance of the infrastructure. It is important to have a strategy always ready to be able to use these situations and not just waste funds purchasing resources that are not needed.

Example case–online marketplace purchases

On December 5, 2012, the US Attorney for the Eastern District of New York announced the arrests of six Romanian and one Albanian national for defrauding US customers on popular Internet marketplaces such as eBay, AutoTrader.com, and Cars.com. The arrests involved co-operation among law enforcement agencies in Romania, Czech Republic, United Kingdom, Canada, and the United States.

The fraudsters posted detailed ads for expensive items such as cars and boats on the popular online markets though none of the posted items actually existed. They used co-conspirators called “arrows” in the United States to open bank accounts using high-quality fake passports. These arrows responded to enquiries from potential buyers and collected payments.

Payments from unsuspecting victims were transferred out of the United States by the arrows as cash or wire transfers. In one case, $18,000 in cash was mailed out of the US inside speakers. In another case, money was used to buy an expensive watch, which was then mailed to the fraudsters. The total estimated earnings of the gang was $3 million.

[alice@sunshine ∼]$ su -
Password: thisisasecret

[root@sunshine ∼]# lsof -i
COMMAND     PID    USER  FD TYPE   DEVICE SIZE/OFF NODE NAME
sshd       1862    root  3u IPv4    11083      0t0 TCP *:ssh (LISTEN)
sshd       1862    root  4u IPv6    11085      0t0 TCP *:ssh (LISTEN)
ntpd       1870     ntp 16u IPv4    11113      0t0 UDP *:ntp
ntpd       1870     ntp 17u IPv6    11114      0t0 UDP *:ntp
ntpd       1870     ntp 18u IPv6    11118      0t0 UDP v6.sunshine.edu:ntp
ntpd       1870     ntp 19u IPv6    11119      0t0 UDP [fe80::a00:27ff:fef6:cadf]:ntp
ntpd       1870     ntp 20u IPv4    11120      0t0 UDP sunshine.edu:ntp
ntpd       1870     ntp 21u IPv4  1878265      0t0 UDP 10.0.2.15:ntp
mysqld     2148   mysql 10u IPv4    11438      0t0 TCP *:mysql (LISTEN)
master     2276    root 12u IPv4    11742      0t0 TCP sunshine.edu:smtp (LISTEN)
master     2276    root 13u IPv6    11744      0t0 TCP v6.sunshine.edu:smtp (LISTEN)
httpd      2316    root  4u IPv6    11985      0t0 TCP *:http (LISTEN)
qpidd      2335   qpidd 10u IPv4    12079      0t0 TCP *:amqp (LISTEN)
qpidd      2335   qpidd 11u IPv6    12080      0t0 TCP *:amqp (LISTEN)
dnsmasq    13558 nobody  4u IPv4  1877904      0t0 UDP *:domain
dnsmasq    13558 nobody  5u IPv4  1877905      0t0 TCP *:domain (LISTEN)
dnsmasq    13558 nobody  6u IPv6  1877906      0t0 UDP *:domain
dnsmasq    13558 nobody  7u IPv6  1877907      0t0 TCP *:domain (LISTEN)
dhclient   13624   root  6u IPv4  1878166      0t0 UDP *:bootpc
httpd      31152 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31153 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31154 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31156 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31157 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31158 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31159 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)
httpd      31160 apache  4u IPv6    11985      0t0 TCP *:http (LISTEN)