Ransomware Incident Response: 7 steps to success

Ransomware infections are becoming increasingly commonplace, and companies that put a plan together before an incident are much more effective at combatting this pervasive malware.

Ransomware response can be broken down into seven steps. Here’s a cheat sheet:

Validate
The first step is to confirm whether a reported ransomware infection is an actual infection. There are cases where a user reports what they think is ransomware, but it turns out to be adware, phishing, or some other virus. Validation is important because it keeps efforts focused on important issues. But if you see a ransomware note demanding payment to unlock files, and your system or files are locked or frozen, then you’ve been hit.

Assemble
Now it’s time for the incident response team to assemble. Incident response teams often include members of your IT staff, management, public relations, and legal. The incident response plan outlines how each member should be trained on how to respond to a ransomware incident. In some cases, the primary person may be unavailable, and it will be necessary to call in a secondary resource to handle that role.

Analyze
The next step is to determine the scope of the incident, including which networks, applications and systems are impacted and whether the ransomware continues to spread. This is often the role of the IT and security point people.

Contain
Containment actions can take place concurrently with analysis activities. In this phase, infected machines are isolated to stop the spread of the ransomware by disconnecting the computers from the network or shutting them down. The scope often changes when containment is underway, and ransomware is still spreading. This phase ends when all infected machines have been isolated from clean machines.

Investigate
The investigation starts by preserving evidence. Some machines will need to be returned to service as soon as possible while others might be less critical. Evidence such as log files or system images is taken of the affected machines along with documentation of serial numbers and asset identifiers.

Eradicate
The eradication phase removes the ransomware from machines and brings them back into a functioning state. Isolated machines are wiped, and then data is restored from backupto each of the machines after the evidence on the computers has been preserved. In some cases, organizations may decide to remove the ransomware and then restore files that were encrypted by the ransomware without wiping the device first.

A full machine restoration prevents other ransomware or malware from causing problems on the computer, and it also prevents backdoors or other software that the ransomware might have installed from being used to infect the machine later. For this reason, it is typically recommended that you wipe the device and restore the operating system and data from backup.

Remediate
The last step is to remediate the problem that the ransomware exploited in the first place. This is often a user training issue, so companies implement more awareness training or coaching of individuals. In other cases, new technology needs to be put in place. If backups were found to be inadequate, the company would back up more data or back up more often. The ransomware incident should result in some improvement actions that the organization can perform to be better prepared for future incidents.

For more news and information on the battle against ransomware, visit the FightRansomware.com homepage today.

Crucial Elements of an Incident Response Plan

The news is crowded with reports from noteworthy companies of cyber-attacks.  Last year was the year of the data breach and this year is the year of ransomware.  Companies large and small, even those with large security budgets and mature security practices, still proved vulnerable to attack.  Every company will suffer a security incident someday, but not all companies are prepared for it, and preparation will determine what impact a security incident will have on your company.

Will your company weather the attack and come out stronger for it or will you lose customers, brand image, or your company?

“We’re not in Kansas anymore”

This is where your incident response plan comes in.  The incident response plan outlines the activities that will take place in an incident.  Decisions made before an incident are far superior to those made in the heat of the moment when the stress is on.  Plans can be thought through and properly vetted, and this leads to more robust decision making, more effective incident response, less company and customer loss due to the incident, and less stress overall.

“Houston, we have a problem”

The first step in an incident response plan is to define the team of individuals who will conduct and coordinate the incident response.  This is more than just a group of technical wizards or high-level executives.  It also includes PR, legal, security, and third parties.

“To the Batcave”

Once the team is assembled, the next step is to create an incident response plan.  This is not a step that is given to one or two team members.  Rather, those involved on the team should also be involved in the incident response planning effort.

Scenarios or table top exercises can be used to develop plans for specific incidents or to enhance existing plans.  Scenarios such as malware infection, ransomware infection, a lost or stolen device, Distributed Denial of Service (DDoS) attacks, cyber breaches, and social engineering should be specifically addressed in meetings where each team member walks through the actions they would take in that incident.  A facilitator guides the discussion and aids in making sure critical steps are not skipped.  The output from scenario planning is a detailed step by step process for handling specific incidents.

