Standards

Standards are the criteria that the organization must meet or be in compliance with in order to avoid fines or other actions levied against the organization. Standards may be required to meet a contractual agreement between partner organizations. In some industries, industry standards such as the Payment Card Industry Data Security Standard (PCI DSS) are enforced to set various performance criteria and reporting standards. Federal regulatory bodies may also apply standards that must be adhered to during normal business and during times of crisis.

Standards imposed by industry organizations and regulatory agencies should be applied to an incident response policy. That may include requirements with respect to reporting the occurrence of an incident, recording aspects of handling the incident, and reporting the final outcome and incident closure.

Procedures

Procedures are lists the steps or activities that response teams should follow to perform all required duties as listed in an incident response plan. An organization may have several ­different incident response plans, depending on the nature of the incident.

Guidelines

Guidelines are informal lists of best practices or good practices either internal to the organization or as listed in various best practice frameworks such as an Information Technology Infrastructure Library (ITIL). A guideline may be a recommended course of action that is not included as an established procedure.

Law Enforcement and Media Communication

A communication plan is a vital part of an incident response plan. During an incident or disaster event, the news media, business partners, and government agencies may require incident reports, event information, and news release or press statements concerning the event. It is very important to clearly describe in an incident response plan who within the organization is responsible to handle a press or law enforcement contact and what the correct message should be. On the other hand, through training, orientation, and policy, all personnel should be aware of how to handle any media inquiries and to whom to forward media inquiries. It is also important to include incident nondisclosure statements and all third-party vendor and contractor contracts.

Consideration should be given to the communications released to both law enforcement and the news media.

1. Law Enforcement Communication An incident response plan must include the notification criteria of law enforcement agencies such as local police, FBI, and Secret Service. Depending upon law enforcement jurisdictions and international laws or regulations notification requirements will differ. For example, those organizations covered by the Health Information Portability and Accountability Act (HIPAA) and regulatory bodies such as the Department of Health and Human Services must report certain information breaches that affect individuals, to the media and certain other government agencies. On the international stage, many countries have adopted information reporting requirements based on the breach of privacy through the release of personally identifiable information (PII).

   A major consideration when law enforcement is involved is determining the amount or type of evidence that can be collected. In some instances, private information, personal identification information, HIPAA-restricted information, and corporate confidential information may be part of the evidence of an incident. Evidence that is collected may become public through various court procedures.

   An incident response plan should clearly specify the person or persons from the organization who are authorized to contact law enforcement and under what circumstances triggers the contact. It should also state what information they can provide and what services they can request. The response plan should include all of the law enforcement agency communication ­contacts, including with the name of the individual and their working hours and after-hours contact information. Meetings should be held with all law enforcement contact personnel prior to any incident to gain a full understanding of the responsibilities of all parties.

2. Media Communication News media organizations in the world of 24/7 news coverage can be quite competitive in obtaining information that has the potential of being sensationalized through media outlets. Depending on how high the profile of the organization is or the type of information breach, media outlets may swarm the organization for information. Incident response teams should be trained and tested on how to redirect media questions and inquiries. It is important that all individuals within an organization understand the importance of information dissemination. Clear restrictions should be placed on the release of incident or information breach information through unauthorized channels such as Twitter, Facebook, or other social media sites.

   The incident response plan should also include the departments responsible for handling dissemination of specialized information such as the legal department, public-relations department, investor relations department, and marketing department. Each of these departments should be involved in an incident response plan and determine how they will handle distribution of different types of authorized information that should be released to the media, shareholders, customers, and affected individuals.

Building in Incident Response Team

An incident response team is the core of the incident response plan. The members involved in an incident response team may vary depending upon the structure of the organization or the nature of the incidents encountered The proper structure of an incident response team includes representatives of the IT ­department, the human resources department, legal services, public relations, executive management, accounting/auditing, and the physical security department. A good incident response team consists of named individuals, and their alternates, who participate in ­training and exercises to adequately perform their duties during an incident. Ad hoc or “only person available” team membership should be avoided, but if that's the normal response action for a department, each person that might respond should receive incident response training. Secondary or supporting team members should also be identified, such as network administrators, database administrators, and technical experts.

