Identity Theft Response

Identity theft is becoming more common as technology continues to advance exponentially. Mobile devices, applications, and email make it more convenient for individuals to access records and financial accounts, but also increase the risk of identity theft.

As the CISO, you will be drafting an

incident response plan

to address identity theft for your financial organization.

Identity Theft Response is the second of four sequential projects in this course. The final plan will be about 10-12 pages in length. There are 16 steps in this project and it should take about 14 days to complete. Begin with Step 1, where you will identify types of cyberattacks in which personally identifiable information could be vulnerable.

Step 1: Identify Potential PII Attacks

Since this project will require an enterprise cybersecurity incident response plan with considerations specifically to identity theft, types of attacks must be identified. In a table or spreadsheet, identify the types of attacks that could result in denial of access to or 

theft of PII (personally identifiable information)

. Consider both internal and external incidents and those associated with employees and/or customers. Submit your list of potential PII attacks for feedback from your CIO (course instructor).

You will build upon this list of identified attacks throughout this project to form your Incident Response Plan. In the next step, industry-specific standards related to these types of attacks will be addressed.

Step 2: Align Industry-Specific Standards

Now that you have identified potential attacks in the previous step, you should research and identify state or federal government standards established for the protection of PII (where they exist) as well as industry codes. Keep in mind that while you are concerned in particular about standards that govern the financial industry, there are different standards specific to other industries. As a CISO, you need to be aware that regulations can vary—for example, standards are different in the health care field.

Add an additional column to the prepared list of potential types of PII attacks from the previous step. In this second column, note what standards might be required when addressing each incident type. You should align government-mandated and sector-voluntary standards to the PII attacks identified.

Refer to the provided 

industry-specific regulations

 for additional background on existing regulations. As you consider standards for your organization, continue building upon this table in the next step.

Step 3: Exceed Policy Standards to Fulfill Company Demands

In the previous step, you identified the policy standards for relevant PII attacks. In this step, address any types of attacks that were not aligned in the previous step or those in which given standards are considered inadequate by senior leadership. As CISO, you are aware of your organization’s expectations to guarantee the highest level of security for the organization and individuals in regards to theft of PII (personally identifiable information).

To complete this phase of the project, you will add an additional one to two columns to include upgraded or superior solutions on items considered to still be vulnerable. The alternatives that you add should reflect your organizational demands, initiatives, and vision. You will assess and prioritize this list of solutions in the next step.

Step 4: Assess Alternatives

Now that you have created a list of alternative solutions, assess your recommendations and prioritize them in a final column. Prioritize each alternative by placing a number “1” next to the first priority, a number “2” next to the second, and so on.

To the right of the prioritized solutions, in a sentence or two, state why you selected that alternative in that particular position. Submit the updated PII Solution Alternatives Table for feedback. This table will be used as an appendix in your final Incident Response Plan. In the next step, you will begin to develop a strategy for breach management.

Step 5: Complete the

Executing the Response to a Cyberattack

eLearning Module

So far, you have identified potential PII attacks and developed a set of PII solution and prevention alternatives. Before outlining a strategy for breach management, review Executing the Response to a Cyberattack. A response to cyberattack typically includes prevention measures, which you have already considered, but it also includes defense, detection, recovery, and response concerns. These areas should be developed with business considerations and subject to the advice of company leaders.

Now that you have become more familiar with an overview of how to execute a response to a cyberattack, proceed to the next step to outline a

breach management strategy

.

Step 6: Outline Breach Management Strategy

The next several steps will fit the alternatives into a breach management strategy. Strategic thinking can be challenging in a project environment. A “project” is work- and task-oriented, and it includes specific deliverables produced within a defined timeframe. Such projects have a limited budget and are developed to exact specifications. This project’s charter is to present a strategic view of responding to a potential breach in the area of the system containing PII.

This section of the planning should explore areas other than cyber technology. It is about policies, required and recommended, that expand the project notes you have been creating to address corporate concerns outside of the technology realm, such as legal implications, reporting, etc.

Briefly outline, for use in the next few steps, a strategic approach in response to a breach allowing access to PII—customers and/or employees. Think of the policy aspects that will have to be addressed. You will continue to use the findings determined here and over the next few steps to produce a breach management strategy.

