oversight

L21L0001 -Investigative Program Advisory Report (IPAR) Incident Response and Reporting Procedures - Date Issued: 07/18/2011 PDF (485K)

Published by the Department of Education, Office of Inspector General on 2011-07-18.

Below is a raw (and likely hideous) rendition of the original report. (PDF)

                 UNITED STATES DEPARTMENT OF EDUCATION
                                      OFFICE OF INSPECTOR GENERAL

                                                  Information Technology Audits and Computer Crime Investigations




DATE:	         July 18, 2011

TO:	           Danny Harris
               Chief Information Officer

FROM:	         Charles E. Coe, Jr. /s/
               Assistant Inspector General
               Information Technology Audits and Computer Crime Investigations

SUBJECT:	      Investigative Program Advisory Report
               Incident Response and Reporting Procedures
               (10-110283) Control Number L21L0001


The O ffice of Inspector G eneral ( OIG) h as c onducted i nvestigations of pot ential c omputer
crimes over the past two years. D uring these investigations, OIG has identified problems with
how t he U .S. D epartment of E ducation ( Department) ha ndled computer s ecurity i ncidents.
Specifically, the Department did not detect, report, or respond to incidents in accordance with the
Department’s Handbook for Information Security Incident Response and Reporting Procedures,
OCIO-14.

To ensure the Department’s systems and networks are protected, OIG made one
recommendation:

       1.	 Enforce the contract’s requirement for Perot Systems to comply with OCIO-14 when
           performing incident response, or develop a separate capability to perform incident
           response in accordance with OCIO-14. The incident response capability, whether or
           not maintained by Perot Systems, should include:

               •	 Providing incident response personnel with the appropriate training and tools
                  to collect and preserve evidence in a quick and forensically sound manner (in
                  person or remotely);
               •	 Analyzing information to determine the root cause of an incident and to
                  determine the extent of damage;
               •	 Implementing appropriate hardware, software, and procedures to activate full
                  content network monitoring in a timely manner to support the incident
                  response process and to assist in discovery of the incident’s root cause.
Attached is the subject Investigative Program Advisory Report (IPAR) that covers our review of
the Incident Response and Reporting Procedures.


                                                 550 12th St SW, Suite 8000
                                                  Washington, DC 20202

                  The Department of Education's mission is to promote student achievement and preparation
                  for global competitiveness by fostering educational excellence and ensuring equal access.
Page 2 – IPAR - Incident Response and Reporting Procedures


Corrective actions proposed (resolution phase) and implemented by your staff will be monitored
and tracked in the Audit Accountability and Resolution Tracking System (AARTS). Department
policy r equires t hat you de velop a f inal c orrective a ction pl an ( CAP) f or our r eview i n t he
automated s ystem within 45 da ys of t he i ssuance of t his report. T he C AP s hould s et forth t he
specific act ion i tems, an d t argeted co mpletion d ates, n ecessary t o i mplement f inal co rrective
actions on the findings and recommendation contained in the IPAR.

If you have any questions concerning this IPAR, please contact Special Agent in Charge, Mark
A. Smith at (202) 245-7019.

Attachment
            UNITED STATES 

   DEPARTMENT OF EDUCATION 

    OFFICE OF INSPECTOR GENERAL 





  Investigative Program Advisory Report 



Incident Response and Reporting Procedures 

               (10-110283) 


        Control Number: L21L0001 



               July 14, 2011 

IPAR: Incident Response and Reporting Procedures - L21L0001




Table of Contents
Acronyms/Abbreviations Used in this Report ................................................................................ 3
	
Incident Response and Reporting Procedures................................................................................. 4
	
A. Executive Summary .................................................................................................................. 4
	
B. 	Background ............................................................................................................................... 4
	
           The EDUCATE Contract.................................................................................................... 5
	
C. The Department has not Detected, Reported, or Responded Appropriately to Security
	
Incidents.......................................................................................................................................... 6
	
           Malware Infection of EDUCATE Systems......................................................................... 7
	
           EDUCATE Connections to a Known Malicious Website .................................................. 7
	
D. Conclusion ................................................................................................................................ 9
	
E. Recommendations ................................................................................................................... 10
	
Attachment 1 - Previous Findings................................................................................................. 11
	
Attachment 2 - OCIO-14 Incident Response Life Cycle .............................................................. 12
	




                                                                                                                                                   2