An incident response plan should also identify third-party forensic companies that may be engaged depending upon the severity level of the incident.

Incident response teams may be constructed both on needs and geographic requirements. Here are some of the different types of teams:

1. Full-Time Response Team This type of incident response team features full-time members who respond to incidents on a daily basis. Very large corporations, financial institutions, banks, and other organizations require full-time response teams based on the frequency of incidents.
2. Functional Response Team Functional response team members report to other managers and departments throughout the organization and become members of incident response teams when they are required. A typical structure for an incident response team involved members from the HR department, legal, information security, IT, and other departments make up an incident response team.
3. Outsourced Response Team Many organizations contract out network and system monitoring as well as the response to intrusions. Managed service contracts that involve handling incidents and providing incident response or offered by large organizations such as Hewlett-Packard, Dell and IBM. In many cases, the contract will also involve some local individuals within the ­company to assist the third-party response team. A hybrid incident response team is the combination of an external team and an internal team.

Incident Response Records

Incident response plans should be the requirement that the incident response team should be required to make incident response plans and keep activity records starting at the beginning of the incident and continuing through resolution. Team responders should record all actions and activities, either during the process or immediately thereafter, to completely document all actions taken during the event. The collection and documentation of all evidence, description of the scene, statements from individuals, and evidence processing notes must be filed and maintained in the event of a formal forensics examination or eventual legal action. Team responders should record all actions and activities, either during the process or immediately thereafter, to adequately document all actions taken. In the event of a forensic examination or eventual legal action, the collection and documentation of all evidence, description of the scene, statements from individuals, and evidence processing notes must be filed and maintained.

Many incident response teams regularly review after-action reports to identify areas of improvement.

A wide range of incident report templates are available on the Internet. At a minimum, the following incident response information should be recorded:

• Date and time of incident
• Type of incident or incident level
• Incident summary
• Incident discovery information
• Actions taken by individuals
• Contact information for individuals involved
• After-action report

Security Event Information

All digital records associated with an event that leads to an incident response must be retained. Event discovery or alerts may be triggered automatically through the use of intrusion prevention systems (IPSs) or intrusion detection systems (IDSs) or a number of other software solutions or hardware appliances. Events may also be discovered through manual review of system logs or other blog information.

Security Information and Event Management (SIEM) systems are used to provide a common platform to collect historical log information as well as real-time information from monitored devices. (Note that other texts may refer to this subject as Security Event and Information Management, or SEIM.) Applications are available that provide easy searching through multiple logs for correlating event information. The output logs of both real-time and historical investigations should be stored for an appropriate retention period. Corporate policy may require that event logs be kept for an indefinite period of time. The default on some log acquisition systems is 30 to 60 days.

Incident Response Containment and Restoration

The incident response plan should provide the details of all actions to be taken during a specific incident. Actions might include isolating the device from the network by, for example, disconnecting the Ethernet plug or pulling the power plug from the wall to shut down the affected network equipment. Plans may differ depending upon forensic investigation requirements. For instance, a forensic investigation might include disconnecting the device from the network but keeping the unit powered up so that volatile RAM memory can be recorded or examined. A Faraday bag may be utilized to shield a device that is connected to a wireless access point. A Faraday bag is designed as a shield to prohibit a device from transmitting or receiving radio signals.

It is never advisable to not take action and “monitor” an attack while it is in progress. In some cases, an IT individual may attempt to trace an attack back to its origin rather than terminating the attack. Such a trace is usually fruitless as attackers have many ways of disguising their actual location. Devices such as log files, monitoring appliances, honeypots, bastion hosts, and other devices may record the IP address or vectors of an attack. If an attack is discovered and not stopped, the organization may face various legal liabilities.

Many corporate incident response policies require that a post-incident restoration action be invoked after an attack. These usually require that the attack unit be reimaged or restored from known good backups. Rarely are devices placed back into service after only one anti-malware or antivirus scan.

Implementation of Countermeasures

Countermeasures are usually put in place as a response to a risk analysis. In many cases they are intended to mitigate specific threats or vulnerabilities. Controls involve a much broader category of risk mitigation tools and may be put in place in response to best practices or due care. In many situations, the terms countermeasure and control are used interchangeably.

