Federal Information Security Management Act of 2002: Difference between revisions
imported>Howard C. Berkowitz |
mNo edit summary |
||
(13 intermediate revisions by 3 users not shown) | |||
Line 25: | Line 25: | ||
#Support Tools Initiative: This initiative will include identifying or developing common protocols, programs, reference materials, checklists, and technical guides supporting implementation and assessment of SP 800-53-based security controls in information systems. | #Support Tools Initiative: This initiative will include identifying or developing common protocols, programs, reference materials, checklists, and technical guides supporting implementation and assessment of SP 800-53-based security controls in information systems. | ||
#Harmonization Initiative: Important for minimizing duplication of effort for organizations that must demonstrate compliance to both FISMA and ISO requirements, this initiative will include identifying common relationships and the mappings of FISMA standards, guidelines and requirements with: | #Harmonization Initiative: Important for minimizing duplication of effort for organizations that must demonstrate compliance to both FISMA and ISO requirements, this initiative will include identifying common relationships and the mappings of FISMA standards, guidelines and requirements with: | ||
##ISO 27000 series information security management standards | |||
##ISO 9000 and 17000 series quality management, and laboratory testing and accreditation standards. | |||
==Framework== | ==Framework== | ||
FISMA establishes minimum security controls for systems that meet a particular high water mark of '''security category (SC)'''. To comply with FISMA: | |||
#[[#Risk assessment|Assess the risks]] so the SC can be set | |||
#[[#High water mark|Compute the high-water mark SC]] | |||
#Determine the ''security controls'' required for that SC | |||
#Exclude, or seek a waiver, for technologies that cannot meet a required control | |||
#Develop new designs, or upgrade plans, to implement the required controls | |||
#Implement approved technical controls and tools | |||
#Operational and management functions are part of the controls; continue to monitor running systems for conformance to these. | |||
===Risk assessment=== | |||
Technical definitions and framework are in [[Federal Information Processing Standard]] (FIPS) [[FIPS PUB 199]], "Standards for the Security Categorization of Federal Information and Information Systems".<ref name=FIPS199>{{citation | Technical definitions and framework are in [[Federal Information Processing Standard]] (FIPS) [[FIPS PUB 199]], "Standards for the Security Categorization of Federal Information and Information Systems".<ref name=FIPS199>{{citation | ||
| id = FIPS PUB 199 | | id = FIPS PUB 199 | ||
| title = Standards for the Security Categorization of Federal Information and Information Systems | | title = Standards for the Security Categorization of Federal Information and Information Systems | ||
| publisher = Computer Security Division, Information Technology Laboratory, [[National Institute for Standards and Technology]] | | publisher = Computer Security Division, Information Technology Laboratory, [[National Institute for Standards and Technology]] | ||
| date = February 2004}}</ref> While the detailed guidance is in additional | | date = February 2004}}</ref> While the detailed guidance is in additional documents , FIPS 199 provides FISMA with three dimensions of security categorization: | ||
*'''[[Confidentiality]]''' | *'''[[Confidentiality]]''' | ||
*'''[[Integrity]]''' | *'''[[Integrity]]''' | ||
*'''[[Availability]]''' | *'''[[Availability]]''' | ||
and matrixes these against ''potential impact'' characterized as low, medium and high: | and matrixes these against ''potential impact'' characterized as none, low, medium and high: | ||
*'''None''' ("N/A") if there is no impact in the category, such as there being no confidentiality requirement on local weather observations | |||
*'''LOW''' if "The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals." | |||
*'''MODERATE''' if The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. | |||
*'''HIGH''' if The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals | |||
===High water mark=== | |||
Resulting from these, the generalized format for expressing the '''security category (SC)''' of an information system is: | |||
<center>SC<sub>information system</sub> = {(confidentiality, impact), (integrity, impact), (availability, impact)}</center> | |||
where the acceptable values for potential impact are low, moderate, or high. | |||
===Security controls=== | |||
{{main|Federal Information Security Management Act of 2002/Catalogs}} | |||
== | |||
For designing FISMA implementations, the primary reference is NIST Special Publication 800-53, Revision 3, "Recommended Security Controls for Federal Information Systems and Organizations". This document identifies a number of security controls that may or may not be applicable to a particular information system. <ref name=SP800-53-Rev3>{{citation | For designing FISMA implementations, the primary reference is NIST Special Publication 800-53, Revision 3, "Recommended Security Controls for Federal Information Systems and Organizations". This document identifies a number of security controls that may or may not be applicable to a particular information system. <ref name=SP800-53-Rev3>{{citation | ||
| title = Recommended Security Controls for Federal Information Systems and Organizations | | title = Recommended Security Controls for Federal Information Systems and Organizations | ||
Line 157: | Line 152: | ||
Common controls are security controls that are inheritable by one or more organizational information systems, and are selected at overseen by the highest level of the organization's information managemen, which takes into account the security categories and associated impact levels, under the guidelines of [[FIPS 199]] and [[FIPS 200]], as well as the security controls necessary to adequately mitigate the risks arising from the use of those systems.<ref>Special Publication 800-53, pp. 2-10 to 2-12</ref> | Common controls are security controls that are inheritable by one or more organizational information systems, and are selected at overseen by the highest level of the organization's information managemen, which takes into account the security categories and associated impact levels, under the guidelines of [[FIPS 199]] and [[FIPS 200]], as well as the security controls necessary to adequately mitigate the risks arising from the use of those systems.<ref>Special Publication 800-53, pp. 2-10 to 2-12</ref> | ||
===Tools=== | |||
There is a great impetus to the economies and operational of [[cloud computing]], but not all cloud services may be able to meet the requirements of some security controls. Some HIGH systems may need completely private physical, virtual private networks, or private application clouds. | |||
Given the Federal government deals with a very large number of existing computers and networks that will connect to new clouds, there will be practical constraints if the means of deployment will change. Many [[cloud computing]] delivery models assume, for example, that many of the security mechanisms will use [[cryptography]] in the [[Secure Sockets Layer]] or some other form of [[Transport Layer Security]]. If the desktops or servers cannot support this, perhaps for performance reasons with the existing desktops, or perhaps because the applications, or application infrastructure such as [[data base management system]]s, do not support it, being FISMA compliant in the cloud becomes much more complex. | |||
A group organized by the [[Center for Strategic and International Studies]] created a list of 20 important controls for FISMA. They recognize that compliance is an incremental process, so grouped the controls into four categories:<ref name=CSIS>{{citation | |||
| url = http://csis.org/files/media/csis/pubs/090223_cag_1_0_draft4.1.pdf | |||
| title = Twenty Most Important Controls and Metrics for Effective Cyber Defense and Continuous FISMA Compliance | |||
| edition = Draft 1.0 | date = 23 February 2009 | |||
| publisher = [[Center for Strategic and International Studies]]}}</ref> | |||
*Quick Wins: Fastest to implement, although not necessarily the most critical | |||
*Improved Visibility and Attribution: Improve the organization's ability to associate events with computer systems, and preferably users | |||
*Hardened Configuration and Improved Information Security Hygiene: Harden the FISMA target | |||
*Advanced: "Organizations handling particularly sensitive networks and information that are already following all of the other controls should focus on this category." | |||
===Reporting and reporting tools=== | |||
In apparent agreement with the concern about paper reporting, OMB will require an automated reporting tool. <ref name=>{{citation | |||
| date = August 20, 2009 | |||
| id = M-09-29 | |||
| author = Jeffrey D. Zients, Deputy Director for Management and Vivek Kundra. U.S. Chief Information Officer | |||
| title = FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management | |||
| publisher = [[Office of Management and Budget]] | |||
| url = http://www.whitehouse.gov/omb/assets/memoranda_fy2009/m09-29.pdf}}</ref> The memorandum dictating the tool also gives guidance on reporting. | |||
====Paper dependence==== | |||
FISMA has been [[#Criticism|criticized]], by legislators and legislative agencies, for being too dependent on manual paper procedures and not enough on specific enforcement technologies and procedures.<ref name=FCW2009-07-01>{{citation | |||
| title = GAO urges improvements to FISMA: An auditor recommends steps to improve information security at agencies | |||
| author = Ben Bain | |||
| date = 1 July 2009 | journal = Federal Computer Week | |||
| url = http://fcw.com/articles/2009/07/01/gao-gives-advice-on-fisma-improvements.aspx}}</ref> | |||
====Granularity==== | |||
OMB FAQ #6 addresses granularity of reporting: "Agencies must provide an overall agency view of their security and privacy program but most of the topic areas also require specific responses for each of the major components (e.g., bureaus or operating divisions). Thus, the agencies’ and OMB’s report can distinguish good performing components from poor performers and more accurately reflect the overall agency performance. | |||
==Criticism== | ==Criticism== | ||
In April 2009, Senator [[Thomas Carper]] ([[Democratic Party (United States)|D-]][[Delaware (U.S. state)|Delaware]]) introduced two pieces of legislation to force more actual compliance and less paper reporting of hypothetical compliance.<ref name=FCW2009-08-28>{{citation | |||
In April 2009, Senator [[Thomas Carper]] ([[ | |||
| url = http://www.fcw.com/Articles/2009/04/28/Senate-FISMA-reform.aspx | | url = http://www.fcw.com/Articles/2009/04/28/Senate-FISMA-reform.aspx | ||
| title = Carper introduces bills to reform IT procurement, FISMA | | title = Carper introduces bills to reform IT procurement, FISMA | ||
Line 167: | Line 191: | ||
| date = 28 April 2009 | | date = 28 April 2009 | ||
| journal = Federal Computer Week}}</ref> | | journal = Federal Computer Week}}</ref> | ||
On May 19, 2009, the House took testimony at the required 60-day reporting interval after start of FISMA implementation.<ref name=SCGMOP-2009-05-09>{{citation | On May 19, 2009, the House took testimony at the required 60-day reporting interval after start of FISMA implementation.<ref name=SCGMOP-2009-05-09>{{citation | ||
| date = 19 May 2009 | | date = 19 May 2009 | ||
Line 184: | Line 208: | ||
| author =Margaret H. Graves. Acting Chief Information Officer, [[United States Department of Homeland Security]] | | author =Margaret H. Graves. Acting Chief Information Officer, [[United States Department of Homeland Security]] | ||
| title = The State of Federal Information Security | | title = The State of Federal Information Security | ||
| publisher = [[Subcommittee on Government Management, Organization and Procurement]], [[U.S. House | | publisher = [[Subcommittee on Government Management, Organization and Procurement]], [[U.S. House Committee on Oversight and Government Reform]] | ||
| date = May 19, 2009 | | date = May 19, 2009 | ||
| url = http://governmentmanagement.oversight.house.gov/documents/20090519083111.pdf}}</ref> DHS is both a user and a provider of FISMA-regulated cloud computing. | | url = http://governmentmanagement.oversight.house.gov/documents/20090519083111.pdf}}</ref> DHS is both a user and a provider of FISMA-regulated cloud computing. | ||
Line 225: | Line 249: | ||
| url = http://governmentmanagement.oversight.house.gov/documents/20090519082953.pdf | | url = http://governmentmanagement.oversight.house.gov/documents/20090519082953.pdf | ||
}}</ref> | }}</ref> | ||
==References== | ==References== | ||
{{reflist|2}} | {{reflist|2}}[[Category:Suggestion Bot Tag]] |
Latest revision as of 16:00, 15 August 2024
Enacted in 2002, the Federal Information Security Management Act (FISMA), was passed to support the E-Government Act of 2002. Without information security, it is impossible for government to deliver reliable services through electronic means. The advent of Internet delivery and cloud computing immensely complicates the security problem.
Nevertheless, there may well be solutions for these new environments, if proper perspective is kept. In any security context, there is acceptance of responsibility, as well as acceptance of risk. An approach to security purely in the network has long been endpoint security, leaving the network encrypted. When the servers are outsourced, it may be that endpoint encryption will remain under control of the owning agency, but audit is the main tool for checking on the server operator. Microsoft, for example, is proposing the "locking down" of desktops as one side of the security architecture; [1] the other extreme was an uncontrolled desktop coming through active defenses, in the U.S. Department of Transportation response to Conficker
There must always be an owner for every function, but the granularity of ownership can legitimately vary for different security functions, and for different missions within a common computing utility.
Guidance for implementing FISMA comes from the Computer Security Resource Center, Computer Systems Division, National Institute of Standards and Technology. [2] There are two phases in the startup, the first of which is complete:
- Phase I: Standards and Guidelines Development (2003-2008)
- Phase II: Organizational Credentialing Program (2007-2010)
In the second phase are the activities:
- Training Initiative: This initiative will include development of training courses, NIST publication Quick Start Guides (QSG’s), and Frequently Asked Questions (FAQ’s) to establish a common understanding of the NIST standards and guidelines supporting the NIST Risk Management Framework.
- Product and Services Assurance Assessment Initiative: This initiative will include defining criteria and guidelines for evaluating products and services used in the implementation of SP 800-53-based security controls.
- Support Tools Initiative: This initiative will include identifying or developing common protocols, programs, reference materials, checklists, and technical guides supporting implementation and assessment of SP 800-53-based security controls in information systems.
- Harmonization Initiative: Important for minimizing duplication of effort for organizations that must demonstrate compliance to both FISMA and ISO requirements, this initiative will include identifying common relationships and the mappings of FISMA standards, guidelines and requirements with:
- ISO 27000 series information security management standards
- ISO 9000 and 17000 series quality management, and laboratory testing and accreditation standards.
Framework
FISMA establishes minimum security controls for systems that meet a particular high water mark of security category (SC). To comply with FISMA:
- Assess the risks so the SC can be set
- Compute the high-water mark SC
- Determine the security controls required for that SC
- Exclude, or seek a waiver, for technologies that cannot meet a required control
- Develop new designs, or upgrade plans, to implement the required controls
- Implement approved technical controls and tools
- Operational and management functions are part of the controls; continue to monitor running systems for conformance to these.
Risk assessment
Technical definitions and framework are in Federal Information Processing Standard (FIPS) FIPS PUB 199, "Standards for the Security Categorization of Federal Information and Information Systems".[3] While the detailed guidance is in additional documents , FIPS 199 provides FISMA with three dimensions of security categorization:
and matrixes these against potential impact characterized as none, low, medium and high:
- None ("N/A") if there is no impact in the category, such as there being no confidentiality requirement on local weather observations
- LOW if "The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals."
- MODERATE if The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.
- HIGH if The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals
High water mark
Resulting from these, the generalized format for expressing the security category (SC) of an information system is:
where the acceptable values for potential impact are low, moderate, or high.
Security controls
For designing FISMA implementations, the primary reference is NIST Special Publication 800-53, Revision 3, "Recommended Security Controls for Federal Information Systems and Organizations". This document identifies a number of security controls that may or may not be applicable to a particular information system. [4]
Those of the Management class involve initial and continuing policy decisions. The Operational class addresses procedures and validation for daily operations, while the Technical class deals with tool selection and implementation.
IDENTIFIER | FAMILY | CLASS |
---|---|---|
AC | Access control | Technical |
AT | Awareness and Training | Operational |
AU | Audit and accountability | Technical |
CA | Security assessment and authorization | Management |
CM | Configuration management | Operational |
CP | Contingency Planning | Operational |
IA | Identification and authentication | Technical |
IR | Incident response | Operational |
MA | Maintenance | Operational |
MP | Information systems media protection | Operational |
PE | Information facility physical and environmental protection | Operational |
PL | Planning | Management |
PS | Personnel security | Operational |
RA | Risk assessment | Management |
SA | System and Services Acquisition | Management |
SC | System and communications protection | Technical |
SI | System and information integrity | Operational |
PM | Program Management | Management |
Controls may be common, system-specific or hybrid.
Common controls are security controls that are inheritable by one or more organizational information systems, and are selected at overseen by the highest level of the organization's information managemen, which takes into account the security categories and associated impact levels, under the guidelines of FIPS 199 and FIPS 200, as well as the security controls necessary to adequately mitigate the risks arising from the use of those systems.[5]
Tools
There is a great impetus to the economies and operational of cloud computing, but not all cloud services may be able to meet the requirements of some security controls. Some HIGH systems may need completely private physical, virtual private networks, or private application clouds.
Given the Federal government deals with a very large number of existing computers and networks that will connect to new clouds, there will be practical constraints if the means of deployment will change. Many cloud computing delivery models assume, for example, that many of the security mechanisms will use cryptography in the Secure Sockets Layer or some other form of Transport Layer Security. If the desktops or servers cannot support this, perhaps for performance reasons with the existing desktops, or perhaps because the applications, or application infrastructure such as data base management systems, do not support it, being FISMA compliant in the cloud becomes much more complex.
A group organized by the Center for Strategic and International Studies created a list of 20 important controls for FISMA. They recognize that compliance is an incremental process, so grouped the controls into four categories:[6]
- Quick Wins: Fastest to implement, although not necessarily the most critical
- Improved Visibility and Attribution: Improve the organization's ability to associate events with computer systems, and preferably users
- Hardened Configuration and Improved Information Security Hygiene: Harden the FISMA target
- Advanced: "Organizations handling particularly sensitive networks and information that are already following all of the other controls should focus on this category."
Reporting and reporting tools
In apparent agreement with the concern about paper reporting, OMB will require an automated reporting tool. [7] The memorandum dictating the tool also gives guidance on reporting.
Paper dependence
FISMA has been criticized, by legislators and legislative agencies, for being too dependent on manual paper procedures and not enough on specific enforcement technologies and procedures.[8]
Granularity
OMB FAQ #6 addresses granularity of reporting: "Agencies must provide an overall agency view of their security and privacy program but most of the topic areas also require specific responses for each of the major components (e.g., bureaus or operating divisions). Thus, the agencies’ and OMB’s report can distinguish good performing components from poor performers and more accurately reflect the overall agency performance.
Criticism
In April 2009, Senator Thomas Carper (D-Delaware) introduced two pieces of legislation to force more actual compliance and less paper reporting of hypothetical compliance.[9]
On May 19, 2009, the House took testimony at the required 60-day reporting interval after start of FISMA implementation.[10] Vivek Kundra, the Federal Chief Information Officer, summarized the overall status: "recent successful breaches at the Federal Aviation Administration and at the vendor that hosts USAjobs.gov demonstrate that the current state of information security at Federal agencies is not what the American people have the right to expect. The Federal Information Security Management Act (FISMA) has been in place for 7 years. It has raised the level of awareness in the agencies and in the country at large, but we are not where we need to be." OMB identified the following key issues:[11]
- The performance information currently collected under FISMA does not fully reflect the security posture of Federal agencies;
- The processes used to collect the information are cumbersome, labor‐intensive, and take time away from meaningful analysis, and;
- The Federal community is focused on compliance, not outcomes
Department of Homeland Security
At the same hearing, Margaret Graves, CIO of the U.S. Department of Homeland Security, spoke more specifically about implementation in a real agency.[12] DHS is both a user and a provider of FISMA-regulated cloud computing.
It provides the services through "OneNet", which not only collapsed a set of wide area networks into one, but needed to reconcile policy differences among the legacy network owners, without either limiting information sharing or dropping to the lowest common level of security. To do this, within the transmission infrastructure are mission-unique Trust Zones through the implementation of a series of Policy Enforcement Points (PEPs).
PEPs are comprised of hardware and software packages positioned throughout the network, as well as appropriate management functions at the SOC. Specifically, each PEP will include an enterprise-managed firewall to resolve policy differences, and sophisticated monitoring capabilities that will allow the operations center to track threats.
The major threat is phishing. "Security controls for email must be strengthened, and we are adding some email specific features to the Trusted Internet Connections that will allow us to further improve our ability to detect and respond to malicious emails."
- Additionally, each data center now houses one of the two Trusted Internet Connections that have been designed with sophisticated threats in mind. Further, the Department’s new data centers deliver utility computing and Infrastructure as a Service, allowing DHS to realize the benefits of cloud computing while also providing the security so necessary for the threats we face today.
Systems integrator perspective
Also testifying was Samuel Chun, director of the cyber security practice of EDS' Public Sector, now a division of Hewlett-Packard.[13] Chun described the deficiencies his organization has encountered in implementing FISMA:
- "There is too much emphasis on the generation of paper reports for compliance, certification and accreditation, and auditing."
- The correlation between compliance and operating performance is unclear. We’ve observed that some of the most well defended agencies consistently receive poor report cards. In addition, a single grade assigned to a large and diverse agency with many components only generalizes the picture and may not, in fact, provide proper warning of a material vulnerability to mission performance to the agency’s mission owners. A more granular approach to reporting that highlights operating performance -- in addition to compliance -- will likely provide more clarity. (OMB guidance on granularity)
- Accountability for good and poor compliance is unclear...it is not transparent how that "report cards" are used for the purposes of budgeting, rewards, and assigning accountability. "For system integrators, however, there is a clear process for receiving and maintaining the authority to operate through the certification and accreditation process that impact us directly. There should be equally transparent accountability for poor performance. We reiterate our support for the appointment of a new cyber official who can address these concerns."
- "Compliance to FISMA measures how well an agency has accounted for, and applied risk and security management standards, processes, and plans for, information systems. The inference is that as long as the standards, processes and plans are sound, the operational security of an agency is thereby effective." He believes that direct mesures may be superior to the indirect measures. Direct measures, would be more rigorous, such as:
- number of attacks defended against
- the mean time to patch a vulnerability
- number of incidents to which an agency has responded
- percent of applications tested would provide more
- Rapidly emerging threats may be outpacing compliance efforts; EDS recommends US-CERT and the NSA rather than NIST
Department of Transportation
There is also experience from the U.S. Department of Transportation. They do not, for example, "scan personal computers used for telework at a detailed level, [they] ensure that minimum security requirements are met...Conficker was managed by connecting "through the DOT secure remote access (SRA) and virtual private network (VPN) systems had active local firewalls installed, and an active antivirus solution."[14]
References
- ↑ Brien M. Posey (June 2009), Running A Controlled Windows Endpoint Environment, Microsoft Corporation
- ↑ Detailed Overview, Computer Security Resource Center, Computer Systems Division, National Institute of Standards and Technology
- ↑ Standards for the Security Categorization of Federal Information and Information Systems, Computer Security Division, Information Technology Laboratory, National Institute for Standards and Technology, February 2004, FIPS PUB 199
- ↑ Recommended Security Controls for Federal Information Systems and Organizations (Revision 3 ed.), National Institute of Standards and Technology, August 2009, NIST Special Publication 800-53, p. II-6
- ↑ Special Publication 800-53, pp. 2-10 to 2-12
- ↑ Twenty Most Important Controls and Metrics for Effective Cyber Defense and Continuous FISMA Compliance (Draft 1.0 ed.), Center for Strategic and International Studies, 23 February 2009
- ↑ Jeffrey D. Zients, Deputy Director for Management and Vivek Kundra. U.S. Chief Information Officer (August 20, 2009), FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency Privacy Management, Office of Management and Budget, M-09-29
- ↑ Ben Bain (1 July 2009), "GAO urges improvements to FISMA: An auditor recommends steps to improve information security at agencies", Federal Computer Week
- ↑ Ben Bain (28 April 2009), "Carper introduces bills to reform IT procurement, FISMA", Federal Computer Week
- ↑ Hearing Testimony and Witness list for the Subcommittee Hearing on: "The State of Federal Information Security.", Subcommittee on Government Management, Organization and Procurement, U.S. House Committee on Oversight and Government Reform, 19 May 2009
- ↑ Vivek Kundra, Federal Chief Information Officer, Office of Management and Budget (May 19, 2009), The State of Federal Information Security, Subcommittee on Government Management, Organization and Procurement, U.S. House Committee on Oversight and Government Reform
- ↑ Margaret H. Graves. Acting Chief Information Officer, United States Department of Homeland Security (May 19, 2009), The State of Federal Information Security, Subcommittee on Government Management, Organization and Procurement, U.S. House Committee on Oversight and Government Reform
- ↑ Samuel Chun, EDS Public Sector division of Hewlett-Packard (May 19, 2009), The State of Federal Information Security, Subcommittee on Government Management, Organization and Procurement, U.S. House Committee on Oversight and Government Reform
- ↑ Jacquelyn Pattillo, Acting Chief Information Officer, U.S. Department of Transportation (May 19, 2009), The State of Federal Information Security, Subcommittee on Government Management, Organization and Procurement, U.S. House Committee on Oversight and Government Reform