IPAR: Incident Response and Reporting Procedures - L21L0001


                      Acronyms/Abbreviations Used in this Report

CIO             Chief Information Officer
CSMC            Cyber Security Management Center
Department      U.S. Department of Education
EDCIRC          U.S. Department of Education’s Computer Incident Response Capability
EDUCATE         Education Department Utility for Communications, Applications and Technology
                Environment
IT              Information Technology
MSSP            Managed Security Services Provider
NetBIOS         Network Basic Input/Output System
NIST            National Institute of Standards and Technology
OCIO            Office of the Chief Information Officer
OCIO-14         Handbook for Information Security Incident Response and Reporting Procedures
OCIO-IA         Office of the Chief Information Officer, Information Assurance Services
OIG             Office of Inspector General
SER             Suspicious Event Report
SLA             Service Level Agreements
US-CERT         United States Computer Emergency Readiness Team




                                                                                               3
IPAR: Incident Response and Reporting Procedures - L21L0001



                            Investigative Program Advisory Report
                       Incident Response and Reporting Procedures

A. Executive Summary

During Office of Inspector General (OIG) investigations of potential computer crimes over the
past two years, OIG identified problems with how the U.S. Department of Education
(Department) handled computer security incidents. Specifically, the Department did not detect,
report, or respond to incidents in accordance with the Department’s Handbook for Information
Security Incident Response and Reporting Procedures, OCIO-14, which is based on Federal
guidelines and industry best practices.
OIG reported these issues to the Department starting in March 2009 (Attachment 1). These
failures have prevented the collection of information that could aid the Department in identifying
all compromised computers, the actions or vulnerability that enabled the incident, the objective
of the incident, and the source. They have left the Department’s systems and data vulnerable.
In this report, we articulate our concerns and make a recommendation to address these problems.


B. Background

The Department’s Chief Information Officer (CIO) is responsible for developing and enforcing
the policy and procedures for information technology (IT) security within the entire Department.
One aspect of IT security is the monitoring and detection of security incidents on a computer or
computer network and properly responding to those incidents. OCIO-14 1 contains Department
requirements related to incident response and reporting procedures.
OCIO-14 defines a computer security incident as “a violation or imminent threat of violation of
computer security policies, acceptable use policies, or standard security practices.” 2 Pursuant to
OCIO-14, Office of the Chief Information Officer (OCIO) Information Assurance Services
(OCIO-IA) manages the Department’s Computer Incident Response Capability (EDCIRC),
which serves as the primary Department-wide contact for all incident reporting and response
activities. The EDCIRC coordinator is responsible for analyzing each incident and coordinating
the response and additional reporting activities, to include the reporting of critical incidents to
the United States Computer Emergency Readiness Team (US-CERT). 3

Under OCIO-14, OIG performs investigations in response to attacks against, as well as the
unauthorized access of, Department information systems, networks, databases, and computer
communication systems. OCIO-14 also states it is necessary for any incident responder to
1
  OCIO-14 dated June 26, 2007, was updated on March 2, 2011. Unless otherwise specified, both versions of
	
OCIO-14 are substantially similar for the issues addressed in this Investigative Program Advisory Report.

2
  OCIO-14 adopted the definition of the National Institute of Standards and Technology (NIST). NIST Special
	
Publication 800-61: Computer Incident and Security Handling Guide, Revision 1 (March 2008).

3
  US-CERT is the Federal Incident Management Center for the Federal Government and serves as the focal point for
	
cyber-security issues in the United States.
	
                                                                                                               4
IPAR: Incident Response and Reporting Procedures - L21L0001


coordinate his or her actions with EDCIRC prior to taking any actions that may affect the data on
a system. EDCIRC is directed to consult with OIG on appropriate actions to ensure that all
potential evidence is preserved.

The EDUCATE Contract

The “Education Department Utility for Communications, Applications, and Technology
Environment” (EDUCATE) contract between the Department and Perot Systems established a
contractor-owner, contractor-operated IT service model for the Department under which the
contractor is required to provide the total IT platform and infrastructure to support Department
employees in meeting the Department’s mission.
EDUCATE’s Performance Work Statement, 6.1.1.6 – Security & Privacy Information
Assurance, states in pertinent part,
        The contactor shall protect and defend information and information systems by ensuring
        their availability, integrity, authentication, confidentiality, and non-repudiation. This
        includes providing for restoration of information systems by incorporating protection,
        detection, and reaction capabilities. The contractor shall provide comprehensive and all-
        inclusive security and privacy operations for EDUCATE IT Resources and services on a
        24/7/365 basis. The contractor shall provide all necessary IT Resources to deliver all
        security and privacy operations herein. These services shall include all security and
        privacy operations in accordance with all Federal authorities (laws, regulations), Federal
        standards and guidelines, and Government and Department Policy (please refer to the
        Constraints section).