As an SSCP, you may be involved in implementing countermeasures throughout the organization. These countermeasures may include hardware devices such as IPSs/IDSs, antivirus software, anti-malware software, and network-based hardware appliances. Countermeasures, such as intrusion detection and prevention devices, must be adjusted or tuned correctly to be effective on a network. A false sense of security may be prompted by an ineffectively adjusted protection device. Every network protection device should have an established baseline and the performance of the device should be measured regularly against the baseline.

The application of countermeasures in a network or on a device such as a host computer does not relieve the operators or administrators from responsibility. User training is important so that controls and countermeasures are installed and operated correctly.

Incident Scene

In general practice, it's advisable to refer to the physical location of an incident as an incident scene rather than a crime scene. This avoids a rush to judgment as well as possibly unfounded or inaccurate accusations of individuals at the location.

In the case of the cyber incident, the incident scene is located in two environments:

1. Physical Environment The physical environment is of course the actual location of the hardware involved. This may include simply the user workstation, a server in a rack, or even an entire network domain. In some cases the physical environment may be quite small, such as a cell phone, pad, or individual laptop.
2. Digital Environment The incident scene in a digital environment may be much more complex and require greater expertise to acquire materials and evidence. Some evidence may be retained in volatile RAM or on an attached hard disk drive, other evidence concerning the same incident may be stored on servers, network-attached storage, storage area networks, and even cloud-based storage. With each of these remote locations, increasingly sophisticated techniques may be required to acquire the evidence.

First responders to digital incident must be trained on how to preserve a digital incident scene. If evidence is contaminated, changed, or altered it is no longer any use during the investigation. During an attack or other incident, users should be educated to step away from their host machines workstations or other digital equipment to allow the incident response team and forensics examiners to gather material and data.

It is a well-known fact in forensic science that just observing evidence changes it. For instance, let's say that you want to check a file to see when it was last accessed. By doing this, you put the current date on that file.

Volatility of Evidence

The volatility of evidence determines the priority that evidence must be collected. The volatility is determined by the life expectancy of evidence once power is withdrawn. As might be expected, evidence resident in RAM will be deleted or eliminated once power is withdrawn.

The following list includes evidence from the most volatile to the least volatile:

• CPU, cache, and register contents
• Routing tables, ARP cache, process tables, kernel statistics
• Random access memory (RAM)
• Temporary file system/swap space/page files
• Data on hard disk
• Network archive data/storage area networks/network attached storage
• Remote-based cloud storage
• Data contained on archival media, disk-based backup, tape-based backup, USB drives

Forensic investigators usually acquire and process data in the order of volatility. Some incident response plans call for immediate disconnection and shut down of the target host or server. This eliminates the accessibility to any volatile memory that might be stored in RAM or register type devices.

Forensic Principles

Dr. Edmund Locard was a pioneer in forensic science and formulated Locard's exchange principle, which states that the perpetrator of a crime will bring something to a crime scene and leave with something from it. This is the foundation of trace evidence, that the perpetrator may leave dirt, hair, fingerprints, smudges, oils, or other residue at a crime scene. It also holds that the trace evidence from a crime scene will leave with the perpetrator, such as carpet fibers and other minute pieces of evidence that may link the perpetrator to the location.

In digital forensics, Locard's exchange principle holds that any perpetrator of an intrusion leaves behind trace evidence within the system. This trace evidence may be used to identify the attacker.

Chain of Custody

Chain of custody refers to a forensic principle whereby each movement or transfer of data must be recorded and logged appropriately. If the chain of custody is disrupted by any means, evidence may not be presented in court. Evidence should be appropriately identified, including the ­circumstances under which it was collected it, including a detailed description of the material when it was collected, as well as other important information. In most cases, evidence is packed in poly bags for transport to a forensic laboratory or storage location.

The evidence documentation must include, at a minimum, the following information:

• Date and time of collection
• Description of the evidence
• Who collected the evidence
• Incident identification or summary
• Evidence discovery information
• Actions taken by individuals
• Contact information for individuals involved
• Chain of custody
• Other collection or handling information

Proper Investigation and Analysis of Evidence

