Using your HIPAA Risk Analysis

Congratulations! You’ve completed your initial comprehensive HIPAA risk analysis, no easy task. You’ve gone through the process and planned for and scoped your environment. You’ve identified your risks, threats, and vulnerabilities, and all of the associated requirements necessary to conduct and complete a HIPAA risk analysis. So, now what? Let’s focus on five important steps for using your HIPAA risk analysis; Internal Reporting, Management Responsibilities, Corrective Action, Monitoring, and Auditing.

5 Important Steps for Using your HIPAA Risk Analysis

Internal reporting, management responsibilities, and corrective action are directly related to a risk analysis process, while monitoring and auditing are required for any information security program and indirectly serve you risk analysis process. Let’s take a look at each of these important steps for completing your HIPAA risk analysis.

1. Internal Reporting

Once you’ve completed the process of identifying your threats and vulnerabilities, potential impact, likelihood of occurrence, controls in place, recommendations, and all of the elements necessary for conducting your risk analysis, we need to know what to do with all of that information, specifically the report format. Your report format should include a high-level summary of your Risk Analysis process. This summary should show internal and external stakeholders what you did and how you did it in a way that that can be independently verified. Your report should frame what could be a confusing and complex collection of information in a way that can be easily understood and recreated. This report of information is important to operational units who may be responsible for implementing the recommendations resulting from the risk analysis, and external auditors, both from your clients, a third-party you’ve hired, or the federal government. A high-level report can go a long way in an auditor’s understanding and perspective of whether your risk analysis met the standards required in the HIPAA Security Rule.

A second item that is useful to include in your internal reporting, however not required, is your organization’s top findings. This can give a visual representation of your risks, not including all threat-level detail, but communicating the likelihood and impact of a particular risk and giving a comparative depiction of how a particular risk compares to other risks.

Another item that should be including in your risk analysis report are your recommendations. At this point, we’re discussing enterprise and project-level recommendations, not threat or vulnerability-level recommendations. These recommendations should include next steps, such as management approval, corrective action, auditing, and monitoring, including a description of how those activities should go forward based on your risk analysis.

Additional documentation should include any appendices and reference materials. Any sort of supplemental information that will be useful to internal and external stakeholders in understanding your HIPAA risk analysis. Lastly, be sure to include your actual HIPAA risk analysis and documentation of your threats and vulnerabilities, asset list, threat list, and policy list.

2. Management Responsibilities

The guiding standard for responding to risk is “reasonableness”. Specifically, we are required to “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level” to comply with HIPAA laws. As you present your risk analysis and recommendations to management, it’s important to constantly think along the lines of what is reasonable and appropriate. There is always the potential for management to receive a risk analysis and be immediately overwhelmed with the number of things that are being recommended to be HIPAA compliant. Our goal isn’t perfection, it is determining how we can reasonably and appropriately mitigate risk. For example, a recommendation may be to utilize a proprietary software solution to mitigate a particular threat or vulnerability. This software solution costs three times your annual revenue, only reduces risk by 3%, and takes three years to develop and implement. In this instance, this is not a reasonable or appropriate recommendation. Another recommendation may be to implement a quarterly logical access review for an organization comprised of less than 100 employees. This process would take less than 15 hours each year to complete, would reduce risk by 50%, and can be immediately implemented. In this instance, this is an appropriate and reasonable method for reducing risk.

When evaluating and responding to risk, management has four ways of doing so. First, they can accept risk. If a cost-benefit analysis determines that the cost to mitigate a risk is unreasonable and inappropriate, the best response (and a compliant) is to accept and continually monitor the risk. Another way management can respond to a risk is to transfer the risk, for example to a business associate. A risk with a low probability of occurring that may have a large financial, regulatory, or reputational impact on the organization, may be best met by transferring the risk to a third party. A third way that management can respond to risk is to mitigate the risk. This is the best response for activities with a high likelihood of occurrence, but a low impact. Mitigation is going to be the bulk of the recommendations for your risk analysis follow-up. This requires changing or increasing controls. The final way to respond to risk is to avoid the risk altogether. This is most appropriate for activities that have a high likelihood of loss and a high likelihood of occurrence. An example of an activity that can be avoided is the risk of a stolen or lost laptop containing ePHI. This risk can be avoided by deciding that laptops will no longer be used to access ePHI or those devices are no longer able to leave the building. Find an alternative way to provide these services without exposing yourself to a particular risk. At the end of this process, management will go through the documentation review and approval. Management’s approval needs to be thoroughly documented.