The referenced Constraints section states in pertinent part,
        The contractor’s proposed solution shall be compliant, in all respects, with all applicable
        federal and departmental security, acquisition, IG, and asset management laws,
        regulations, rules, and policies. As new laws, regulations, guidance and policy is [sic]
        promulgated, the contractor is expected to review, plan for and comply with such
        authorities. The contractor shall comply with the following authorities included in, but
        not limited to, Sections 8.1 through 8.8.
        At section 8.8.8, included among listed Department of Education Policies, is the
        “Handbook for Information Security Incident Response and Reporting Procedures”
        (OCIO-14).
To clarify these security operations, the EDUCATE contract has Service Level Agreements
(SLAs), which provide and describe the performance metrics needed to accomplish the intended
mission. The SLAs covering Security Operations and Incident Response require the contractor
to provide security operational services as determined by mutually agreed upon procedures, in
accordance with US-CERT Federal Incident Reporting guidelines as defined at the time of the
SLA’s approval, and in accordance with the Infrastructure Solutions Security Operations Center
Standard Operation Procedure (SOC SOP).


                                                                                                      5
IPAR: Incident Response and Reporting Procedures - L21L0001


In August 2008, the Department acquired the independent services of the Cyber Security
Management Center (CSMC) through an interagency agreement with the U.S. Department of
Transportation. 4 This agreement states the objective is to “provide continuous monitoring and
testing to ensure the EDUCATE contractor(s) delivers real-time detection, assessment, response
and remediation related to all relevant cyber incidents.” All incidents detected by CSMC are
forwarded to EDCIRC. As set forth in OIG’s Final Alert Memorandum, Implementation of the
Managed Security Services Provider Contract, Control Number ED-OIG/L19K0011, dated
September 24, 2010, (b) (7)(E)




To provide additional monitoring, the Department signed an interagency agreement with US-
CERT to monitor the EDUCATE network with the Einstein program. The Einstein program
monitors the network gateways of the participating agencies for unauthorized traffic. Thus, it
provides the Federal civilian government with a process for collecting, correlating, analyzing,
and sharing computer security information. The Einstein program is not meant to replace an
agency’s own security filtering or intrusion-detection systems, but it does provide US-CERT
with the intelligence to see activity in various parts of the Federal networks and to alert on
suspicious traffic if it is identified. US-CERT sends suspicious traffic information concerning
the EDUCATE network to EDCIRC for additional investigation. (b) (7)(E)


(b) (7)(E)




C. The Department has not Detected, Reported, or Responded Appropriately to Security
Incidents

Under OCIO-14 and applicable procedures, once a computer security incident is discovered, a
number of actions are required (Attachment 2). The incident must be reported and evidence of
the incident must be properly collected and reviewed (the detection/identification phase); the
incident must be stopped before it spreads or causes more damage, the actions performed must
be documented, and the destruction of evidence must be prevented (the containment phase); the
cause of the incident must be identified and mitigated (the eradication phase); the affected
systems must be restored to an unaffected state (the recovery phase); and the data and process
must be reviewed to determine if there are any lessons learned (the follow-up phase). A root
cause analysis (RCA) must be also be performed. 5


4
  The interagency agreement was renegotiated on August 13, 2010.
5
  SLA SP-1 was the primary SLA applicable to the incident response process, and prior to its March 2011 revision,
explicitly referenced an RCA. The current SLAs incorporate the SOC SOP which requires an RCA. OCIO-14,
dated 03/02/2011, requires a root cause analysis to be performed as part of the final stage in the incident response
life cycle. The previous version of OCIO-14, dated 06/26/2007, did not specifically state a root cause analysis was
                                                                                                                       6
IPAR: Incident Response and Reporting Procedures - L21L0001