Proper steps must be taken to ensure that data could not be altered. While working with a live hard disk, the forensic investigator will use a specialized write-block hard disk controller that will prevent the writing of any information on the hard drive during an investigation. Figure 6.1 illustrates an industry-standard write blocker attached to a hard drive under investigation.

All data on a hard drive under investigation should immediately be copied using ­industry-standard bit copy software. Products such as EnCase, developed by Guidance Software, and Forensics Toolkit from Access Data offer a suite of tools used by digital forensic examiners to not only create a bit-for-bit copy of hard drive data but also hash the contents to ensure data integrity between the original hard drive source and the copy. The hash value will ensure that no changes have been made to the original disk image. The hash value for an image can be calculated and compared with the original hash value of the data. A data copy should always be used during an examination, while the original is stored as primary evidence.

Interpretation and Reporting Assessment Results

While the forensic examiner is performing the examination of the evidence, they will allow the character of the evidence to lead to various suppositions and potential conclusion ­possibilities. This is the interpretation process that the forensic expert will use to determine the importance or significance of various pieces of the evidence information. Through experience, training, and proven forensic examination techniques, the forensic examiner will interpret the data and formulate a conclusion. On occasion, the data will be insufficient to draw any conclusions.

Once the forensic examiner has examined the evidence, they will prepare a report. The examiner's report is very important as it provides information concerning the evidence, the analysis techniques, and the resulting findings to the incident investigator, the prosecutor, other attorneys and possibly the court by way of testimony. Forensic examiner reports differ in content but generally contain the following sections:

• Summary of findings
• Identity of the reporting agency
• Incident or case identifier or submission number
• Incident or case investigator
• Identity of the forensic examiner
• Identity of the submitter (if different)
• Date of receipt of evidence
• Date of report
• Descriptive list of items submitted for examination, including serial number, manufacturers, make, and model
• Identity and signature of the examiner
• Brief description of steps taken during examination, such as string searches, graphics, image searches, and recovering erased files
• Detail of findings
• Results/conclusions

It is quite common for either legal side of the court case to request to see the “examiner's notes.” The forensic investigator must keep a log of every action taken and test applied during the evidence examination process.

Emergency Response Plans and Procedures

Emergency response plans differ from incident response plans in that an incident response plan usually refers to a network intrusion. Emergency response is generally much broader in nature. For instance, an incident may be a network intrusion that plants malware on ­several host machines. An emergency is the network being down for an appreciable amount of time, affecting ongoing business operations.

There are two types of emergency response plans:

1. Disaster Recovery Plan A disaster recovery plan (DRP) is a documented set of procedures used to recover and restore IT infrastructure, data, applications, and business communications after a disaster event. A disaster may be natural, in the form of a flood, tornado, or wildfire, or it may be man-made, in the form of a terrorist attack or willful destruction of property. Man-made disasters can be intentional or unintentional.
2. Business Continuity Plan The business continuity plan (BCP) is a documented set of procedures used to continue business operations in some form to enable the organization to maintain its business capacity during some event. This plan may entail substituting equipment or workspaces, temporarily relocating equipment and individuals, and reducing or eliminating noncritical services for a period of time. An event for which a business continuity plan can be used might be a localized fire, power outage, weather-related event, or man-made disaster.

Business Continuity Planning

Business continuity planning is a set of procedures and prearrangements that can be put into action in the event of a disaster. The effort of the continuity plan is to maintain, as best as possible, business as usual in the face of a crisis. The business continuity plan is the result of a business continuity policy approved at the executive level. A substantial commitment of personnel and funds is required to achieve an actionable plan. Without significant corporate executive support, a business continuity plan stands little chance of success.

A number of terms are used when creating a business continuity plan. These terms are described in the following sections.

Recovery Point Objective

Recovery point objective (RPO) specifies a point in time to which data can be restored. The recovery point could be the last full backup plus any completed incremental or differential backups that might've taken place after the full backup. The more frequent the backup, the less data will be lost during a business disruption event. For instance, if the organization uses a dual-write technique such as a RAID-1 mirror backup where the ­second drive is a cloud drive or off-premises drive, the recovery point objective could be at the point of the business disruption event.