“Who’s on First?”

It is not enough to know what to do.  You also have to know who is going to do it.  Many plans have failed because no one knew who was supposed to carry out the expertly-written instructions.  Each task in the incident response plan should have a designated person or role assigned to it.  Role-specific tasks provide accountability and ensure that there will be someone to conduct those activities during an incident.  None of the tasks identified in the procedures should be overlooked.  It is important to also assign alternates in case the primary person is unavailable when the actual incident occurs.  Once the incident procedures have been properly vetted and approved and the roles outlined, response activities should be practiced regularly so that the incident response team is familiar with their responsibilities.

There is a lot more information available on incident response, but an effective incident response plan requires the right team, well-thought-out instructions, and tasks that are clearly assigned to individuals.  Plans lacking these elements will not provide your company, customers, and employees with the guidance they need when an incident occurs, and it will happen.  Be prepared.

This post is sponsored by AT&T Security.

5 steps to a winning incident response team

People are the core of any incident response effort.  You must have the right people to provide the right response.  Incident response teams should include a diverse set of individuals across the organization including executives, information technology, security, public relations, legal and relevant 3rd parties.  Here is what makes a winning incident response team.

  1. Winning teams have top level support

Top level support is essential in an incident response team, and executives can provide it.  Executives are the ones who will be able to allocate the resources necessary to take action during a breach, and they can rally support and establish budgets for planning and preparation activities.  Executives also bring legitimacy to incident response plans and procedures.

  1. Winning teams have the technical skills

Almost every incident will require some level of technical skill to resolve it and most incidents will require significant technical effort.  Information technology (IT) team members are usually the first to find out about an incident.  Sometimes users report an incident to IT and in other cases, IT learns about the incident through detective security controls such as log monitoring or intrusion detection systems, or antivirus.  IT is also responsible for making technical changes as incident response activities progress.

  1. Winning teams have a security perspective

A keen understanding of the risks, impact, and scope are needed in incident response.  This is where members of the incident response team responsible for security step in.  Security team members take point on validating reported events and determining if they constitute an incident.  They analyze information collected by technology tools and assess the scope and impact of the incident.

  1. Winning teams know how to communicate

Communication, both internally and externally, is a fundamental component of incident response.  Public relations team members communicate with employees, partners, law enforcement, the media, or investors regarding the incident.  They work with the legal team to understand the compliance and contractual liability and cyber breach notification requirements.

  1. Winning teams cross organizational boundaries

Teams may include both internal employees and contractors.  Incident response is not something most companies do every day, and an effective response requires individuals who have the unique skills, tools, and techniques required to address the incident.  Some third parties that may be part of the incident response team include forensics, security consultants, attorneys, insurance, law enforcement, or upstream providers such as Internet Service Providers (ISP), datacenters, or cloud providers.

Team makeup is critical for successful incident response.  A winning team needs to have adequate support, the required technical and security skills, effective communicators, and outside expertise.  So who is on your team?

This post is sponsored by AT&T Security.

Effectively gathering facts following a data breach

It is easy for miscommunication to happen after a data breach.  There could be many people working on the incident and those people may document differently and without guidance, critical facts could be lost due to inconsistent or ineffectual documentation procedures.  This can make it difficult for incident response teams to understand the relevant facts of the matter.  Here are some guidelines in documenting a breach.

It can be very helpful to start with a timeline.  Discuss the incident with those who first noticed it and those who validated that there was an incident.  Put the time of the reported incident and the validation on the sheet and then add the events that led up to the incident.  Keep adding events to the timeline as you progress and this will help show the incident flow and help you determine the cause and effect of the incident.  Review the timeline with the incident response team and receive feedback.  The timeline can be used similar to a murder board in a police investigation.  Post the known facts and their times on the wall in the incident briefing room and then tack on new facts to it as you progress.  You can do this digitally as well if the team is not all in one place.

