Data breach fact gathering and intelligence

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.

Data breach risk high for healthcare

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 have 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:

Utah Department of Health          780,000
Emory Healthcare          315,000
S.C. Department of Health and Human Services          228,435
Alere Home Monitoring, Inc.          116,506
Memorial Healthcare System, Fla.          102,153
Howard University Hospital            66,601
Apria Healthcare            65,700
University of Miami            64,846
Safe Ride Services            42,000
Medical Integration services, Puerto Rico            36,609

As I 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 requiring 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.  Know 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.

Incident response and information security culture

A while back, I┬á published a white paper on security culture for JURINNOV.┬á 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.

Computer Forensics: First Responder Training

Timothy Opsitnick, Senior Partner,  John Liptak, Forensic Investigator and I explained the role of computer forensics and the first responder to an incident in this training session.  Contents included:

  • Understanding Computing Environments
  • Collecting Electronically Stored Information
  • Forensic Analysis Demonstration
  • Types of Cases When Forensics Are Useful

How to know your security is working by using metrics

Try to imagine a world without metrics.┬á The temperature would only be ÔÇ£hotÔÇØ instead of 95┬░ or a project would be ÔÇ£in progressÔÇØ instead of 75% complete.┬á Metrics provide an effective way to keep track of vital information.┬á They are particularly useful for identifying trends and measuring the progress of activities.┬á When used effectively, security metrics provide a uniform way to make decisions and to measure progress in information security.

The first step in implementing effective information security metrics is to choose a meaningful set of metrics.  Meaningful metrics are relevant to the organization and associated with its goals.  If the business contends that  it will protect customer data, then significant metrics may include the number of days since a data breach or average time to resolve incidents.

Sample information security metrics

The National Institute of Standards and Technology (NIST) and The SANS Institute have both defined sample metrics that give an idea of different items that may be used to measure the status of an organizationÔÇÖs security structure.┬á Similar to the security snapshot, which measures 25 metrics in 5 categories, the NIST and SANS metrics provided here are divided into six categories with select metrics provided as samples.

Access Control

Access control metrics measure the efficiency and effectiveness of methods used to grant and restrict usage of information.  Some Access Control metrics include:

  • Percentage of remote access points used to obtain unauthorized access
  • Percentage of false positive access rejections

Awareness and Training

Security awareness and training metrics measure the level of investment given to furthering and solidifying skills in information security for both information security practitioners and employees. Some Awareness and Training metrics include:

  • Percentage of information security personnel who have received training this year
  • Average number of security awareness training given this year

Contingency Planning

Contingency planning metrics measure the level of planning and efficiency and effectiveness of response to a state of emergency where critical systems become unavailable, effectiveness of backup operations and recovery for critical information systems.  Some Contingency Planning metrics include:

  • Number of days since the last system failure
  • Availability percentage of key information systems

Incident Response

Incident response metrics are concerned with the effectiveness of activities taken to detect and correct information security incidents.  Incidents are defined as situations where information security controls are compromised, subverted or circumvented.  Incidents may or may not result in loss of data confidentiality, integrity or availability.  Some Incident Response metrics include:

  • Average number of hours needed to recover from a system failure
  • Percentage of incidents that were reported within the organization during a specified period of time.

Media Protection

Media protection metrics track important data relative to how well the organization protects the media on which important data resides.  Media types include hard drives, flash drives, data tapes and optical media such as compact disks and DVDs.  Some Media Protection metrics include:

  • Number of flash drives containing sensitive data
  • Percentage of decommissioned hard drives that were forensically wiped and/or destroyed

Risk Assessment

Risk assessment metrics show the effectiveness of risk management activities within the organization.  Some Risk Assessment metrics would include:

  • Percentage of risks identified requiring mitigation that were successfully mitigated within specified time frames
  • A bar chart showing the number of critical, high, medium and low level risks identified

Security metrics are necessary to understand and interpret various data points and measurements.┬á Once these points are collected, they can provide an organization with an easy way to measure the efficiency and effectiveness of its information security activities.┬á The most useful metrics are those tailored to the companyÔÇÖs individual needs and requirements as reflected in the companyÔÇÖs values and goals.┬á Metrics provide the ability to monitor and control specific, measurable information security activities in a logical and easily understood manner.

Further Reading:

http://www.itl.nist.gov/lab/bulletns/bltnaug03.htm

http://www.sans.org/reading_room/whitepapers/auditing/guide-security-metrics_55

http://csrc.nist.gov/publications/nistpubs/800-55-Rev1/SP800-55-rev1.pdf

Security governance for virtualized systems

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 specify 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 is able to 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, ie: 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 logon 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 issue resolution.

Ymy 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 differ 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.

Summary

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.

For further reading

NIST Releases Virtualization Security Guidelines

Altor Networks Automates VM Security Policy Enforcement

Security in a Virtualized World