Breach management options will be considered in the next step.

Step 7: Determine Breach Management Options

Using the outline of the strategic approach developed in the previous step, determine both the technical and strategic options available in addressing a breach of PII. The eventual goal is to help senior management understand the level of effort required in an appropriate response to a breach. Take note of these options for future use.

Once complete, you will be ready to research legal issues in the next step.

Step 8: Research Breach Management Legal Issues

With breach management options identified in the last step, begin to research associated legal issues. Breach management in response to exfiltration of PII is well documented in a legal context. Multiple resources are available that address the issue. This section of your research and breach management strategy report should carefully identify all the concerns being raised in the courts surrounding previously documented cases.

The idea is to find evidence of court cases being litigated that are a result of a PII breach—not necessarily the outcomes of those legal proceedings. Identify the issues that your policy strategy should address and draft a discussion. This discussion will be used in a future report. After considering legal issues, move to the next step, which will be a look at cyber insurance.

Step 9: Research Breach Management Cyber Insurance Options

Redirect the research from legal issues in the last step to cyber insurance options in this step. As the number of PII breaches grows, so does the new industry of cyber insurance. Draft several paragraphs that state the options now available for this component of risk mitigation. Be sure to include what is covered by most readily available insurance policies, as well as what is not covered.

As an example: Is the institution covered for a customer PII breach if it is determined the breach was caused by an employee? The intent is not to make you a cyber insurance expert, but to offer senior leadership some of the strategic, big-picture options. This draft will be used in a future report.

In the next step, you will research the regulatory requirements of breach management.

Step 10: Research Breach Management Reporting and Other Requirements

Publicly traded enterprises and health care organizations are subject to governmental regulations and requirements where PII is concerned. In addition, some industries voluntarily impose standards upon their members. This is the section of the breach management strategy to address those issues.

What are the minimum reporting requirements applicable to financial institutions (in this case)? What standards are in place that must be met to prevent additional damage to the institution in the way of fines, warnings, or other sanctions as a result of noncompliance with regulations on reporting the breach?

Actual requirements for other industries could be similar, overlapping, or not, determined by the business sector, inclusion in critical infrastructure classification, and a number of other factors. The financial sector is our example for this project and not to be considered comprehensive or all-inclusive across all sectors.

In the next step, you will compile the report on breach manage

Step 11: Compile the Breach Management Strategy Report

After considering the elements of breach management strategy over the last several steps, compile all drafts and revise into a complete five- to seven-page Breach Management Strategy that will present policies to senior leadership for the response to a PII breach.

You will need to include an overview of your strategic approach, options available, legal issues, cyber insurance, reporting and other requirements, and finally the proposal. Your proposal should identify issues/impacts with mitigation strategies, and include regulatory responses where they exist. Note how financial industry reporting requirements differ from health care or other industries.

Submit the Breach Management Strategy for feedback. This report will help complete your work on the final incident response plan.

Step 12: Compose Policy Components of an Incident Response Plan (IRP)

Now that you have a proposed breach management strategy, you are ready to begin development of an incident response plan (IRP) specific to a breach of PII. Compose the key policy components of an incident response plan in a list to be used as a basis for the next step.

Step 13: Itemize the Steps of an IRP

Start at the key policy component list from the last step and add postincident requirements already identified to itemize the actions it will take to accomplish these goals. Keep in mind the level of effort required and time involved to accomplish each element of the IRP.

You now have all the information necessary to create a comprehensive IRP. To get your mind set in the right direction, imagine that a breach affecting PII has occurred. It is the organization’s worst cyber incident. What do you do? How does the organization respond? What steps need to be taken to meet all the requirements you have identified in the Breach Management Strategy?

This step is to create a list or an outline; the use of a spreadsheet is recommended to facilitate subsequent steps in the project. The primary column is all of the actions or tasks that need to be completed in the IRP. As part of this first list, identify what department is responsible for what action by considering the functional areas of a financial institution.

You will build upon this list in the next step by adding the element of time to your spreadsheet documentation.

