Photo credit: KAREN BLEIER/AFP/Getty Images

In breaking news directly related to data security policies, FoxNews is reporting that the World Bank has suffered possibly “the worst security breach ever at a global financial institution”:

 The World Bank Group’s computer network — one of the largest repositories of sensitive data about the economies of every nation — has been raided repeatedly by outsiders for more than a year, FOX News has learned.

It is still not known how much information was stolen. But sources inside the bank confirm that servers in the institution’s highly-restricted treasury unit were deeply penetrated with spy software last April. Invaders also had full access to the rest of the bank’s network for nearly a month in June and July.

In total, at least six major intrusions — two of them using the same group of IP addresses originating from China — have been detected at the World Bank since the summer of 2007, with the most recent breach occurring just last month.

While it remains unclear how much data has been pilfered from the bank, it’s a lot. According to internal memos, “a minimum of 18 servers have been compromised,” including some of the bank’s most sensitive systems — ranging from the bank’s security and password server to a Human Resources server “that contains scanned images of staff documents.”

One World Bank director tells FOX News that as many as 40 servers have been penetrated, including one that held contract-procurement data.

Despite the gravity of the break-ins, the bank is trying hard to pretend to outsiders it didn’t happen. “There were attempts to hack the bank’s computer systems last summer,” says a World Bank spokesman. “However, there was no compromise of confidential information.”

So if this actually happened, which data security policies could have helped prevent the “the worst security breach ever at a global financial institution”?

• Corporate Security Policy
• Incident Response Policy
• Network Security Policy
• Vulnerability Management Policy

Others?

The IT Security group at the California Department of Techonology Services (DTS) have a security incident response presentation here that describes their incident response plan.

This presentation includes a couple of scenarios where they demonstrate how to implement the Security Incident Lifecycle:

• Security Incident Identification
• Security Incident Triage
• Security Incident Response & Resolution
• Security Incident Communication (concurrent)
• Post Security Incident Documentation

Great info!

The American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA) created an Incident Response Plan template which you can find here.

It contains a lot of useful info, including a good description of an Incident Response Team. Here’s an excerpt:

An Incident Response Team is established to provide a quick, effective and orderly response to computer related incidents such as virus infections, hacker attempts and break-ins, improper disclosure of confidential information to others, system service interruptions, breach of personal information, and other events with serious information security implications. The Incident Response Team’s mission is to prevent a serious loss of profits, public confidence or information assets by providing an immediate, effective and skillful response to any unexpected event involving computer information systems, networks or databases.

The Incident Response Team is authorized to take appropriate steps deemed necessary to contain, mitigate or resolve a computer security incident. The Team is responsible for investigating suspected intrusion attempts or other security incidents in a timely, cost-effective manner and reporting findings to management and the appropriate authorities as necessary. The Chief Information Security Officer will coordinate these investigations.

The Incident Response Team will subscribe to various security industry alert services to keep abreast of relevant threats, vulnerabilities or alerts from actual incidents.

It also suggests that the incident response team be composed of the following members:

• Information Security Office (ISO)
• Information Technology Operations Center (ITOC)
• Information Privacy Office (IPO)
• Network Architecture
• Operating System Architecture
• Business Applications
• Online Sales
• Internal Auditing

An archive of the template can be found here: Incident Response Plan Template

Great info! Check it out!

An excellent template for an Incident Response Policy can be found in RFC 2350 here. While this is a template for a computer security incident response team (CSIRT), it has a lot of the same structure you would need for an Incident Response Policy.

It even has a filled out example of the template. Here’s an excerpt:

5.1.2 Incident Coordination

• Determining the initial cause of the incident (vulnerability exploited).
• Facilitating contact with other sites which may be involved.
• Facilitating contact with XYZ University Security and/or appropriate law enforcement officials, if necessary.
• Making reports to other CSIRTs.
• Composing announcements to users, if applicable.

5.1.3 Incident Resolution

• Removing the vulnerability.
• Securing the system from the effects of the incident.
• Evaluating whether certain actions are likely to reap results in proportion to their cost and risk, in particular those actions aimed at an eventual prosecution or disciplinary action: collection of evidence after the fact, observation of an incident in progress, setting traps for intruders, etc.
• Collecting evidence where criminal prosecution, or University disciplinary action, is contemplated.

In addition, XYZ-CERT will collect statistics concerning incidents which occur within or involve the XYZ University community, and will notify the community as necessary to assist it in protecting against known attacks.

Check it out!

Cynthia Bonnette, the Director of Information Security Risk Assessment for NETBankAudit in Arlington, VA wrote a sample incident response policy which appeared in this issue of the AML Compliance Alert here.

Here’s an exerpt:

INCIDENT IDENTIFICATION, CLASSIFICATION AND ESCALATION

Once detected, suspected incidents (e.g., anomalous activity) must be reported. The nature and severity of the incident will determine the appropriate response strategy. The Information Security Officer (ISO) or Security Officer classifies the threat severity based on the definitions below. The ISO or Security Officer is also responsible for determining when to escalate or downgrade the severity level of an incident based on changes in circumstances and the discovery of additional information.