Prompt notifications, the initial response, and access to data pertaining to the incident are all
critical to ensuring that evidence is preserved, that the incident can be properly contained and
mitigated, and that an accurate root cause analysis can be conducted. The following examples
illustrate security incidents in Department systems that were not handled in accordance with
OCIO-14 and applicable procedures. In particular, there were instances in the last two years
when untimely notification, improper response, and lack of access to systems and data have
resulted in the loss of potential evidence.
Malware Infection of EDUCATE Systems

In July 2010, a suspicious event report (SER) generated by Perot Systems indicated an
EDUCATE computer, located in Washington, D.C., was communicating to suspected hostile
websites, and the communication resembled known malicious traffic. Instead of capturing and
preserving the evidence, which includes the network traffic, the live system data, 6 or a forensic
image of the system, Perot Systems pulled the system off the network, thus preventing the
collection of additional data that would have aided in discovering the root cause of the incident.
If Perot Systems had coordinated with EDCIRC, EDCIRC could have either collected the live
data itself or contacted OIG to collect the data. A subsequent OIG review of the system
determined the system was infected with malware, but OIG was unable to continue its
investigation. OIG did not have enough data to determine the source or purpose of the infection,
because Perot had unintentionally manipulated the data as a result of its failure to properly
implement evidence collection procedures.
Similarly, a month later, a scheduled antivirus scan discovered malware on a different
EDUCATE computer located in Washington, D.C. Again, instead of preserving the evidence,
Perot Systems removed the system from the network and powered off the computer. As a result
of Perot Systems’ improper remediation, OIG was unable to obtain any live system data or an
image of the system for analysis. Subsequent analysis determined the malware caused the
computer to conduct unauthorized network scanning of the EDUCATE network. This malware
technique is used to gather intelligence about the network and then to use that knowledge to
successfully carry out additional attacks. Because Perot Systems did not respond properly to this
incident, data was lost, and OIG was unable to determine the source and purpose of the scanning
and how the system was initially infected.
EDUCATE Connections to a Known Malicious Website

One of the more serious recent incidents of improper response occurred on an internal system in
the EDUCATE infrastructure located in the Plano Technology Center, (b) (7)(E)
        . On July 6, 2010, EDCIRC and OIG received a SER from CSMC stating a computer



required, but it did require the incident to be documented and that the lessons learned from the incident be discussed
and reviewed.
6
  Live system data is collected while the system is running and includes volatile and nonvolatile data. Volatile data
includes system random access memory and running processes. Nonvolatile data includes system data such as
registry settings and local log files.
                                                                                                                      7
IPAR: Incident Response and Reporting Procedures - L21L0001


was making numerous attempts to connect to a known malicious overseas Internet Protocol
address through the Network Basic Input/Output System (NetBIOS) protocol stack. 7
Upon notification of the incident, OIG requested, through EDCIRC, to have the live data on the
system preserved. Perot Systems looked at the previous month’s firewall logs and discovered
the suspicious activity was on-going throughout the previous month. Instead of preserving the
evidence, Perot Systems conducted a full system anti-virus scan. 8 Perot Systems contacted the
vendor of the system’s main application and learned the NetBIOS protocol stack was not
required for the application to operate. Perot Systems then deactivated the NetBIOS protocol
stack, and as a result, the observed traffic stopped.
On July 8, 2010, after OIG was notified of Perot Systems’ actions, it requested a forensic image
of the system and, if that was not immediately possible, OIG reiterated its request for the
system’s live data. OIG suggested the use of its Live Response Program to collect this data since
there were Perot Systems technicians who were trained in its use. 9 Five days after this request,
EDCIRC informed OIG that Perot Systems refused to run the program. Ultimately, OIG
contacted the Department’s CIO for assistance, and the CIO ordered Perot Systems to allow OIG
to run the tool and collect the data. The live data was collected from the system by an OIG
employee on July 14, 2010.
As required by its contract, Perot Systems provided a root cause analysis to OCIO-IA on August
5, 2010, but it was rejected by OCIO-IA, because it did not identify the root cause and contained
inaccurate statements. To date, OCIO-IA has not received another root cause analysis on this
incident.
On August 9, 2010, OIG made another request for a forensic image of the system and requested
the backups of the system as it existed before the incident, but it learned Perot Systems had not
made backups of this system. On September 2, 2010, Perot Systems shipped a logical copy of
the system to OIG (Perot Systems told OIG that it could not shut the system down; therefore,
only a logical copy, as opposed to a forensic image, could be provided). Given that a logical
copy provides only a limited amount of data, OIG was unable to examine crucial areas of the
system. 10