Step 14: Assign a Typical Timeline for an IRP

As a result of your Breach Management Strategy, are there specific timelines required by the regulatory compliance you referenced? If so, that should be your starting point for creating the IRP timeline. These are referred to as project “milestones.” Look at the list you created in the previous step and put those milestones in a required response time sequence.

When building the timeline, pay attention to elements that depend on previous elements—things that must be completed before a following action can be started. In project management, these are referred to as “critical path” items.

This section of creating the IRP must have all critical path items covered within regulatory milestones. It is not mandatory to assign perfect values to the actual time it takes to accomplish each action item. It is mandatory to show the milestone dates.

As an example, one reporting requirement for a financial institution suffering a PII breach is likely to be to notify all affected customers within 72 hours of the breach. That means you will have a customer notification milestone at three days in the IRP.

After you have added the milestone dates to your spreadsheet documentation, you will plan for implementation of the incident response plan in the next step.

Step 15: Plan for the IRP Implementation

This is the step where you tie together the requirements (milestones), the timeline (critical path), and which department will be responsible for what elements in the plan (accountability). Ensure all of the rows and columns in the spreadsheet are in alignment to accomplish the goal of minimizing the impact of the PII breach. It is the final step in creating the IRP. This spreadsheet will be included in your final IRP.

Now, it is time for the final step, in which you will explain the results of all your hard work on the IRP to senior leadership.

Step 16: Complete the Incident Response Policy Plan (IRP)

The resulting IRP should be a total of 10 to 12 pages that present an actionable plan to fully address a breach of the organization’s PII. It should include a final paragraph on your thoughts about how the recommendations are likely to be received.

This final step is to bring all the work together. Use what has been created in the previous steps as detail to support your completed plan on incident response. Synthesize the material and include all CIO (instructor) feedback received.

Include in your comprehensive IRP the review and findings from a policy approach to maintain or exceed compliance with all regulatory demands. In addition, demonstrate your adherence to the best possible outcome for victims of a PII breach.

Remember, confidence in and approval of the approach is mandatory. It has already been determined that a breach of the organization’s PII is a serious matter. The CEO and the rest of the executives are depending on your expertise to address the situation quickly and effectively. This IRP is that plan of action.

Submit the complete report to the CIO for approval and delivery to the senior leadership team.

Information security continuous monitoring (ISCM) is defined as “maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions” (Dempsey et al., 2011).

Incidents, often discovered under an ISCM plan, are the result of thwarted controls, even when the organization is implementing adequate risk mitigation, for instance using the risk management framework (RMF) outlined by the National Institute for Standards and Technology (NIST, 2010).

Incident response controls outlined in NIST Special Publication 800-53 are aimed at recognizing and handling incidents and mitigating and remediating the damage that could result from incidents (NIST, 2013). An incident is an event that results in a violation of security protocols. Once an incident has occurred, it is important that the organization assess the damage to its critical infrastructure.

An important part of any postincident process is to document as accurately as possible the nature and cause(s) of the incident in case it needs to be presented in court. A postincident report should follow some simple steps, as outlined by Kim and Solomon:

· Preparation of the incident report: Decide how to respond to the threat or incident and form an incident report team.

· Identification: Did the incident really happen? If it did occur, is it damaging to the organization? This is not a rhetorical question. An incident or event may not be serious enough to allocate resources and manpower to address.

· Notification: This is an important step in the postincident report. If an event or incident has taken place, the appropriate authorities must be notified immediately. Sometimes senior managers find a problem but do not communicate to key stakeholders for fear of losing their jobs or a company losing its reputation and clients’ trust.

· Response: In this step, senior managers articulate the best possible way to address the incident while minimizing downtime.

· Recovery: Once the appropriate measures have been taken to address an incident, senior managers must reexamine the organization’s system to make sure the threat or vulnerability has been eliminated.

· Follow-up: Now that the system is up and running, senior managers and leadership must ask: What have we learned from this incident? What policies or procedures need to be updated? What can we do to prevent another occurrence?

· Documentation and reporting: Document the incident and its cause(s) and use it as a teaching moment.