Severity levels are as follows:

High. A high level event is an event that can cause significant damage, corruption, or loss (compromise) of confidential, critical and/or strategic bank and customer information. The event can result in potential damage and liability to the bank and to its public image and may degrade customer confidence concerning the bank’s products and services (e.g., online banking). Examples: computer intrusions, compromise of critical information, widespread virus infection, attacks against the IT infrastructure (e.g., domain name servers, firewalls and backup systems) and denial-of-service attacks that disable a critical service or impede business performance.

Medium. A medium level event is an event that may cause damage, corruption, or loss of replaceable information without compromise or may have a moderate impact on the bank.s operations or reputation. Examples: misuse or abuse of authorized access, accidental intrusion, confined virus infection, unusual system performance or behavior, system crashes, installation of unauthorized software, unexplained access privilege changes or unusual after-hour activities.

Low. A low level event is an event that causes inconvenience, aggravation, and/or minor costs associated with recovery, unintentional actions at the user or administrator level, or unintentional damage or minor loss of recoverable information. The event will have little, if any, material impact on the bank.s operations or reputation. Examples: sharing of passwords, policy or procedural violations, and scans of bank systems (except online banking or investing systems, which are medium level events).

Worth looking at for a jump start on developing your own incident response policy. Check it out!

Here is a good example of an online incident reporting form that you can use as part of your incident response process. It’s from the State of North Carolina Office of Information Technology Services.

Here are some of the areas covered on the form:

• Physical location (s) of victim’s computer system/network
• IP Address of attacked or compromised host/network
• Is the affected system/network critical to the organization’s mission?
• Which Critical Infrastructure sector was affected?
• Nature of Problem?
  • Intrusion
  • System impairment/denial resources
  • Unauthorized root access
  • Web site defacement
  • Compromise of system integrity
  • Hoax
  • Theft
  • Damage
  • Unknown
  • Other
• Has this problem been experienced before?
• Suspected method of intrusion/attack
  • Virus (provide name if known)
  • Vulnerability exploited (explain)
  • Denial of Service
  • Trojan horse
  • Distributed Denial of Service
  • Trapdoor
  • Unknown
  • Other
• Suspected perpetrator(s) or possible motivation(s) of the attack
• The apparent source (IP address) of the intrusion/attack
• Evidence of spoofing?
• What computer system (hardware and/or software) was affected?
• Did this incident involve a suspected or actual breach of confidential or personally identifiable information?
• Did the intrusion/attack result in damage to system(s) or data?
• What actions and/or technical mitigation have been taken?
• Incident Priority

Here’s an archived copy of the form: Incident Reporting Form

You might want to read this classic article called “How to Design a Useful Incident Response Policy” here.

I love this visual representation of a simplistic incident response process:

Here’s the incident response policy used at Yale.

Parts of the policy include:

• Identification of Incidents
• Establishment of an IT Security Incident Response Team
• Risk Assessment Classification Matrix
• Documentation and Communication of Incidents
• Subordinate Procedures
• Role of Yale Personnel, Training
• Incident Prevention

This is an exerpt from the Risk Assessment section:

The ISO will establish an internal risk assessment classification matrix to focus the response to each Incident, and to establish the appropriate team participants to respond. This classification matrix will correspond to an “escalation” of contacts across the University, and will indicate which authorities at Yale to involve and which procedure would be applicable for each class of incident.

An archived copy of the policy is here.

Here’s a helpful white paper by Kerry Thompson that describes best practices that you should follow when responding to a security incident.

I like the part about the incident team. Here’s an exerpt:

An incident team for a small to medium enterprise is almost always two people. One will be the technical lead who will perform the bulk of the remedial work, and the other will be a backup person reporting to management and recording the actions taken. Further people may be involved depending on the size of the organisation, usually in the reporting chain rather than in direct involvement. These may include:

• the IT manager
• the CEO/CIO/CTO
• Media relations
• Legal
• Law enforcement

Always get help if you feel the situation is getting out of hand. For example, in one case an incident involving malware infection dragged on for two weeks before someone was called in to diagnose the problem and resolve it within an hour. Get equipment and software tools if required.

Other areas covered include:

• Forming a plan for resolution
• Return to operation
• Preventing reoccurance
• Review the causes
• Review resolution
• Create a final report

Check it out!

Your Data Security Incident Response Policy should include a reference to your Incident Response Plan or Procedure which should require that an Incident Report be completed for each security incident. An incident report example can be found at the California Department of Finance page here.

This is a very thorough report that requires you to fill in information on topics like:

• Date and Time Incident Occurred
• Description of Incident
• Estimated Cost of Incident
• Corrective Actions Taken to Prevent Future Occurances
• Estimated Costs of Corrective Actions
• Have Those Responsible for the Incident Been Identified?
• If So, How Many Individuals Were Involved?
• Will Criminal Charges Be Filed?

Check it out here.