3. Corrective Action

A HIPAA risk analysis is a great tool that can serve as a compliance roadmap. It can show you where you have the most exposure, what steps provide the greatest reduction of risk, and can assist in helping with budget requirements. The risk analysis should include control recommendations that are specific and were identified and documented during the analysis phase, and include best practices for categorizing your control recommendations from a cost perspective, benefit perspective, and the time it would take to implement. This step in using your HIPAA risk analysis will be very specific to your unique organization and can be based on a number of factors such as the size of your organization, the services provided, and the amount of ePHI that you have access to. Your corrective actions and control recommendations should prioritize the next steps that should be taken in further maturing your organization’s security posture.

4. Monitoring

Once you’ve completed the corrective action stage, you’ve completed all the steps related to your risk analysis. Using your risk analysis and all the resources that you have created during the process can help you to develop a risk-based security management system. If you’ve already identified your areas of greatest risk, sometimes it makes sense to increase your monitoring activities in order to appropriately address those areas of great risk. Ways you can do this include increasing frequency and the intensity of evaluation. There are certain types of controls you can use to monitor your risks. These include diagnostic controls, boundary controls, and belief systems. A diagnostic control is a reporting tool used to communicate that certain activities are happening when they’re supposed to happen and in the way they were designed to occur. Boundary controls are solutions that constrain certain activities. Not just by alerting you of an activity, but by impacting and influencing activities. These can include role-based access, multi-factor authentication, password management, and encryption sanctions. Lastly, belief systems are a part of the culture of compliance concept. This includes employee security training, an important aspect to ensuring that your responsibilities under HIPAA laws are appropriately taken care of.

5. Auditing

The final step in using your HIPAA risk analysis is your auditing process. There is often confusion between monitoring and auditing. Monitoring is a review of the information provided by an operational unit, whereas, auditing is an independent assessment of activities performed by someone outside the operation. When auditing your risk analysis, you should be testing your risk analysis controls for their existence and their effectiveness. Assess that your controls are in place and that they are appropriate and operating effectively. This independent audit, in turn, can benefit by laying the groundwork for future risk analyses.

Using your HIPAA risk analysis helps you to determine what you are going to do with the risk you have identified. It verifies that management has reviewed and agreed with the risk analysis process, and it also suggests how we can use this information to improve, whether that is through monitoring and auditing. If you need help with your HIPAA risk analysis process or understanding how to use the information established from your HIPAA risk analysis, contact us today.

More Resources

Security Awareness Training Compliance Requirements: SOC 2, PCI, HIPAA, and More

Most Common HIPAA Gaps

Penetration Testing in Support of HIPAA Compliance

Best Practices for Managing Firewall and Router Security

When you look at the threat landscape today and the organizations that have experienced a data breach (Target, Home Depot, Arby’s), they all have a common denominator – they were all compliant. They had been checking the boxes like they were asked to do. So, when it seems that compliance isn’t enough, how can we ensure that we are secure? Organizations today should use these examples as motivation to focus on maintaining a secure environment. If you’re secure, compliance will always fall into place. However, just because you’re compliant, doesn’t necessarily mean you’re secure. Let’s start the conversation by discussing best practices for managing our firewalls and routers, and essentially our networking gear as a whole. When it comes to managing firewall and router security, we will be focusing on three main areas: physical devices, running operating systems, and secure traffic rules.

Managing the Security of Physical Devices