7
  NetBIOS allows applications on different computers to communicate within a local area network.
8
  The scan detected no malware. However, many malware in circulation today will drop additional malware or
utilities onto a system. Depending on the release date of the malware it may not be immediately identifiable by the
anti-virus software. The majority of anti-virus vendors have a lag time from the time of an infection to the release of
a patch to remove the malware.
9 (b) (7)(E)
                                                                                                             OIG
developed a program to assist the responding technicians in the collection of the necessary data, OIG’s Live
Response Program. This program is a series of scripts and programs built for the purpose of acquiring system
evidence in a consistent and simple manner. Initially, Perot Systems agreed to use the program, but it later declined
when OIG attempted to schedule training for Help Desk personnel, indicating it would take too much time to run.
The program takes approximately 15 minutes to run.
10
   A logical copy of a system provides only a partial view of the entire system. It does not capture critical files that
are in use by the operating system, nor does it collect deleted files, file slack, and free space. Critical evidence is
often located and available for examination only within a forensic image of a hard drive.

                                                                                                                       8
IPAR: Incident Response and Reporting Procedures - L21L0001


After it reviewed the logical copy, OIG asked to speak with the Perot Systems technicians who
worked on this incident. Perot Systems, through EDCIRC, informed OIG that it would not be
allowed to talk directly to the Perot Systems’ technicians, and it would need to submit questions
to Perot Systems’ managers who would get the answers and provide them to OIG. Ultimately,
OIG was able to interview the technicians after several days of coordinating with a Perot
Systems’ attorney.
On October 8, 2010, OIG asked EDCIRC to capture the current network traffic of the system.
(b) (7)(E)




                                                                       erot Systems stated it
would start the network capture anyway and allow it to run for a 24-hour period. Two days later,
OIG was informed no data was captured because the official request was never entered into the
incident tracking system. (b) (7)(E)




At every critical juncture, Perot Systems or OCIO failed to properly respond to the NetBIOS
incident. Although Perot Systems’ initial actions may have contained the incident, Perot
Systems destroyed potential evidence by running a full system anti-virus scan and then shutting
off the NetBIOS protocol stack. (b) (7)(E)
                              Perot Systems or OCIO forced OIG to step in to undertake these
activities. By its delays in then allowing OIG to retrieve the live data, as well as by its failure to
provide a forensic image and its impeding of – albeit temporarily – OIG’s access to Perot System
technicians, Perot Systems also hampered evidence collection.
(b) (7)(E)




D. Conclusion

The Department and its contractor Perot Systems have not properly responded to computer
security incidents in accordance with OCIO-14 and Perot Systems’ contract. Perot Systems’
preferred method for dealing with many of the reported incidents seems to be to remove the
infected system from the network and attempt to clean the system by running a virus scan, before
there is any attempt to collect the potential evidence. Not only does this practice violate the
containment procedures set forth in OCIO-14, but it also hampers the investigative processes that
is part of the detection/identification phase, and can destroy the potential of determining the root
                                                                                                     9
IPAR: Incident Response and Reporting Procedures - L21L0001


cause that is part of the eradication phase of OCIO-14. In addition, Perot Systems was unable to
(b) (7)(E)                 was slow to provide requested data and access to Perot Systems’
employees, and has not completed root cause analyses that identified the root cause of these
incidents.
Because Perot Systems has ignored the initial stages of the incident response life cycle and
proceeded directly to the recovery phase, the Department has been unable to discover what it did
not know about the incident, including the source of the problem and the various systems that
might be impacted. The Department is unable then to determine if there are any lessons to be
learned from the incident as is required in the follow-up phase of OCIO-14. This could leave the
Department’s data and systems vulnerable.


E. Recommendations

To ensure the Department’s systems and networks are protected, OIG recommends the Chief
Information Officer to:
    Enforce the contract’s requirement for Perot Systems to comply with OCIO-14 when
    performing incident response, or develop a separate capability to perform incident response
    in accordance with OCIO-14. The incident response capability, whether or not maintained
    by Perot Systems, should include:
             Providing incident response personnel with the appropriate training and tools to
             collect and preserve evidence in a quick and forensically sound manner (in person or
             remotely);
             Analyzing information to determine the root cause of an incident and to determine the
             extent of damage;
             Implementing appropriate hardware, software, and procedures to activate full content
             network monitoring in a timely manner to support the incident response process and
             to assist in discovery of the incident’s root cause.




                                                                                                  10