Figure 6.2 illustrates a timeline with the business disruption event in the center (the crash event). The maximum tolerable downtime (MTD) indicates the maximum time the organization can be without the business operational unit. The recovery time objective (RTO) is the point at which full operation will be restored, and the recovery point objective (RPO) indicates the point in time at which reliable data for backup purposes is available. Notice that the vertical line represents cost. The bell-shaped graph represents a cost ­versus timeline. For example, the closer you move the recovery time objective to the business disruption event, the more it will cost the organization. The closer you move the recovery point objective to the business disruption event, meaning that backups are made more frequently (up to complete data mirroring), the more costly it is for the firm to create the backups.

Since business units require IT processing to perform their duties, IT systems and business network capabilities must be fully operational prior to the maximum tolerable downtime (MTD) of the departments served.

Disaster Recovery Planning

After a disaster event, it is extremely important to restore IT services and functions. The restoration process may be detailed for a disaster recovery plan. The high-level disaster recovery policy is an executive-supported policy that sets forth the creation of the disaster recovery plan (DRP).

In the event of a disaster affecting IT operations, all IT personnel, including you as an SSCP, will participate in recovery efforts to restore IT services as soon as possible. As you have seen, in business continuity planning, the majority of business operations are contingent upon active and reliable IT services and functions.

The difference between a disaster recovery plan and an incident response plan is that an incident response plan details the methods and procedures used to detect and stop an imminent threat to the organization's IT assets while the disaster recovery plan is designed to rebuild, recover, and restore damaged assets to full operational capacity. Restoration operations may take a period of time and significant coordination and effort to rebuild or refurbish facilities, restore order, restore and provision hardware products, and restore data and applications from backup sources.

There are some things to consider during the creation of the disaster recovery plan. Some of these considerations are detailed in the following sections.

Identification and Ranking of Disaster Types

As with incident response planning, a disaster recovery plan begins with identifying various disaster types. Disasters may be the result of either natural causes or man-made causes. Natural disasters include hurricanes, tornadoes, mudslides, forest fires, floods, and other disasters caused by weather-related events, and man-made disasters, either intentional or unintentional, may be caused by fires, bombs, terrorist activities, civil unrest, and acts of war, just to name a few.

It is very difficult to have a large number of disaster plans with a response to each ­particular type of disaster. Imagine communicating to a senior executive on the phone that IT operations has experienced a disaster due to fire. The very next question might be, How big was the fire? Was it localized? Did it take down the entire IT installation and facility? And how serious was it? So as you can see, the overall effects of disasters might differ.

Many organizations find it convenient to establish a disaster classification system to describe to all individuals the severity of the disaster and the type of restoration response to expect. Figure 6.3 illustrates a typical disaster classification chart. In this example, there are only three grades of disasters—one, three, and five—which allows for other numbers or levels of classification to be substituted if required. Other columns may be added to indicate programs of plans to invoke, persons to notify, and other disaster information.

Interim or Alternate Processing Strategies

During a disaster event and recovery operation, the primary IT facility may not physically be available to carry out IT operations. In some disaster scenarios, it may be temporarily disabled, while in other, more severe scenarios, it may be totally destroyed and need to be totally rebuilt.

The disaster recovery plan must include the possibility of relocating IT operations. The different relocation options will respond directly to the recovery time objective. For instance, services may be made available for almost instant switchover, while other services may require the transportation and configuration of hardware in a remote location. Each strategy affects the variables of time to restore services and cost to restore services.