Managing the security of a device goes much further than the device itself. Here are several elements of physical device management:

  • Establish a formal change control program. We, as an organization, need to be aware of any changes made to a system, whether it’s making a change to the Access Control List (ACL), installing a new operating system, or installing a new device. This program needs to be defined and documented in the policies and procedures.
  • Assign responsibility for the management of devices. Is someone with a trained eye and the proper credentials reviewing your firewall and router configurations? Are you monitoring whether your operating system is current and not susceptible to known vulnerabilities?
  • Define acceptable use policies and procedures for your assets. Are the rules you’ve established appropriate and required for your business? Are they secure? Those managing your assets should have training in that particular area and it must be necessary for them to perform their business function.
  • Define acceptable technologies and acceptable locations to place them in. We wouldn’t want to put a wireless device or wireless access point in the core of our environment and it not be protected. Established policies that define where it is appropriate to put a firewall or router is critical for managing the security of physical devices.
  • Perform periodic review of the configurations. As the industry changes, so does the risk posture. We need to constantly evaluate these network devices including the firewall, router, switches, and wireless access points (WAP) as the risks change on a daily basis.
  • Ensure that devices are physically secured from unauthorized access. It’s important to ensure that we’re physically securing these devices from any and all unauthorized access. If a hacker can get physical access to a device, it’s game over. At that point, they will have the ability to reset usernames and passwords, and gain physical and logical access to your assets.
  • Secure the cables that connect in to and out of devices. Securing the cables that connect devices to and from the network is important to prevent unauthorized access such as port sniffing or a similar malicious attack. Be sure your controls that you have in place take into account securing these cables.
  • Limit the ability to directly console the devices. With a network device, there are multiple ways to gain access. We need to make sure that anyone who needs access to certain assets to perform their job has access, but everyone else should be denied access. Access controls are essential for limiting people outside, or within, the organization from accessing your assets that has no business doing so.
  • Minimize out-of-bound access points. Minimize any unnecessary exposure to assets by limiting out-of-bound access points. Logging and monitoring traffic can help you know exactly who is accessing your network and what they’re doing.

Managing Operating System Security

When it comes to managing your firewall and router, it’s critical that you are properly managing your operating system. Here are several musts when it comes to managing operating system security.

  • Limit logical access. When looking at the operating system, we must limit logical access by including a policy of least privilege.
  • Maintain a detailed set of hardening standards. This is a critical practice. Organizations must maintain a set of hardening standards, regardless of the organization’s size. It may be helpful to understand that the industry has already vetted the types of hardening controls that you should apply to your organization, so you don’t have to start from scratch. Ask yourself, “are my firewalls and routers up to standard?” A review of your firewall and router configurations should include reviewing standards such as NIST, SANS, NSA, etc.
  • Configure logging. From an audit perspective, we see this missing a lot in different environments. Your organization should be able to identify when any administrative changes have been made in order to determine if something is a security incident, or appropriate use.
  • Change the defaults. Always change vendor defaults. This means passwords and SNPA community strings should be set to complex values. Passwords should be at least 13 characters in length, both alpha and numeric, including both upper and lowercase. Password recovery should be disabled and the maximum log in attempts should be no more than three.
  • Ensure strong encryption. There are numerous encryption protocols that are no longer considered secure. If you don’t know what your supporting, chances are you are supporting an insecure version. Disable web based management if you aren’t using it, and if you are, validate that the certificate is strong and accepted (TLS v1.2). Disable telnet or clear text protocols and use SSH v3 where possible. It’s also best practice to establish a VPN.
  • Keep it updated. Update and patch your router and firewall with your operating system on a regular basis. You don’t always need to update your router and firewall just because there is a new operating system available, however, if the OS you’re running is found to have vulnerabilities, you should. Also, be sure to include all networking devices into your patching schedule.
  • Establish remote access console timeout. 15 minutes or less is a best practice when it comes to locking your workstation. This helps to prevent someone from performing malicious behavior on your machine when you are away from your desk.
  • Configure NTP. As part of your logging infrastructure, you should have your devices set up and configured to support NTP.
  • Establish log-on banner. As auditors, we rarely see this as a requirement, however this is a strong suggestion to be considered. There have been legal cases in the US in the past where a hacker gained access to a router and was found “not guilty” because the organization that was hacked did not have a banner visible that said, “If you are not authorized to access this site, you are trespassing and should disconnect immediately”.
  • Disable unused interfaces. Any unused interfaces should be disabled or removed. This minimizes your vulnerabilities and scope, and can keep someone from using that additional interface for a malicious attack.
  • Ensure that downloaded images are authentic. When you go to upload a new operating system, validate that the OS you’ve downloaded is authentic and hasn’t been compromised.
  • Restrict ICMP from untrusted interfaces. Restrict inbound and outbound ICMP from untrusted interfaces to minimize the ability for attack.
  • Enable anti-spoofing rules. Be sure to have anti-spoofing rules that prevents hackers from spoofing their source address to look like it’s coming from your internal address and allowing your firewall and router to pass that address.