Any postincident handling must follow the rules of evidence in accordance with applicable laws and regulations. This will ensure admissibility, authenticity, completeness, reliability, and believability of the postincident evidence if it is required or necessary to be presented in court. While cybersecurity law is still relatively new, there are certain rules for evidence to be introduced in court (Braid, 2002):

· Admissible evidence stands up in court.

· Authentic evidence is relevant to the incident.

· Complete evidence is objective and represents alternative interpretations.

· Reliable evidence is grounded in truth.

· Believable evidence is clear and easy for a jury to understand.

In addition to following the rules of evidence, senior managers and senior leadership must also remember that in most instances, a professional criminal cyberforensic expert may be called to help with the postincident report. It a cybercrime forensics expert is called in, it is important he or she has credentials and certification.

Also, a cyberforensics expert must remember that crime does not happen in isolation; criminals use take advantage of the means to commit a crime, the opportunity to commit a crime, and they usually have a motive. Cybersecurity professionals refer to means, opportunity, and motives by the acronym MOM.

Another important concept in the postincident report is that whenever a crime is committed, the criminal not only takes something away but also leaves something behind. This is known as Locard’s exchange principle.

References

Braid, M. (2002). Collecting electronic evidence after a system compromise. https://www.giac.org/paper/gsec/659/collecting-electronic-evidence-system-compromise/101519

Dempsey, K., Chawla, N. S., Johnson, A., Johnston, R., Jones, A. C., Orebaugh, A, Scholl, M., & Stine, K. (2011, September). Special publication 800-137: Information security continuous monitoring (ISCM) for federal information systems and organizations. National Institute of Standards and Technology (NIST). http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137

Kim, D., & Solomon, M. (2018). Fundamentals of information systems security (3rd ed.). Jones & Bartlett Learning.

National Institute of Standards and Technology (NIST). (2010, February). Special  publication 800-37, Revision 1: Guide for applying the risk management framework to federal information systems. http://dx.doi.org/10.6028/NIST.SP.800-37r1

National Institute of Standards and Technology (NIST). (2013, April). Special publication 800-53: Security and privacy controls for federal information systems and organizations. http://dx.doi.org/10.6028/NIST.SP.800-53r4

Incident Response Plan

Print

Computer security incident response has become an important component of information technology (IT) programs. An incident is defined as “a security event that compromises the integrity, confidentiality, or availability of an information asset” (Gordon, 2015).

Any organization in the business of handling personally identifiable information (PII) should establish an incident response capability. That capability, which requires planning and resources, should consider the following guidelines (Cichonski et al., 2012):

· creating an incident response policy and plan

· developing procedures for performing incident handling and reporting

· setting guidelines for communicating with outside parties regarding incidents

· selecting a team structure and staffing model

· establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., human resources and legal department) and external (e.g., law enforcement agencies)

· determining what services the incident response team should provide

· staffing and training the incident response team

The National Institute of Standards and Technology’s (NIST) Computer Security Incident Handling Guide notes the importance of continually monitoring for attacks and establishing procedures for prioritizing incidents, as well as instituting methods of collecting, analyzing, and reporting data (Cichonski et al., 2012).

References

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Special publication 800-61, revision 2: Computer security incident handling guide: National Institute of Standards and Technology. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2

Step 16: Complete the Incident Response Policy Plan (IRP)

The resulting IRP should be a total of 10 to 12 pages that present an actionable plan to fully address a breach of the organization’s PII. It should include a final paragraph on your thoughts about how the recommendations are likely to be received.

This final step is to bring all the work together. Use what has been created in the previous steps as detail to support your completed plan on incident response. Synthesize the material and include all CIO (instructor) feedback received.

Include in your comprehensive IRP the review and findings from a policy approach to maintain or exceed compliance with all regulatory demands. In addition, demonstrate your adherence to the best possible outcome for victims of a PII breach.

Remember, confidence in and approval of the approach is mandatory. It has already been determined that a breach of the organization’s PII is a serious matter. The CEO and the rest of the executives are depending on your expertise to address the situation quickly and effectively. This IRP is that plan of action.

Submit the complete report to the CIO for approval and delivery to the senior leadership team.