1. Hot Site A hot site is an alternate IT processing facility that can be brought online within a very short period of time. The hot site will maintain duplicate equipment but no applications or data. The hot site will maintain duplicate equipment and duplicate sets of data. To be effective, the hot site should be significantly geographically separate from the primary site so it's not involved in the same disaster. If the hot site is not an integral function of the organization and is a third-party contractor location, in many cases it is utilized for a short period of time, measured in either hours or days, while a less costly alternate site is made ready.
2. Warm Site A warm site is an alternate IT processing facility that has equipment installed and usually configured. The warm site does not have duplicate data installed and must be provisioned from backups. It is less costly than the hot site and still requires hours and sometimes days to bring online.
3. Cold Site A cold site is a location that is provisioned with HVAC, power, and communications lines and can be used for complete IT restoration. A cold site does not have network hardware or communications equipment. Equipment would have to be ordered, shipped in, and installed. After installation, all data would have to be restored from backups. With testing and configuration, a cold site offers the longest recovery time, requiring in many cases weeks of preparation. But on the other hand, it is the least costly.
4. Contracted or Mutual Sites A contracted or mutual site is made available through an arrangement with the IT department of another organization, where the other organization offers equipment and processing time under a contract or by mutual agreement. This type of an arrangement may also be between different IT departments or divisions within the same organization. In some instances, a mutual site is referred to as a multiprocessing site—one site cannot support the entire IT department, so multiple sites are used as a type of cluster. Normally this scenario is similar to a warm site, where the contracting organization offers access to IT processing capacity and data must be restored from backups to begin operation.
5. Cloud Sites Cloud providers now offer a service that consists of the use of either a hot site or a warm site, depending on costs and requirements. Using the Infrastructure as a Service (IaaS) model, the cloud service provider can rapidly duplicate the client's IT service configuration and provision data from backup locations. Some organizations are making use of cloud sites for immediate switchover, while other organizations make use of a less costly service that will require a little more time to bring online.
6. Mobile Sites A mobile site is a site usually based in 18-wheeler trailers. Under contract, this type of site may be transported to the required location. Mobile sites can be expanded by connecting trailers of equipment together. Mobile sites are usually self-contained and feature a portable generator system to power the equipment. Depending upon the contract, 18-wheeler trailers may be dedicated and outfitted with the exact equipment required to duplicate the IT operation. Transportation, availability, and available communications infrastructure should be prime considerations in using a mobile site and a disaster recovery plan.

When employing any of the types of recovery site options, the planners must consider several important factors:

• Transportation of essential personnel to the backup location
• Room and board for essential personnel at the backup location
• Commitment of essential personnel, which may be hindered by the possibility of the destruction of homes, local infrastructure, and dislocation of immediate family
• Salaries, payment for personnel living expenses, and transportation

It is important to consider cross training of personnel or duplicate personnel with alternate skill sets and the availability of contractors in the remote recovery site location.

Restoration Planning

Disaster preparedness and restoration planning is the formulation of plans that reduce the vulnerability to threats and provide a set of procedures for restoration after a disaster event. In addition to the safety and protection of human life, many other items must be taken in consideration during the creation of a disaster recovery plan:

• Power and essential communications
• Personnel in the labor force
• Essential supplies such as shelter, food, and water
• Transportation
• Building materials and construction components
• Data processing hardware and infrastructure components
• Data communications
• Backup data

Disaster preparedness planners, when creating a disaster recovery plan, should consider alternate sources for any of these requirements.

Backup and Redundancy Implementation

It is important that as a security practitioner you are familiar with all of the different types of backup and data restoration solutions. Data backup and restoration solutions are driven by two primary considerations: time and cost. As you saw with recovery time objectives (RTOs) and recovery point objectives (RPOs), fast recovery times and minimal data loss come with a price. By varying the time frame, not only is the cost affected, but the type of technology used for data backup storage may change.

Not all data needs to be backed up equally. When creating a backup program for the organization, data may be prioritized by importance or frequency of use. For instance, data required for immediate use, such as customer information or accounting data, may be considered vitally important to corporate operations. The decision might be made to prioritize this data and back it up in such a manner as to provide a very fast restoration process. Other data, such as sales transactions, database archives, or archived communications such as emails, may be backed up using a method that is far less expensive and may require a much longer time to restore.

In years past, data was backed up sequentially on magnetic tape. Many may remember the reel-to-reel tapes featured in science-fiction movies. While some of these devices still exist in mainframe computer centers, most tape backup today is performed on tape cartridges and specialized machines. It is not unusual to back up data on DVDs and hard disk arrays and to the cloud.

When removable media is involved, various backup scenarios may be used. The selection of the backup scenario is based upon several factors:

• Required time to back up all of the data
• Required time to restore all of the data
• Cost of labor in time and effort
• Cost of backup media (life of backup media)