Maintaining Secure Traffic Rules

Lastly, let’s talk about maintaining secure traffic rules in and out of your environment.

  • Maintain a list of approved ports and services. Management should always oversee the traffic that is allowed in and out of your environment.
  • Limit inbound traffic (from the Internet to the DMZ). This is a standard best practice, and the best way to monitor who is able to access your environment. Open ports that aren’t used only become a liability.
  • Limit outbound traffic to only that which is needed. In the event that a hacker successfully entered your environment, setting up policies that limit outbound traffic can help to prevent the data that a hacker can take from your environment.
  • “Any” based rules should not be used. Rules should be as prescriptive as necessary to securely shape the traffic.
  • Systems that interact with sensitive information should have rules explicitly defined to limit the exposure. Any system storing sensitive data should have very strict rules established that limit all access to protect this data as securely as possible.

Creating a security-minded culture at your organization should supersede any boxes you are checking for the sake of compliance. Beginning with managing firewall and router security is a good starting point. For additional information on best practices for managing firewall and router security at your organization, visit the Center for Internet Security (CIS) or contact us today.

More Resources

Think Like a Hacker: Common Vulnerabilities Found in Network

The Dangers of End-of-Support Operating Systems

Stay Secure With These Intrusion Detection and Protection Techniques

Conducting your HIPAA Risk Analysis

A couple of weeks ago, we posted about the planning process for a HIPAA risk analysis. This process included determining whether the proper resources are available, the importance of defining scope, creating or using ePHI workflows, and compiling asset lists. The next step in the process is to perform the actual risk analysis. Let’s talk about the actual elements for conducting your HIPAA risk analysis and define some common terms we will need to know for this process.

Defining Common Terms for Conducting your HIPAA Risk Analysis

When talking about risk analysis, we often hear the terms threat, vulnerability, and risk. Understanding what these terms mean is important for when you’re ready to conduct your risk analysis. According to NIST 800-30, 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 violation of the system’s security policy”. A threat is the potential for a person or thing to exercise (accidentally trigger or intentionally exploit) a specific vulnerability (adapted from NIST 800-30). According to HHS guidance for risk analysis, a risk can be understood as a “function of the likelihood of a given threat triggering or exploiting a particular vulnerability, and the resulting impact on the organization”. This means that risk is not a single factor or event, but rather a combination of factors or events that, if they occur, may have an adverse effect on the organization.

The Subjective Nature of Risk

Before we dive into the technical approach of conducting your HIPAA risk analysis, we must make clear that the concept of risk is subjective. When determining risk, we must ask ourselves:

  • What is the asset?
  • What must we account for?
  • What do we need to protect?
  • Is there significant risk?

To better understand how risk can be subjective, picture a worn tire, completely smooth in some places. Just considering the tire we can conclude that it is in bad shape, and there is significant risk. However, when you picture the tire connected to a tire swing rather than on your car, the subjective nature changes and the tire is no longer a significant risk. This combination of factors is important to consider when you see an asset and then see how it is used. What if the rope holding the tire swing was frayed? Would you alter and increase your opinion of the nature of risk? In this case, we must consider not only the tire, but also what it is connected to. What if we implement a control here and position a group of people holding a rescue trampoline under the girl on the tire swing with the frayed rope? Have we appropriately reduced the risk? Let’s complicate it more. Now, the rescue team with the trampoline is standing at the edge of a canyon. Does this change our opinion of significant risk again?