Next, record the facts only.  Don’t let personal opinions creep into the log.  Documented assumptions can lead the incident response team in the wrong direction.  They can also be detrimental if legal action is taken as part of the investigation as these documents could be part of the discovery process.

The National Institute of Standards and Technology’s (NIST) Computer Security Incident Handling Guide suggests that teams should have a person designated as the documenter while another person performs tasks so that the critical facts are not left out.

Lastly, don’t jump to conclusions.  There could be many explanations given the available data so care must be taken to eliminate available options.  Determine what data you will need to eliminate an option and then seek that out.  Keep track of the possible scenarios and their underlying criteria and whether those criteria have been proved or disproved.

Hospitals are the highest risk for data breaches

Recent research shows that hospitals are the highest risk for data breaches.  The third annual benchmark study on patient privacy found that 45% of healthcare organizations had suffered more than five data breaches.  This is an increase from 29% in 2010.  In the majority of cases, 46%, the cause of the data breach was a lost or stolen computing device.  Employee carelessness and business associate mistakes were tied for the second most likely cause.

Healthcare IT News put together a list of the top 10 healthcare data breaches of 2012 listed below:

Healthcare Data Breach Top 10

 

 

 

 

 

As we move into 2013, health care organizations can help prevent data breaches by maintaining tight control over organizational computing assets containing Protected Health Information (PHI) since this is the highest cause of breaches.  They should also be concerned with employee security training and require higher security standards of business associates.  Last but not least, HIPAA compliance is a must.

When a data breach or cyber security incident does occur, the impact can be minimized if clear direction for handling the breach has been given through incident response plans.  It is also important to know when to call for outside help.  Identify providers of breach response services and computer forensic services and have their information at hand to minimize the scope and impact of a data breach or cyber security incident.

Culture change through incident response

A while back, I published a white paper on security culture.  An organization’s culture in relation to information security determines how receptive employees will be to security initiatives.  Culture can make the difference between security that is embedded into the organization versus security that is simply an afterthought or even worse, ignored.

Culture is formed through a series of successes that reinforce the underlying assumptions behind those successes.  Alternatively, failures diminish assumptions associated with the failure.  There are many actions an organization can take to being the process of instilling a culture of security.   A recent example at Seattle Children’s Hospital shows how the organization’s security culture was improved through incident response planning.

In an interview with Information Week, Cris Ewell, Chief Information Officer for Seattle Children’s Hospital stated that employees have recognized that breaches will happen even with the best preventative measures now that they have implemented incident response plans.  They also realized that some incidents require outside help.   It is important to know who to contact ahead of time because time is precious following an incident.

Developing a Virtualization Security Policy

Since many organizations are rapidly virtualizing servers and even desktops, there needs to be direction and guidance from top management in regards to information security. Organizations will need to develop a virtualization security policy that establishes the requirements for securely deploying, migrating, administering, and retiring virtual machines. In this way, a proper information security framework can be followed in implementing a secure environment for hosts, virtual machines, and virtual management tools. This article is part two of a series on virtualization.

As with other policies, the security policy should not specify technologies to be utilized. Rather, it should define requirements and controls. Technologies will be implemented to satisfy the requirements and controls provided by the policy.

  • Auditing and accountability
  • Server role classification
  • Network service
  • Configuration management
  • Host security
  • Incident response
  • Training

Auditing and accountability

The auditing and accountability portion has to do with the responsibilities of administrators, management, and users of the virtual environment. It is important to specify administrative roles such as backup operators, host administrators, virtual network administrators, server users, and self-service portal users. For smaller organizations, a few people may fill these roles, but larger organizations will specify greater separation of duties between roles. Clearly, identify the server role classifications that each user role can access.

Furthermore, this section should indicate that administrative actions will be logged and audited. Logs should be redundant, backed up regularly, and applications should be available for audit log searching and review.

Server role classification

Virtual machines or guests, serve different roles such as a file server, domain controller, email server, remote access server, or database. Some roles are more sensitive than others, and thus they should be treated differently. Roles can be determined by the applications a server hosts or the data it hosts, as well as its criticality and value.