When considering these criteria, several backup scenarios can be employed. Of course, at some point in time all of the data must be backed up, which is usually referred to as a full backup. The selection of backup techniques between full backups depend upon the ­criteria. Various backup techniques are described in the following sections.

Differential Backup

A full backup may be created once a week, then daily backups must be made of the transactions for each day. The differential backup records all of the transactions since the full backup. For instance, the transactions occurring on Monday will be recorded. On Tuesday, all of the transactions occurring on Tuesday will be added to the backup of all of the transactions occurring on Monday. On Wednesday, all of the Wednesday transactions will be added to the backup of all of the Monday and Tuesday transactions. So on each day, the transactions are just appended to the previous day's backup file.

The advantage is in the event of a restoration, only one file must be added to the full backup file to create a record of all transactions that have occurred. The disadvantage may be in media cost; the backup for each day requires more media because of the amount of data stored each day. Figure 6.4 illustrates the concepts of a differential backup.

Incremental Backup

Again, assuming a full backup was created once a week, daily backups must be ­created for the transactions of each day. In the case of incremental backup, the transactions occurring on Monday are backed up into a file. Tuesday's transactions are backed up into a second file. Wednesday's transactions are backed up into a third file. Thursday and Friday transactions are similarly backed up into separate files. In the event of a restoration, each of the files must be added to the others and finally to the full backup to form a contiguous data file containing not only all of the existing information from Sunday but also the information from the rest of the week.

The advantage to this program is that each day's backup may be created much faster. Each day's data is in one file. The cost of media for each day is reduced because it is only storing one day's worth of information. The obvious disadvantage is that if a full restoration is required, it takes much longer to combine all of the different daily files together with the full backup prior to being able to restore all the data to the affected device. Figure 6.5 illustrates incremental backup.

Business Continuity Plan and Disaster Recovery Plan Testing and Drills

The business continuity plan (BCP) and disaster recovery plan (DRP) should be verified at least once every year. This procedure is accomplished through the use of a variety of tests and drills with the personnel involved. The various types of tests are based on time, cost, complexity, and risk to the organization. For example, taking the IT department offline to test the capability of a failover to a remote site might pose a substantial risk to the organization. However, many government and military organizations perform this type of test to test readiness in the event of an emergency.

There are various types of tests used to validate either the business continuity plan or the disaster recovery plan:

1. Checklist Test The checklist or desk check test is performed by the personnel involved in the plan. Primarily, it involves mentally understanding their responsibilities, reviewing procedures, and updating contact and other required information. Individuals are asked to document any changes or updates made to their areas of responsibility since the last checklist test.
2. Structured Walk-Through Test In a structured walk-through test, individuals with responsibility of performing some action or activity in the plan, as well as individuals from key departments involved in the plan, attend a structured walk-through meeting. During the meeting, those involved validate that the plan is correct and that they understand their responsibilities. The structured walk-through test is the most common of the plan tests and may be performed frequently across different business units.
3. Simulation Test The simulation test features actual steps that would be taken during an actual emergency or disaster. For instance, files may be restored from backup, generators may be started and switched over, and other physical items may be tested. This is a simulation, and all individuals involved are aware of that. The normal business of the organization is not affected by a simulation test. The output of a simulation test is to specifically test the validity of the plan and the activities, techniques, and responsibilities as specified in the plan.
4. Parallel Test A parallel test involves performing IT processing using alternate techniques such as a hot site or warm site. Throughout this test, organizational activities are not interrupted. This type of test must be planned for and budgeted because it incurs substantial cost to the organization. Individuals must be transported to an alternate site, data must be restored from remote backups, and processing must occur as if it were a production site. On many occasions, auditors or observers record the activities.
5. Full Interrupt Test In full interrupt testing, business operations are interrupted and the alternate site is brought online into full operation. Processing is performed using the alternate site data and equipment. As can be imagined, this type of test is very intrusive and disruptive to ongoing operations. The organization faces great risk when performing full interrupt testing. A number of things can go wrong, including not being able to bring the original site back to full production mode in a timely manner.

As an SSCP, you will be expected to perform many roles as assigned during both ­continuity and disaster preparedness testing. You must understand the reasons for the ­testing and the importance of your role to its success.