When conducting your HIPAA risk analysis, you must have all of the information about the assets that you’re trying to protect in order to fully understand the risk in your environment. Once you can do this, you are ready to move forward and identify risks, threats, vulnerabilities, controls and evaluate all the information about the assets you’re trying to protect in order to come up with a reasonable ranking for your risk. As you start conducting your HIPAA risk analysis it’s important to wait to define your risk until the end of the process.

Choosing a Risk Analysis Method

There are multiple acceptable risk analysis methods out there. The most common are NIST SP 800-30, Mehari, and Magerit. Among these risk analysis methods, NIST is the most common, especially in the healthcare industry. However, all of these risk analysis methods contain the same key elements. The key elements of any risk analysis method are to:

  • Identify potential threats and vulnerabilities
  • Determine the likelihood of threat occurrence
  • Determine the potential impact of threat occurrence
  • Evaluate current controls
  • Determine the level of risk
  • Finalize documentation

Let’s break these elements down and fully define the steps for conducting your HIPAA risk analysis.

Identify Potential Threats and Vulnerabilities

This initial step further emphasizes that the planning part of your HIPAA risk analysis is so important. It’s much easier to identify potential threats and vulnerabilities if you have defined your scope, ePHI workflow, and asset lists so that you know where your potential threats and vulnerabilities exist. Just like the tire illustration, when conducting your HIPAA risk analysis, you must ask yourself the same questions over and over again to exhaust every possibility that could occur in different parts of your environment that contain ePHI.

Determine the Likelihood of Threat Occurrence

This step in conducting your HIPAA risk analysis involves determining the probability that a potential vulnerability is actually exercised. For example, consider a lost or stolen employee laptop. How many laptops do you have? Do they leave your organization’s facility? Do people use their personal laptops to access ePHI? Is ePHI stored on laptops? The best way to do this is to numerically rank the likelihood of each threat and vulnerability you’ve identified. For example, you could rank the likelihood by very unlikely, unlikely, likely, very likely.

Determine the Potential Impact of Threat Occurrence

The next step in the process is determining the potential impact of a threat occurring. Just because something is very likely to occur, doesn’t mean the impact on your organization will be very bad. Also consider the reverse; something may be very unlikely to occur, but if it did would have a devastating impact on the organization. Just like with determining the likelihood, you’ll want to create a key that allows you to numerically rank the adverse impact resulting from a successful threat. Ask yourself, how much ePHI could be accessed? Could this shut down operations? Could this impact other covered entities or business associates? Could this cause a loss of business and harm to our reputation?

Evaluate Current Security Controls

Now that you’ve ranked the likelihood and impact of a threat occurring, it’s time to evaluate all use of assets and any backup measure used to prevent a threat from being exploited. Going back to our example of a stolen employee laptop, let’s list all of the controls that are currently in place to protect ePHI accessible from the laptop. Some example controls would be:

  • Encryption
  • Unique user ID
  • VPN
  • Multi-factor authentication
  • Remote wipe
  • No ePHI stored on the computer
  • Laptop can’t be physically removed from facility
  • ePHI can’t be remotely accessed

Just as in the previous steps, create your own rating system to rank each current control. Is what you’re doing insufficient, sufficient, or excellent in terms of preventing a threat or vulnerability from being successfully exploited? Once you’ve completed this step, you may also want to consider what else can you do to mitigate risk.

Determine the Level of Risk

The risk left over after you’ve identified potential threats and vulnerabilities, determined the likelihood and impact of those threats occurring, and evaluated existing security controls, is called residual risk. This gives you the information needed to determine the level of risk. Looking at your residual risk, you must come up with a numerical scoring system to rank these risks (very low, low, moderate, high, very high) to determine and understand where your risk lies. This will be a combination of the likelihood ranking, impact ranking, and existing controls ranking.