A series of classification levels such as standard, secure, and highly secure should be specified. The number of levels you have is determined by your organization’s business rules. For each classification, clearly state the server roles and information types that would fall into the category and the level of authentication, segmentation, encryption, and integrity verification necessary. For example, for segmentation, virtual machines classified as highly secure must be located on physically distinct hosts and separate logical networks and backup media should be allocated solely for use on highly secure systems.

Network service

The network service section details how remote access to hosts and virtual machines will be conducted or if it is allowed at all. It specifies Access Control List (ACL) requirements and how logical addresses will be allocated, distributed, and managed for virtual hosts and machines. Resource limits for hosts should be specified so that hosts are not overburdened with virtual machines causing performance degradation. Indicate the need for service accounts and least privilege configuration of service account privileges, i.e., configuring service accounts with the bare minimum privileges necessary for the service to function.

Configuration management

The configuration management section is concerned with maintaining the consistency of the virtual environment. This section should specify the types of changes that require approval and how each type is approved. Any exemptions to the approval process are listed. Some change types include virtual network creation, modification, or removal, host addition or removal, host hardware modification, or virtual machine hardware modification.

Approval stages should be specified including the roles or groups responsible for approving change requests and the types of change requests that can be approved by each role or group. List how authorization will take place and where and how change authorizations are tracked and stored.

The configuration management section should also include statements on how violations of the configuration management policy will be dealt with and how actual changes are validated against logged changes. This includes any auditing that is required for change controls.

Host security

The host security section defines where hosts will be stored, how hosts are monitored, and how physical and remote access to the hosts is controlled. The location of hosts is important because hosts need to be available and secure. The location determines the level of network connectivity such as redundant network links and internet connectivity as well as power redundancy, power availability and cooling.

The next part of host security deals with how the hosts are monitored. Specify the types of monitoring that will take place. For example, physical monitoring may use closed circuit cameras that archive footage to DVD. You might specify logging of successful and failed login attempts to the host servers and directory modification on storage devices containing virtual machine files or configuration data.

Incident response

This section should detail what should happen if the virtual environment is compromised in some way. It should explain how information security incidents in the virtual environment are evaluated and how they are reported. It then defines the persons and groups responsible for controlling the issue and what constitutes problem resolution.

Your business may have an incident response plan in place already. This plan should be consulted when constructing this section so that it is aligned with the main information security policy. This section should still be included even if an incident response plan exists because the virtual environment can differ in how incidents are resolved and in what constitutes an incident.

Business continuity

Virtual environments vary greatly in Business Continuity (BC) methodologies. Since virtual machines are stored as files, they can be easily moved around. Business continuity methodologies, therefore take this into account in specifying how machines will be brought back into production when significant outages or disasters occur.

The business continuity section should specify what should be backed up and how it would be restored in the case of an emergency. Levels of emergency should be stipulated as well as the groups responsible for coordinating BC efforts. The section should also specify if resources such as a cold, warm, or hot site are necessary for BC.

Training

The training section should clearly define what skills a person should have to fulfill the roles specified in the auditing and accountability section and how those skills will be taught and measured. It is important for those working on the environment to be trained in how to not only perform their job duties but to perform them in a secure manner.

The training section should specify ongoing assessment of training gaps and areas of focus for team members including how often training should occur, whether this will be handled internally or outsourced, and how training budgets will be determined. If training is to occur in house, curriculum evaluation and follow-up reviews should be specified in the training portion. In this way, when technology changes, the team’s skills will be kept up to date as well.

The virtualization security policy contains many elements from other organizational security policies, but it is specifically targeted to virtual hosts, the machines they contain, and the tools that manage them. It is important that virtual environments have such a policy because existing security controls do not adequately address the risks associated with using virtual machines. If you do not have a policy in place yet you are encouraged to develop one before your virtual environment is implemented. This policy will resolve security ambiguities associated with managing the environment, and it will ensure a consistent approach to information security within your organization if those affected by the policy are properly trained and required to adhere to it.