IPAR: Incident Response and Reporting Procedures - L21L0001




                             Attachment 1 - Previous Findings


Over the last two years, OIG identified, reported, and made recommendations to the Department
on the following weaknesses within incident response and reporting, based on OCIO-14
requirements:
Memorandum, OIG Information Technology Security Concerns, dated March 11, 2009.

                •   Department systems made frequent outbound connections to foreign sites
                    known to contain malware.
                •   CSMC alerts increased as a result of improved coverage and tuning. CSMC
                    started to generate repeat findings because the Department failed to identify
                    the computer responsible for the suspicious activity in prior alerts.
                •   Since January 2009, there were approximately 60 virus or malware detections
                    on Department computers per week.
                •   There was an increase in keylogger data incidents as reported by US-CERT.
Email to the OCIO-Information Assurance: Urgent IT Security Issue, dated June 8, 2010.
            Based on a review of network traffic, OIG identified potentially compromised
            systems, as well as numerous Department computers, which were communicating
            with hostile Internet sites that had not yet been identified by the Department as
            suspicious.
Investigative Program Advisory Report, Bypassing of Web Content Filtering, Control Number
L21K0001, dated July 20, 2010.
            Users throughout the Department were circumventing web filtering by adding an “s”
            to the “http” before a uniform record locator in their browsers. The https traffic went
            undetected under the current configurations of the web filtering program.

           (b) (7)(E)

Final Alert Memorandum, Implementation of the Managed Security Services Provider Contract,
Control Number ED-OIG/L19K0011, dated September 24, 2010.
            The Department had not effectively implemented its managed security services
            provider (MSSP) contract with CSMC. The memorandum discussed (b) (7)(E)




                                                                                                 11
IPAR: Incident Response and Reporting Procedures - L21L0001



               Attachment 2 - OCIO-14 Incident Response Life Cycle


Summarized below are six stages of the incident response life cycle, as found in OCIO-14, which
adopted from NIST Special Publication 800-61, Revision 1:
            Preparation: The initial phase consists of the development of policy and procedures
            and the identification and implementation of other components required for the
            response.

            Detection/Identification: This phase involves the collection and review of the
            evidence of an intrusion.

            Containment: This phase includes the stopping of an incident before it spreads or
            causes more damage, while also documenting the actions performed, performing two
            disk images of the system and the gathering, and reviewing the network, system and
            application logs.

            Eradication: The identification and mitigation of the cause of the incident is the
            purpose of this phase.

            Recovery: The restoration of affected systems to an unaffected state and their
            validation in terms of functionality and security are the components of this phase.

            Follow-up: The final part of the incident response process involves the review of
            data, in an effort to determine if there are any lessons to be learned from an incident.




                                                                                                   12
                        UNITED STATES DEPARTMENT OF EDUCATION

                                 DFFlCE OF TIiE ClllEF INr-oRMAT'Ol'l OFFICER




                                                     June 24, 2011

MEMORANDUM


TO:          Charles E. Coe, Jr.
             Assistant Inspector General        /111\
FROM:         Danny A. Harris, PhD .          H"V--�---­
              Chief lnfonnation Officer
              Office of the Chief lnfonnation Officer



SUBJECT: Investigative Program Advisory Report (lPAR)
               ControINo.L2ILOOOI