If you’d like to take it a step further, you can categorize your risks based on specific aspects of that risk. For example, reputational risk, regulatory compliance risk, operational risk, technical risk, financial risk, etc. Although not necessary, this is a helpful task for conducting a thorough HIPAA risk analysis.

Final Documentation

The final step in conducting your HIPAA risk analysis is documenting your risk analysis process. Your documentation can look several different ways, however, the elements that you should ensure are included are each defined asset, threat, vulnerability, likelihood, impact, current controls, control ranking, residual risk, and any control recommendations.

To summarize, start simple. Don’t overwhelm yourself and establish the framework of key elements to get started. Don’t forget about the subjective nature of risk and be sure to always document everything. For more information or free tools and resources to help you complete your HIPAA risk analysis, contact us today.

More Resources

HIPAA Compliance Checklist: Security, Privacy, and Breach Notification Rules

Risk Assessment Checklist – 5 Steps You Need to Know

Penetration Testing in Support of HIPAA Compliance

Planning your HIPAA Risk Analysis

Preparing for HIPAA compliance can be an overwhelming undertaking if you’re uncertain where to begin. Starting with a formal risk analysis can help you determine how your current security posture stands up against HIPAA laws while creating a roadmap leading you towards compliance.

Why is HIPAA Risk Analysis Important?

Why is risk analysis important? First and foremost, a risk analysis is important because it is a requirement under the HIPAA Security Rule. The number one finding identified during the Phase 1 HIPAA audits was that organizations consistently struggled with the risk analysis. Completing a risk analysis provides benefits that go beyond compliance with a single requirement, it is the start of a compliance path. If you’ve never completed or are struggling with one, the first step in the formal risk analysis process is planning. It’s important to remember that incomplete planning means incomplete results.

A risk analysis is not the same as an overall HIPAA gap analysis. A risk analysis asks, how much exposure do we have to unauthorized access or disclosure of ePHI? While a gap analysis asks, how are we doing compared to what the regulations require? A risk analysis provides greater layers of information by showing how much exposure you have, identifying the controls you have in place, and determining how likely it is that a security incident will occur. All of this leading to any necessary corrective action.

Determining your Resources

Determining available resources for completing the risk analysis is the next step in the planning process. Who will lead the project? Do they have the proper experience to conduct the risk analysis? Do they have the support of the leadership team? Have they reviewed any past risk analyses? If they don’t have any previous experience they will need to be trained and given any necessary resources to become familiar with the process in order to perform a satisfactory risk analysis. If you do not have the internal resources available, there is also the option to seek an outside source to perform the risk analysis for you.

Determining Your Scope

The next step in planning the risk analysis is determining the scope. Jocelyn Samuels from the OCR said, “All too often we see covered entities with a limited risk analysis that focuses on a specific system such as the electronic medical record or that fails to provide appropriate oversight and accountability for all parts of the enterprise. An effective risk analysis is one that is comprehensive in scope and is conducted across the organization to sufficiently address the risks and vulnerabilities to patient data.” The risk analysis requirement only applies to ePHI, so that excludes any fax receipts or phone calls where PHI is discussed. The best way to determine what is considered in scope is to think in terms of ePHI processing. Where does ePHI enter and exit your organization? Creating an ePHI data workflow will help you outline the specific places in your organization that touches, receives, or accesses ePHI. Creating a visual representation of your workflow will be a huge resource for your risk analysis scoping process.

Information gathering can be useful during ePHI flow research. Analyzing any previous information security incidents, performing interviews with key staff, reviewing documentation, and looking at past and present ePHI projects, can help you validate the scope of your risk analysis.

Don’t forget that planning is important. When you’re ready to move forward to discuss threats and vulnerabilities, ensure that you’ve accurately captured the information you need to properly complete your risk analysis.  Bring in internal resources who aren’t directly involved in the project and get feedback on any missing elements and present them with the documented plan you have established. For more information on risk analysis, contact us today.

More Resources

Most Common HIPAA Gaps

5 Ways Business Associates and Covered Entities Can Prepare for HIPAA Compliance

HIPAA Compliance Checklist: Security, Privacy, and Breach Notification Rules

Conducting Incident Response Plan Table Top Exercises

So, your Incident Response Plan looks good on paper – it’s been mapped, planned, documented. But has it been tested? Will it work?

Testing and drilling your employees and your Incident Response Team to understand how to respond in the event of an incident not only prepares them for an actual event, but it also helps to ensure that your plans are current and effective in the existing threat and organizational climate. Experts suggest that participating in table top exercises to simulate a real-world scenario is the best way to prepare.

When facilitating these exercises at your organization, be sure that the employees understand the purpose for conducting the exercises. They should be fully engaged so that you can determine if your team has all bases covered and be able to identify any previously unknown gaps in your current plan. The should understand that participating in these exercises will help determine if everyone can hypothetically talk through their respective functions during an incident and be sure everyone fully understands their role when responding to an actual incident.

The facilitator should present a scenario, asking participants specific questions related to the scenario, and from there, participants will engage in a discussion that focuses on roles, responsibilities, coordination, and decision-making during an incident. Prepare several scenarios in advance that will address specific areas of your Incident Response Plan you wish to test. Some sample scenarios include:

  • During a routine evaluation of system logs, an administrator discovers that company data has been obtained by an unauthorized user account.
  • A remote user has lost his/her laptop containing stored sensitive company data.
  • After a recent move, it has been discovered that a locked cabinet containing sensitive company data is missing.
  • A former employee, disgruntled after employment termination, has realized that he/she still has remote access to the company’s server and decides to infect the system with a virus.

We are already familiar with the stages of Incident Response: Preparation, Detection and Identification, Containment, Remediation, Recovery, Lessons Learned. Once presented with a scenario, the participants should begin going through these stages to determine what steps to take to handle the incident appropriately.

Here are some example questions that participants should be addressing during each stage of the exercise:

Preparation

  • How are we currently preparing for a security incident? What are we doing to prevent an incident from occurring? What are we doing to limit the impact of this type of incident occurring?
  • Do we have proper policies and procedures in place for handling an incident? Are they adequate?
  • What actions would have helped to prevent this type of incident from happening?

Detection & Identification

  • What controls are currently in place that would help identify this incident, and what are the procedures for reporting this incident?
  • How do we detect malicious activity of unknown origin on our systems?
  • How would we respond quickly to a suspected incident?
  • What tools or assets do we have to assist us in detecting unauthorized activity?
  • How would we assess the incident?
  • Do we have a specific incident response team for this type of incident?

Containment

  • How are we documenting the incident? What evidence should be collected? Have all aspects of the incident been assessed? (size, scope). What is the risk of the incident on operations?
  • What do our procedures say about containing an incident?
  • What strategies should we take to contain the incident?
  • How can we prevent further damage from this incident?
  • What could potentially happen if the incident were not contained properly?

Remediation

  • How can we clean the system?
  • Have we documented the footprint of the intruder? Where did it originate?
  • Have we made necessary changes to ensure successful restriction of a repeat incident?
  • Have the changes been tested?
  • Have we implemented any remote wipe capabilities?
  • Has a system access review been completed to ensure there are no other users that need to be removed?
  • What chain of custody procedures have been modified to ensure incident will not reoccur?

Recovery

  • How do we securely restore the system?
  • What monitoring procedures will be in place to ensure successful recovery?
  • What backups of files existed to replace the lost files?
  • Have we prepared a backout plan if recovery is unsuccessful?
  • Have we considered alternatives for database access without the infected system being involved?

Lessons Learned

  • What happened? What gaps can we now identify from this incident?
  • How do we go about regaining our customers’ confidence?
  • Now we must revise our policies and procedures to prevent future attacks. What adjustments should be made to avoid these attacks going forward?

Use this exercise to be a teaching, educating, and inspiring experience. Practicing your step-by-step Incident Response Plans will help your organization to be able to respond quickly and effectively during a real-world incident.

With help developing your Incident Response Plan or for unbiased guidance on Information Security best practices, contact us today.

More Resources

SOC 2 Academy: Incident Response Best Practices

SOC 2 Academy: Testing Your Incident Response Plan