Thank you for the opportunity to respond to the Office of Inspector General's (OIG)
[nvestigalive Program Advisory Report (lPAR), coIncident Response and Reporting Procedures"
(Case # 10-110283) Control No. L21LOOOI. OIG conducted                            an   investigation over the past two
years starting in 2009 that revealed instances in which the Department did not detect, report, or
respond to incidents in accordance with the Department's Handbook/or Information Security
Incident Response and Reporting Procedures, OCIO-14. The report provides recommendations
that the Chief lnfonnation Officer (CIO) take one action to improve incident response
throughout the agency. Below is the Department's proposed response to your recommendation
based upon the draft report:



Recommendation 1. Enforce the contract's requirement for Perot Systems to comply with
OCIO-14 when performing incident response, or develop a separate capability to perform
incident response in accordance with OCI0-14. The incident response capability, whether or not
maintained by Perot Systems, should include:


      •   Providing incident response personnel with the appropriate training and tools to collect
          and preserve evidence in a quick and forensically sound manner (in person or remotely);


      •   Analyzing information to detennine the root cause of                    an   incident and to determine the
          extent of damage;

      •   Implementing appropriate hardware, software, and procedures to activate full content
          network monitoring in a timely manne:r to support the incident response process and to
          assist in discovery of the incident's root cause.


                               400 MARYlAND AVE.. S.W        •.   Wf\SmN(;TO�. IX: Zll.Wl4580
                                                           WW\\,ed.g()\

      Our mission IS 10 en)ure equal.acc�   10 education   and to promOle edur,ulon.:al �t'Henrt uHClughout lhe DatKJn
While we agree with this recommendation, we would like to state that the Office of the Chief
lnforrnation Officer (OCIO) has been exercising due diligence in steadily improving the
Department's Incident Response program. More specifically OCIO lAS has initiated andlor
completed the following activities to ensure the Department and its contractor, Dell Systems
(fonnerly known as "Perot Systems"), properly responds to computer security incidents in
accordance with the Department's Handbook/or In/ormation Security Incident Response and
Reponing Procedures, aCIO-14:


   •    aCIa lAS has recently hired a GS-IS Cyber Security Director to oversee the operational
        protection and defense of the Department's information and information systems. The
        U.S. Department of Education's Computer Incident Response Capability (EDClRC) was
        given two additional staffing allocations from within lAS to include a certified computer
        forensic analyst.
   •    All EDClRC personnel have anended specialized training        in   Incident Handling and
        Response andlor forensic analysis within 2011.
   •    aCla lAS has strengthened the EDCIRC relationship with Cyber Security Management
        Center (CSMC), the Department's Federal Managed System Security Provider and built
        enhanced analysis capabilities to include analysis of advanced persistent threat activity.
        Furthermore, OCIO is working with CSMC to expand visibility of all Department
        networks (to include FSA and American Data Technology Incorporated-ADTI) by
        installing Network Intrusion Detection Systems (NIDS) on the inside of the firewalls
        within the networks. Additionally, both the EDClRC and CSMC            are   leveraging and
        utilizing Einstein capabilities to conduct inbound and outbound traffic analysis.
   •    aCIa is leveraging the IA Enhancement funding, authorized by the Secretary, to develop
        an automated Enterprise-wide Continuous Monitoring program that enables the EDCIRC
        to have near-real time situation awareness of system configurations, vulnerabilities,
        automated change detection, and automated patch management. Additionally, the
        EDCIRC has purchased forensic analysis tools which will assist with discovering any
        root cause analysis for intrusions when they occur.
    •   OelO is leveraging the IA Discovery Project, supported and endorsed by the Secretary,
        to identify all assets on the Education Department Utility for Communications,
        Applications and Technology Environment (EDUCATE) and the FSA Virtual Data
        Center (VDC) networks, identify and remediate associated vulnerabilities, and to
        establish recommendations and a roadmap to incorporate solutions to address identified
        systemic issues. This effort kicked-off in January 2011 and is nearing completion.
        Through this endeavor several critical vulnerabilities have already been identified and
        remediated.
    •   OCIO has also established new Security Service Level Agreements with Dell Systems in
        March 2011 to address identified weaknesses    in   the government's ability to track security
        issues. The Chief Information Security Officer (CISO) is continuing to review and
        analyze security requirements within the Dell Systems contract and how those
        requirements are being enforced.
    •   OCIO lAS has initiated an enterprise approach to information security working closely
        with Federal Student Aid (FSA), Institute of Education Sciences (lES), and other data
       centers to consolidate and standardize capabilities, standardize processes, improve
       response times, and achieve cost efficiencies through economies of sca1e.
   •   ocrO-14, Handbook for Information Security Incident Handling and Reporting
       Procedures has been updated, staffed, and published in March 20 II.


In summary, the OCIO acknowledges that the capabilities, processes, and procedures that have
been or are being put into place are still nascent but feel that the Cyber Security Incident
Response capability within the Department is being built on a strong foundation and has a solid
trajectory for enhanced capability. The ocro and the EDCIRC will continue to work with FSA,
Dell Systems, and the DIG to synchronize and enhance our business processes to ensure the
protection and defense of the Department of Education's infonnation and information systems.


Thank you again for the opportunity to comment on this report. If you have any questions,
please contact me at (202) 245-6252 or Danny.Harris@ed.gov.