type: other

jurisdiction: US

text: b' U.S. Department of Agriculture\n Office of Inspector General\n\n\n\n\n Audit Report\n\n U.S. Department of Agriculture,\nOffice of the Chief Information Officer,\nFiscal Year 2009 Federal Information\n Security Management Act\n\n\n\n\n Audit Report 50501-15-FM\n November 2009\n\x0c U.S. Department of Agriculture\n Office of Inspector General\n Washington, D.C. 20250\n\n\nDATE: November 17, 2009\n\nThe Honorable Peter Orszag\nDirector\nOffice of Management and Budget\nEisenhower Executive Office Building\n1650 Pennsylvania Avenue N.W.\nWashington, D.C. 20503\n\nSUBJECT: U.S. Department of Agriculture, Office of the Chief Information Officer,\n Fiscal Year 2009 Federal Information Security Management Act Report\n (Audit Report 50501-15-FM)\n\nThis report presents the results of our audits of the U.S. Department of Agriculture\xe2\x80\x99s (USDA)\nefforts to improve the management and security of its information technology (IT) resources.\nUSDA and its agencies have taken actions to improve the security over their IT resources;\nhowever, additional actions are still needed to establish an effective security program.\n\nSincerely,\n\n\n/s/\n\n\nPhyllis K. Fong\nInspector General\n\x0cTable of Contents\n\nExecutive Summary ................................................................................... 1\xc2\xa0\n Recommendation Summary ........................................................................................ 8\xc2\xa0\nBackground & Objectives ....................................................................... 10\xc2\xa0\n Background ............................................................................................................... 10\xc2\xa0\n Objectives .................................................................................................................. 11\xc2\xa0\nScope and Methodology.......................................................................... 12\xc2\xa0\nExhibit A: Office of Management and Budget (OMB) Reporting\nRequirements and U.S. Department of Agriculture (USDA) Office of\nInspector General (OIG) Position ........................................................... 13\xc2\xa0\nAbbreviations ........................................................................................... 29\xc2\xa0\n\x0cU.S. Department of Agriculture, Office of the Chief Information Officer,\nFiscal Year 2009 Federal Information Security Management Act\n(Audit Report 50501-15-FM)\n\nExecutive Summary\nAlthough improvements have been made in the Department\xe2\x80\x99s information technology (IT)\nsecurity in the last decade, many longstanding weaknesses remain. Since 2001, the Office of\nInspector General (OIG) has reported material weaknesses in the design and effectiveness of the\nDepartment\xe2\x80\x99s overall IT security program. The U.S. Department of Agriculture (USDA) is a\nlarge and complex organization, which includes 29 separate agencies and staff offices, each with\nits own IT infrastructure. In order to mitigate the continuing material weaknesses, the\nDepartment should rethink its policy of attempting to simultaneously achieve numerous goals in\nshort timeframes. Instead, the Department and its agencies, working in cooperation, should\ndefine and accomplish one or two critical objectives prior to proceeding on to the next set of\npriorities.\nFor the Department\xe2\x80\x99s security program to be effective, agency inclusion and cooperation is\nessential. The Department needs to coordinate with each of its component agencies and offices\nto identify and prioritize the most significant security risks. It then needs to develop and\nimplement a prioritized plan to systematically mitigate the risks using realistic goals and\nmilestones. Once the plan is developed, the Department should continuously communicate with\nagencies to maintain their commitment to and progress towards implementing the needed\ncorrective actions. Departmentwide security improvements require cooperative Department and\nagency commitment and action. Until this occurs, critical data are exposed to an increased risk\nof inappropriate disclosure, modification, or deletion because of USDA\xe2\x80\x99s current security\nprogram.\nThe most important accomplishment for the Department in the past year was the implementation\nof the Cyber Security Assessment and Management (CSAM) system. CSAM is a comprehensive\nsystem developed by the Department of Justice, which can facilitate achieving Federal\nInformation Security Management Act (FISMA) 1 compliance. CSAM provides a vehicle for the\nDepartment, agencies, system owners, and security staffs to (1) manage their system inventory,\ninterfaces, and related system security threats and risks; (2) enter system security data into a\nsingle repository to ensure all system security factors are adequately addressed; (3) prepare\nannual system security documents, such as security plans, risk analyses, and internal security\ncontrol assessments; and (4) generate custom and pre-defined system security status reports to\neffectively and efficiently monitor each agency\xe2\x80\x99s security posture and FISMA compliance. It\nalso aids the Department and agencies in their testing of security controls, documenting\nweaknesses, and tracking the mitigation of those weaknesses.\nThis report constitutes OIG\xe2\x80\x99s independent evaluation of the Department\xe2\x80\x99s IT security program\nand practices, as required by FISMA.\nThe following summarizes the key matters discussed in exhibit A of this report. Exhibit A\ncontains OIG\xe2\x80\x99s responses to the Office of Management and Budget\xe2\x80\x99s (OMB)\xc2\xa0required questions.\n\n\n1\n FISMA of 2002, Title III, Information Security, dated December 17, 2002.\n\n 1\n\x0cThe questions were defined in OMB Memorandum M-09-29, Fiscal Year 2009 Reporting\nInstructions for the Federal Information Security Management Act and Agency Privacy\nManagement, dated August 20, 2009.\n\n\xe2\x80\xa2 To address OMB\xe2\x80\x99s questions, we reviewed the data entered by the Department and agencies\ninto the CSAM system. We found that although the Department had an accurate inventory of\nsystems, the CSAM system data pointed to problems in other areas. Specifically, our review of\nthe CSAM system data for the Department\xe2\x80\x99s 287 FISMA reportable systems showed:\n \xe2\x80\xa2 Current certification and accreditations 2 (C&A) were not completed for 53 systems;\n \xe2\x80\xa2 required 3 security controls were not reviewed and tested for 250 systems;\n \xe2\x80\xa2 contingency plans for 73 systems were not tested during the year; 4\n \xe2\x80\xa2 interconnections with other systems were not accurately reported as required 5 for 162\n systems; and\n \xe2\x80\xa2 12 systems were not accurately recorded in CSAM as contractor systems. 6\n\nAgency officials are responsible for ensuring that their systems meet Federal and Departmental\nrequirements and documenting that compliance in CSAM. The Office of the Chief Information\nOfficer (OCIO) is responsible for ensuring that the agencies are compliant with Federal and\nDepartmental guidance and they are reporting aggregate results during the annual FISMA\nreporting cycle. CSAM has a powerful reporting capability that can be used to generate\ninformation covering: current C&A status, completion of security control testing and review,\nand contingency plan testing results. The Department has access to the same CSAM information\nthat we evaluated during the FISMA review and should have been aware of each of the\nweaknesses we identified. The Department should more effectively use CSAM\xe2\x80\x99s capabilities in\nperforming its oversight responsibilities.\n\n\xe2\x80\xa2 Our review of the plan of action and milestones (POA&M) 7 process found the Department did\nnot have effective policies and procedures for reporting IT security deficiencies in CSAM. For\nexample, our review at one agency identified at least 35 instances where POA&Ms should have\nbeen created, but were not. In fact, the agency had not entered POA&Ms into CSAM for any IT\n\n2\n The C&A is a process mandated by OMB Circular A-130, Appendix III, \xe2\x80\x9cSecurity of Federal Automated Information\n Resources,\xe2\x80\x9d dated November 28, 2000. The process requires IT system controls be documented and tested by technical\n personnel and given the formal authority to operate by an agency official.\n3\n The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 2, Recommended\n Security Controls for Federal Information Systems, dated December 2007, requires periodic testing and evaluations of the\n effectiveness of information security policies, procedures, practices, and security controls to be performed with a frequency\n depending on risk, but not less than annually. The Department requires annual testing of 29 key controls; our number is based\n on 100 percent testing of those controls.\n4\n NIST SP 800-53 Revision 2, Recommended Security Controls for Federal Systems, dated December 2007, requires yearly\n testing of contingency plans.\n5\n FISMA requires agencies to identify information systems in an inventory, which includes identification (ID) of the interfaces\n between each system, and all other systems or networks, including those not operated by, or under the control of the agency.\n6\n A system hosted or operated by a contractor.\n7\n OMB Memorandum M-02-01, Guidance for Preparing and Submitting Security Plans of Action and Milestones, dated\n October 17, 2001, required each agency to submit to OMB by October 31, 2001 (with brief quarterly updates thereafter), \xe2\x80\x9ca plan\n of action with milestones\xe2\x80\x9d to address all weaknesses identified by program reviews and evaluations. It defines a POA&M as a\n tool that identifies tasks needing to be accomplished to assist agencies in identifying, assessing, prioritizing, and monitoring the\n progress of corrective efforts for security weaknesses found in programs and systems. The goal of a POA&M should be to\n reduce the risk of the weakness identified. CSAM is used as the USDA POA&M repository, and to track and report to OMB\n progress to mitigate the weaknesses.\n\n 2\n\x0csecurity weakness identified in fiscal year 2009. This occurred because the OCIO security\nmanual did not include a policy that establishes a POA&M 8 process for reporting IT security\ndeficiencies and tracking the status of remediation efforts. Although there were no formal\npolicies, the OCIO had a standard operating procedure (SOP) 9 on the POA&M Management\nProcess. Our review of the SOP determined that it was written prior to the implementation of\nCSAM and was no longer applicable.\n\nAlso, oversight of the POA&M process had not been a priority within the Department. As a\nresult, sufficient resources had not been committed to provide Departmental and agency staffs\xe2\x80\x99\nadequate training on POA&M management and oversight to ensure that all parties understood\nhow to accomplish an effective POA&M program. A common theme found during our fiscal\nyear 2009 reviews was that POA&Ms were considered to have negative consequences by agency\nsecurity personnel. They believed that the use of POA&Ms was discouraged by agency upper\nmanagement because they were viewed as a failure of the security staff to perform their\nresponsibilities. Therefore, the security staffs were reluctant to record and track POA&Ms. As a\nresult, the agency\xe2\x80\x99s IT resources were at a higher risk of compromise or malicious activity.\nOMB policy recognizes that the POA&M process is constructive. It ensures agencies are\nconstantly reviewing their security posture and working towards finding and mitigating\nweaknesses.\n\n\xe2\x80\xa2 Based on the OIG reviews performed throughout fiscal year 2009, we continue to find that\nagencies are not following NIST and Departmental 10 guidance when preparing C&A\ndocumentation. Agencies are required to submit their system C&A packages and all supporting\ndocumentation to the Department for an in-depth review (referred to as a concurrency review).\nDuring the concurrency review, the Department ensures that the documentation prepared to\nsupport system accreditation 11 is complete, accurate, reliable, and that it meets all NIST and\nother mandated documentation standards. We evaluated seven C&A concurrency reviews where\nthe Department had concurred with the agencies\xe2\x80\x99 recommendations to accredit the system. We\nfound that the agencies\xe2\x80\x99 security certification 12 documentation did not support accreditation. We\nfound that agencies had not followed NIST guidance in all seven cases. Specifically, we found\nthat three System Security Plans (SSP), 13 four risk assessments (RA), and seven testing\n\n\n\n8\n A POA&M is a tool that identifies tasks needing to be accomplished to assist agencies in identifying, assessing, prioritizing, and\n monitoring the progress of corrective efforts for security weaknesses found in programs and systems. It details resources\n required to accomplish the elements of the plan, milestones in meeting the task, and scheduled completion dates for the\n milestones. The goal of a POA&M should be to reduce the risk of the weakness identified.\n9\n POA&M Management Process, Standard Operating Procedure, dated February 27, 2008.\n10 NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, dated May 2004;\n Departmental Manual (DM) 3555-001, Certification and Accreditation Methodology, dated October 18, 2005.\n11\n Security accreditation is the official management decision given by a senior agency official to authorize operation of an\n information system and to explicitly accept the risk to agency operations, agency assets, or individuals based on the\n implementation of an agreed-upon set of security controls.\n12\n Security certification is a comprehensive assessment of the management, operational, and technical security controls in an\n information system, made in support of security accreditation, to determine the extent to which the controls are implemented\n correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the\n system.\n13\n The SSP is a required C&A document that provides an overview of the security requirements of the system and describes the\n controls in place (or planned) for meeting those requirements. The SSP also delineates responsibilities and expected behavior\n of all individuals who access the system. (NIST SP 800-18, Guide for Developing Security Plans for Federal Information\n Systems, dated February 2006).\n\n 3\n\x0cdocuments 14 did not meet NIST requirements; and two agencies had not selected the required\ncontrols to test. When reviewing CSAM, we found there were 34 systems with an expired\nauthority to operate or interim authority to operate (IATO). 15 We have reported problems in the\nC&A process since 2001 and attribute these continuing problems to a lack of commitment by\nagencies to a quality C&A process, as well as a lack of Departmental oversight. Agencies do not\nknow if required system controls have been implemented correctly because the controls may not\nhave been documented and tested. Systems, and the information in those systems, may be at risk\nif security controls have not been implemented correctly.\n\n\xe2\x80\xa2 We found two agencies were not performing continuous monitoring of security controls in\naccordance with NIST 16 guidance. Neither agency had documented the critical system controls\nthat needed to be monitored, the frequency of that monitoring, or the actions to be taken based on\nthe results of the monitoring. In addition, one agency did not effectively perform annual system\nself assessments or document the results in CSAM as required. The lack of continuous\nmonitoring was attributed to insufficient resources and agency staffs not realizing the importance\nof the process. Without a formal continuous monitoring plan, agencies cannot be certain that\nthey are accomplishing the objectives of their security program.\n\n\xe2\x80\xa2 The Department needed to take additional actions to minimize the risk of unauthorized release\nof \xe2\x80\x9cprivacy data\xe2\x80\x9d as required by OMB guidance. 17 Due to the complexity and age of the legacy\nsystems within USDA, the Department had not fully implemented its plan to reduce the use of\nsocial security numbers (SSN) as identifiers in application databases. OMB requires that the\nDepartment track all sensitive data extracts (i.e., extracts containing SSNs) to ensure the data are\nerased within 90 days or once they are no longer being used. The Department was not aware of\nthis requirement and had not implemented a policy or plan to address this task. Also, because of\ntechnical issues associated with getting encryption software to run on USDA workstations, the\noverall size of the Department and the diversity of programs, full disk encryption had only been\nimplemented on 53 percent of the Department\xe2\x80\x99s laptops. As a result, the potential exists for\nsensitive information to reside on unencrypted computers/devices. 18\n\n\n\n\n14\n A Security Testing and Evaluation (ST&E) is one phase of the C&A where an independent party evaluates and conducts\n testing of the controls established in and around a system. The purpose is to determine whether controls as stated in the system\n documentation are adequate and operating as prescribed.\n15\n Authority to Operate (ATO) or Interim Authority to Operate (IATO) is the last step in the C&A process. If C&A is adequate\n and meets NIST requirements an ATO is given for a period of 3 years. If after assessing the results of the security certification\n the agency deems that the risk to agency operations is unacceptable, but there is an overarching necessity to place the system\n into operation or continue its operation, an IATO may be issued for up to 6 months in order for the agency to fix the\n vulnerabilities in the IT system.\n16\n NIST SP 800-53, Revision 2, Recommended Security Controls for Federal Information Systems, dated December 2007,\n requires agencies to \xe2\x80\x9cmonitor and assess selected security controls in the information system on a continuous basis including\n documenting changes to the system, conducting security impact analyses of the associated changes, and reporting the security\n status of the system to appropriate organizational officials on a regular basis.\xe2\x80\x9d\n17\n OMB Memorandum M-06-15, Safeguarding Personally Identifiable Information, dated May 22, 2006; OMB Memorandum M-\n 06-16, Protection of Sensitive Agency Information, dated June 23, 2006; OMB Memorandum M-07-16, Safeguarding Against\n and Responding to the Breach of Personally Identifiable Information, dated May 22, 2007.\n18\n The next step of the Department\xe2\x80\x99s encryption effort will include external storage media. OCIO stated this will begin in the\n next few months.\n\n 4\n\x0c\xe2\x80\xa2 We reviewed the Department\xe2\x80\x99s Privacy Impact Assessment (PIA) implementation as required\nby the e-Government Act of 2002. 19 The Department is required to publish all PIAs on a\npublicly accessible website. We found that 13 of the required 122 PIAs were missing from the\nDepartment\xe2\x80\x99s website.\n\n\xe2\x80\xa2 NIST 20 states \xe2\x80\x9calthough the solutions to IT security are complex, one simple yet effective tool\nis the security configuration checklist.\xe2\x80\x9d Both NIST and the Department 21 have issued policies\nrequiring the use of checklists when deploying certain software. We found that agencies were\nnot using the required checklists when deploying the software covered by the NIST\nrequirements. Specifically, we scanned systems at two agencies using a commercially available\nsoftware tool that compares implemented server settings with those required by NIST and\nDepartmental checklists. One agency stated it used a checklist but did not know if it was NIST\ncompliant (we determined that it was not compliant). The other agency stated the security\nconfiguration checklist settings caused operational problems. As a result, it implemented only\n69 percent of the settings. The agency had not documented the reasons for not implementing the\nremaining 31 percent of the settings. The use of security configuration checklists to deploy\nsoftware and hardware ensures consistency across the agency and ease of maintenance. When\nUSDA agencies do not use and follow the checklists, helpdesk support, inventory management\ncapabilities, and operating costs are all negatively affected due of the lack of standardization.\n\n\xe2\x80\xa2 OMB 22 required agencies with Windows Vista or Windows XP operating systems, and/or\nplans to upgrade to these operating systems, to adopt standard security configurations on\nworkstations by February 1, 2008. The standard security configurations were developed by\nNIST, the Department of Defense, and the Department of Homeland Security and are commonly\nreferred to as the Federal Desktop Core Configuration (FDCC). Because of the complexity of\nthe Department and its many diverse systems, it did not meet the OMB mandated deadline. The\nDepartment issued a memo on February 15, 2008, requiring agencies to be FDCC compliant by\nJuly 31, 2008. As of September 30, 2009, the Department reported only 8 percent of machines\nhad deployed 100 percent of the FDCC standard security configuration settings. However, for\nthose machines without full deployment of the FDCC standard security configuration settings,\nthe Department reported an average of about 90 percent of the settings were deployed. We have\nnot validated this percentage or the actual settings deployed. As a result, we do not know the\nextent to which their workstations are properly secured and in compliance with the FDCC.\n\n\n\n\n19\n e-Government Act of 2002, PL 107\xe2\x80\x93347, dated December 17, 2002, requires agencies to conduct PIA for new IT investments\n and online information collections. A PIA is a review of how information about individuals is handled within the agency when\n the agency uses IT to collect new information, or when agencies develop or buy new IT systems to handle collections of\n personally identifiable information.\n20\n NIST SP 800-70, Security Configuration Checklists Program for IT Products \xe2\x80\x93 Guidance for Checklists Users and Developers,\n dated May 2005.\n21\n OCIO issued a memorandum, Required Use of Security Configuration Guides, dated March 10, 2009.\n22\n OMB Memorandum 07-11, Implementation of Commonly Accepted Security Configurations for Windows Operating Systems,\n dated March 22, 2007.\n\n 5\n\x0c\xe2\x80\xa2 The Department had made progress in the required 23 reporting of security incidents 24 to law\nenforcement and the US-Computer Emergency Readiness Team (US-CERT). 25 However, we\nfound that due to the volume of incidents throughout the year, the Department did not always\nfollow its own security review procedures. We reviewed 49 incidents (5 privacy-related) and\nfound only 18 of the 49 (37 percent) incidents were handled in accordance with Departmental\nprocedures, which require that agencies submit documentation to the OCIO and carryout pre-\ndefined steps. The procedures also require that the agency undertake and document a thorough\ninvestigation of the initial cause of the incident. In addition, the procedures require agencies to\nsubmit a detailed final report to the OCIO outlining the steps taken to mitigate the cause of the\nincident. Despite these procedures, we found that:\n\n \xe2\x80\xa2 19 incidents did not have all required documentation;\n \xe2\x80\xa2 16 incidents were reported as closed, before the required reviews were completed;\n \xe2\x80\xa2 12 incidents were not adequately investigated;\n \xe2\x80\xa2 12 incidents had incomplete final reports; and\n \xe2\x80\xa2 5 privacy-related incidents were improperly handled.\n\nOCIO officials stated that errors occurred in the handling of the incidents due to the volume of\nthe reported incidents. We found that OCIO staff and contractor personnel were unclear as to\nwhat procedures to follow when security incidents were reported. For example, OCIO and its\ncontractor staff did not always ensure that agencies included the checklists contained in the\nprocedure\xe2\x80\x99s appendix with its incident submissions. When we inquired as to why the checklists\nwere not included, the OCIO personnel stated that since checklists were an appendix to the\nprocedures they were not required. The appendix\xe2\x80\x99s checklists are required when an agency\nreports an incident.\n\nOMB 26 has mandated that an incident be reported within 1 hour when it may involve privacy\ninformation. The Department included OMB\xe2\x80\x99s mandated timeframe in its procedures for\nhandling privacy incidents. The OCIO officials stated that staff did not always follow\nprocedures when handling privacy incidents because of the unrealistic timeframe mandated by\nOMB, even though it had included the timeframe in its own procedures. This failure to follow\npolicies and procedures may affect the Department\xe2\x80\x99s ability to rapidly detect incidents and the\nloss of privacy information. The rapid detection and reporting of incidents is essential for\nminimizing data loss and destruction, mitigating any exploited weaknesses, and restoring\ncomputing services.\n\n\n\n\n23\n Agriculture Security Operations Center Computer Incident Response Team-Standard Operating Procedures for Reporting\n Security and Personally Identifiable Information Incidents, dated June 9, 2009.\n24\n DM 3505-000, USDA Cyber Security Incident Handling Procedures, dated March 20, 2006, states an incident is a violation or\n imminent threat of violation of computer security policies, acceptable use or standard computer security practices. It is also\n any adverse event whereby some aspect of a computer system is compromised, such as loss of data confidentiality, disruption\n of data integrity, or disruption or denial of service.\n25\n US-CERT provides response support and defense against cyber attacks for the Federal Civil Executive Branch (.gov) and\n information sharing and collaboration with State and local Government, industry and international partners. US-CERT is the\n operational arm of the National Cyber Security Division (NCSD) at the Department of Homeland Security (DHS). The NCSD\n was established by DHS to serve as the Federal Government\xe2\x80\x99s cornerstone for cyber security coordination and preparedness.\n26\n OMB Memorandum 07-16 requires reporting to US-CERT within 1 hour of discovery/detection.\n\n 6\n\x0c\xe2\x80\xa2 The Department has made significant improvements to ensure that all employees receive\nsecurity awareness training; however, there was no consistent method for tracking security\ntraining for USDA contractors. The Department has a database to maintain a record of all\ncontractors within the Department; however, use of the database was not required and only two\nagencies were using it. Therefore, it was difficult for the Department and the agencies to identify\ncontractors, their access controls, and whether they had received the required27 training.\n\n\xe2\x80\xa2 Federal law, NIST, and the Department 28 require all users with significant security\nresponsibilities to receive specialized role-based training, in addition to security awareness\ntraining. We were unable to determine whether all employees that should have received the\nadditional role-based training actually received it. Agencies interpreted the definition of\n\xe2\x80\x9csignificant IT security responsibilities\xe2\x80\x9d differently because the Department\xe2\x80\x99s security training\npolicy did not clearly define what \xe2\x80\x9csignificant IT security responsibilities\xe2\x80\x9d encompassed. For\nexample, one agency determined that only the staff working in its security office had significant\nsecurity responsibilities and needed the training. Another agency interpreted the definition of\nsignificant security responsibilities to apply to all staff with elevated privileges 29 to the agency\xe2\x80\x99s\nsystems. As a result, employees who were actually assigned significant IT security\nresponsibilities did not receive the additional training, as required by law, NIST, and the\nDepartment.\n\n\xe2\x80\xa2 For a number of years, we have recommended that the Department adopt a verifiable scanning\nand reporting process. OIG has been scanning USDA networks for vulnerabilities for over 9\nyears and continues to identify a significant number of weaknesses. To achieve a better\nunderstanding of the security posture of the Department, we scanned the networks of two\nagencies using industry standard, commercially available software. 30 The scanning software is\nconstantly updated with current information, allowing it to identify both old and new\nvulnerabilities in servers, workstations, network devices, and websites. Our scans and reviews\nidentified a number of issues.\n\n\xe2\x80\xa2 A review of each agency\xe2\x80\x99s servers, workstations, and network devices was conducted to\ndetermine if vulnerabilities were being mitigated in a timely manner. To make this\ndetermination, we compared an agency\xe2\x80\x99s scan results for multiple months. We concluded that\nthe vulnerability was not mitigated in a timely manner if it continued to exist on multiple\nmonthly scans and a POA&M had not been created. We found over 20,000 vulnerabilities on\nagencies\xe2\x80\x99 servers, workstations, and networks that had not been mitigated in a timely manner.\n\n \xe2\x80\xa2 We requested from each agency an inventory of the devices attached to its networks and a\n list of the devices that it was scanning. The two lists were then compared. We found that\n some devices were not being scanned.\n\n27\n FISMA of 2002, Title III Information Security, dated December 17, 2002 and NIST SP 800-53, Revision 2, Recommended\n Security Controls for Federal Information Systems, dated December 2007.\n28\n NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model, April\n 1998, FISMA, and DM 3545-001, Computer Security Training and Awareness, dated February 17, 2005.\n29\n Elevated privileges are those above a normal system user. These would include staff that had administrative privileges to\n servers, databases and networks.\n30\n The commercially available software scans workstations, servers, network devices and websites to look for known\n vulnerabilities that have not been mitigated. Some of the items scanned for include: missing patches, poor website coding\n practices and insecure software settings.\n\n 7\n\x0c \xe2\x80\xa2 Each agency\xe2\x80\x99s network devices were evaluated to determine if they were configured in\n accordance with NIST 31 standards. We found 299 critical settings 32 that were not in\n conformance.\n\n \xe2\x80\xa2 The code used to construct agency controlled websites was evaluated to determine if it was\n written so that the website was secure. The software identified 322 instances where the\n implemented code was not secure.\n\n \xe2\x80\xa2 Servers and workstations were analyzed to determine if required software patches were\n applied in a timely manner. The software identified 1,705 required patches that had not\n been installed on servers and 36,184 required patches that had not been installed on\n workstations.\n\nAgencies stated that timing issues, a lack of resources, and their unfamiliarity with scanning\nrequirements contributed to these issues. As a result, USDA networks and information\ntechnology resources are vulnerable to illegal and malicious activity, and exploitation by internal\nand external sources.\n\n\n Recommendation Summary\n 1. Develop and implement an effective plan to mitigate the material IT weakness within\n the Department in cooperation with the agencies. Ensure the plan includes prioritized\n tasks, defined goals, and realistic timeframes. The Department and its agencies,\n working in cooperation, should define and accomplish one or two critical objectives\n prior to proceeding on to the next set of priorities.\n 2. Develop and implement effective policies and procedures to fully utilize CSAM for\n Departmental oversight.\n 3. Develop and implement an effective monthly FISMA scorecard to be used for agency\n reporting and Departmental oversight. Ensure that the scorecard includes verifiable\n items such as, but not limited to: vulnerability scanning, patching, anti-virus reports,\n and training.\n 4. Develop and implement an effective process to ensure system interfaces are\n accounted for in CSAM.\n 5. Develop and implement an effective process to ensure POA&Ms are entered, tracked,\n and closed properly. The process should include the required link to budgetary\n resources.\n 6. Develop and implement an effective C&A process based on NIST guidance. Ensure\n that all systems have the proper authority to operate.\n\n\n\n31\n NIST SP 800-53, Revision 2, Recommended Security Controls for Federal Information Systems, dated December 2007.\n32\n Critical security settings are those software configuration settings which may allow a device or software on a device to be\n compromised because they are not set in the most secure manner possible.\n\n 8\n\x0c7. Issue Departmental guidelines implementing continuous monitoring in accordance\n with NIST guidance.\n8. Implement all requirements of the OMB Privacy memos.\n9. Implement effective policies and procedures to ensure agencies use required NIST\n and Departmental configuration checklists and have documented the reasons for those\n settings not implemented.\n10. Complete the FDCC deployment and ensure all FDCC deviations are documented by\n the agencies.\n11. Ensure all OCIO personnel and contractors adhere to Departmental policies and\n procedures concerning incident reporting, including the OMB mandated timeframes\n for reporting incidents.\n12. Develop training policies and procedures for personnel with significant security\n responsibilities; to include a Departmental definition of what constitutes significant\n security responsibilities.\n13. Ensure that encryption of all mobile computers/devices is completed timely, to\n include removable storage devices/media.\n14. Develop and implement policies and procedures requiring all agencies to populate\n and regularly update the Non-Employee Identity System with contractor information.\n\n\n\n\n 9\n\x0cBackground & Objectives\n\nBackground\nImproving the overall management and security of IT resources needs to be a top priority for\nUSDA. As technology has enhanced the ability to share information instantaneously among\ncomputers and networks, it has also made organizations\xe2\x80\x99 networks and IT resources vulnerable to\nmalicious activity and exploitation by internal and external sources. Insiders with malicious\nintent, recreational and institutional hackers, and attacks by foreign intelligence organizations are\nbut a few of the threats that pose risks to the Department\xe2\x80\x99s critical systems and data.\n\nOn December 17, 2002, the President signed into law the e-Government Act (Public Law (PL)\n107-347), which includes Title III, \xe2\x80\x9cFederal Information Security Management Act\xe2\x80\x9d. FISMA\npermanently reauthorized the framework established by the Government Information Security\nReform Act (GISRA) of 2000, which expired in November 2002. FISMA continued the annual\nreview and reporting requirements introduced in GISRA. In addition, FISMA included new\nprovisions that further strengthened the Federal Government\xe2\x80\x99s information and information\nsystems security, such as the development of minimum control standards for agencies\xe2\x80\x99 systems.\nNIST was tasked to work with agencies developing those standards per its statutory role in\nproviding technical guidance to Federal agencies.\n\nFISMA supplements information security requirements established in the Computer Security Act\nof 1987, the Paperwork Reduction Act of 1995, and the Clinger-Cohen Act of 1996. The Act is\nconsistent with existing information security guidance issued by OMB and NIST. More\nimportantly, however, FISMA consolidated these separate requirements and guidance into an\noverall framework for managing information security. It established new annual reviews,\nindependent evaluation, and reporting requirements to ensure agencies implemented FISMA. It\nalso provided both OMB and Congressional oversight.\n\nFISMA assigned specific responsibilities to OMB, agency heads, Chief Information Officers\n(CIO), and Inspector Generals (IG). OMB is responsible for establishing and overseeing\npolicies, standards, and guidelines for information security. The responsibilities include the\nauthority to approve agencies information security programs. OMB also requires the submittal\nof an annual report to Congress summarizing the results of agencies\xe2\x80\x99 evaluations of their\ninformation security programs.\n\nEach agency must establish a risk-based information security program that ensures that\ninformation security is practiced throughout the lifecycle of each of the agency\xe2\x80\x99s systems.\nSpecifically, the agency\xe2\x80\x99s CIO must oversee this program, which must include:\n\n \xe2\x80\xa2 Periodic RAs that consider internal and external threats to the integrity, confidentiality, and\n availability of systems, and to data supporting critical operations and assets;\n \xe2\x80\xa2 development and implementation of risk-based, cost-effective policies and procedures to\n provide security protections for the agency\xe2\x80\x99s information;\n \xe2\x80\xa2 training that covers security responsibilities for information security personnel and security\n awareness for agency personnel;\n\n\n 10\n\x0c \xe2\x80\xa2 periodic management testing and evaluation of the effectiveness of security policies,\n procedures, controls, and techniques;\n \xe2\x80\xa2 processes for identifying and remediating significant security deficiencies;\n \xe2\x80\xa2 procedures for detecting, reporting, and responding to security incidents; and\n \xe2\x80\xa2 annual program reviews by agency officials.\n\nIn addition to the responsibilities listed above, FISMA requires each agency to have an annual\nindependent evaluation of its information security program and practices, including control\ntesting and compliance assessment. The evaluations are to be performed by the agency\xe2\x80\x99s IG or\nan independent evaluator, and the results of these evaluations are to be reported to OMB.\n\n\nObjectives\nThe objective of this audit was to evaluate the status of USDA\xe2\x80\x99s overall IT security program by:\n \xe2\x80\xa2 Evaluating the effectiveness of OCIO\xe2\x80\x99s oversight of agencies\xe2\x80\x99 CIOs, and compliance with\n FISMA;\n \xe2\x80\xa2 determining whether agencies maintain an adequate system of internal controls over IT\n assets in accordance with FISMA and other applicable laws and regulations;\n \xe2\x80\xa2 evaluating OCIO\xe2\x80\x99s progress in establishing a Departmentwide security program, which\n includes effective certifications and accreditations;\n \xe2\x80\xa2 evaluating the agencies\xe2\x80\x99 and OCIO\xe2\x80\x99s POA&M consolidation and reporting process; and\n \xe2\x80\xa2 analyzing USDA\xe2\x80\x99s Privacy Act documentation to ensure USDA has adequate safeguards to\n prevent the intentional or negligent misuse of, or unauthorized access to, personally\n identifiable information.\n\n\n\n\n 11\n\x0cScope and Methodology\n\nThe scope of our review was Departmentwide and included agency IT audits completed during\nfiscal year 2009. We conducted this audit in accordance with Government Auditing Standards.\nThose standards required we plan and perform the audit to obtain sufficient, appropriate evidence\nto provide a reasonable basis for our findings and conclusions based on our audit objectives. We\nbelieve the evidence obtained provides a reasonable basis for our findings and conclusions based\non our audit objectives.\n\nFieldwork for this audit was performed at OCIO from June to October 2009. In addition, the\nresults of IT control testing and compliance with laws and regulations performed by contract\nauditors at four additional agencies are included in this report. In total, our fiscal year 2009 audit\nwork covered 10 agencies and staff offices: Economic Research Service (ERS), Food and\nNutrition Service, Forest Service, Farm Service Agency (FSA), Food Safety and Inspection\nService, Natural Resources Conservation Service (NRCS), Office of the Chief Financial Officer\n(OCFO), OCIO, Rural Development, and Risk Management Agency. These agencies and staff\noffices operate approximately 181 of the OCIO\xe2\x80\x99s estimated 287 general support and major\napplication systems within the Department.\n\nTo accomplish our audit objectives, we performed the following procedures:\n\n \xe2\x80\xa2 Consolidated the results and issues from our prior IT security audit work and the work of\n contractors administered by USDA\xe2\x80\x99s OIG. Contractor audit work consisted primarily of\n audit procedures found in the U.S. Government Accountability Office\xe2\x80\x99s (GAO) Financial\n Information System Control Audit Manual;\n \xe2\x80\xa2 evaluated the Department\xe2\x80\x99s progress in implementing recommendations to correct material\n weaknesses identified in prior OIG and GAO audit reports;\n \xe2\x80\xa2 gathered the necessary information to address the specific reporting requirements outlined\n in OMB Memorandum M-09-29, Fiscal Year 2009 Reporting Instructions for the Federal\n Information Security Management Act and Agency Privacy Management, dated August 20,\n 2009; and,\n \xe2\x80\xa2 performed detailed testing specific to FISMA requirements at selected agencies as detailed\n in this report.\n\n\n\n\n 12\n\x0cExhibit A: Office of Management and Budget (OMB) Reporting\nRequirements and U.S. Department of Agriculture (USDA) Office of\nInspector General (OIG) Position\n(OMB Questions are in bold, OIG responses are underlined)\n\nQuestion 1:\nFISMA Systems Inventory\nIdentify the number of Agency and contractor systems by component and FIPS 199 impact\nlevel (low, moderate, high) reviewed.\n\nQuestion 2:\nCertification and Accreditation, Security Controls Testing, and Contingency Plan Testing\nFor the Total Number of Reviewed Systems Identified by Component/Bureau and FIPS\nSystem Impact Level in the table for Question 1, identify the number and percentage of\nsystems which have: a current certification and accreditation, security controls tested and\nreviewed the past year, and a contingency plan tested in accordance with policy.\n\nNote: Totals listed below are not Department totals, but represent only those 10 agencies\nreviewed by OIG or OIG contractors during fiscal year 2009.\n\nAs of 10/6/2009 Question 1 Question 2\n\n\n\n\n 2.b\n Number of 2.c\n systems for Number of\n which systems for\n 1.c security which\n Total 2.a controls contingency\n Number of Number of have been plans have\n FIPS 199 1.a 1.b Systems systems tested and been tested\n System FY FY 2009 (Agency and certified reviewed in\nBureau Name Impact 2009Agency Contractor Contractor and in the past accordance\n Level Systems Systems systems) accredited year with policy\n # # # # # # # # #\n Total Rev. Total Rev. Total Rev. Total Total Total\nEconomic High 0 0 0 0 0 0 0 0 0\nResearch\nService Moderate 1 1 0 0 1 1 1 0 0\n Low 0 0 0 0 0 0 0 0 0\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 1 1 0 0 1 1 1 0 0\nFood and High 0 0 0 0 0 0 0 0 0\nNutrition\nService Moderate 7 2 3 0 10 2 7 0 3\n Low 1 0 0 0 1 0 0 0 0\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 8 2 3 0 11 2 7 0 3\n\n\n\n 13\n\x0cForest Service High 1 0 0 0 1 0 1 0 1\n Moderate 16 3 5 2 21 5 20 0 20\n Low 4 0 0 0 4 0 4 0 4\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 21 3 5 2 26 5 25 0 25\nFarm Service High 0 0 0 0 0 0 0 0 0\nAgency -\nCommodity Moderate 48 10 0 0 48 10 41 32 48\nCredit Low 22 0 0 0 22 0 21 0 22\nCorporation\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 70 10 0 0 70 10 62 32 70\nFood Safety and High 0 0 0 0 0 0 0 0 0\nInspection\nService Moderate 12 1 0 0 12 1 12 0 5\n Low 0 0 0 0 0 0 0 0 0\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 12 1 0 0 12 1 12 0 5\nNatural High 0 0 0 0 0 0 0 0 0\nResources\nConservation Moderate 3 3 0 0 3 3 3 0 3\nService Low 0 0 0 0 0 0 0 0 0\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 3 3 0 0 3 3 3 0 3\nOffice of Chief High 11 10 0 0 11 10 10 1 10\nFinancial\nOfficer Moderate 13 2 0 0 13 2 11 0 12\n Low 0 0 0 0 0 0 0 0 0\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 24 12 0 0 24 12 21 1 22\nOffice of Chief High 0 0 0 0 0 0 0 0 0\nInformation\nOfficer \xe2\x80\x93 Moderate 2 1 2 0 4 1 4 0 0\nInformation Low 1 0 0 0 1 0 1 0 0\nTechnology\nManagement Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 3 1 2 0 5 1 5 0 0\nOffice of Chief High 4 3 0 4 3 3 0 1\nInformation\nOfficer - Moderate 5 0 0 0 5 0 4 0 4\nNational Low 5 0 0 0 5 0 4 1 4\nInformation\nTechnology Not 0 0 0 0 0 0 0 0 0\nCenter Categorized\n Sub-Total 14 3 0 0 14 3 11 1 9\n\n\n\n\n 14\n\x0cRural High 0 0 0 0 0 0 0 0 0\nDevelopment\n Moderate 10 1 0 0 10 1 10 1 10\n Low 2 0 0 0 2 0 2 0 2\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 12 1 0 0 12 1 12 1 12\nRisk High 0 0 0 0 0 0 0 0 0\nManagement\nAgency Moderate 3 3 0 0 3 3 3 0 0\n Low 0 0 0 0 0 0 0 0 0\n Not 0 0 0 0 0 0 0 0 0\n Categorized\n Sub-Total 3 3 0 0 3 3 3 0 0\n\n\nTOTALS: HIGH 16 13 0 0 16 13 14 1 12\n MOD 120 27 10 2 130 29 116 33 105\n LOW 35 0 0 0 35 0 32 1 32\n NOT CAT 0 0 0 0 0 0 0 0 0\n\nGRAND 171 40 10 2 181 42 162 35 149\nTOTALS:\n\n\n\nTotals for the entire Department are:\n\n \xe2\x80\xa2 Total USDA reportable systems \xe2\x80\x93 287 (Question 1);\n \xe2\x80\xa2 Number of systems Certified and Accredited \xe2\x80\x93 234 (Question 2a);\n \xe2\x80\xa2 Number of systems for which security controls had been tested and reviewed in the past\n year 33 \xe2\x80\x93 37 (Question 2b); and\n \xe2\x80\xa2 Number of systems for which contingency plans had been tested during the past year in\n accordance with policy (Question 2c) - 214.\n\nQuestion 3:\nEvaluation of Agency Oversight of Contractor Systems and Quality of Agency System\nInventory\n\nThe Agency performs oversight and evaluation to ensure information systems used or\noperated by a contractor of the Agency or other organization on behalf of the Agency meet\nthe requirements of FISMA, OMB policy and NIST guidelines, national security policy,\nand Agency policy.\n\nAgencies are responsible for ensuring the security of information systems used by a\ncontractor of their Agency or other organization on behalf of their Agency; therefore, self\nreporting by contractors does not meet the requirements of law. Self-reporting by another\n\n\n33\n The Department requires annual testing of 29 key controls; our number was based on 100 percent testing of those\n controls.\n\n\n 15\n\x0cFederal Agency, for example, a Federal service provider may be sufficient. Agencies and\nservice providers have a shared responsibility for FISMA compliance.\n\n3a. Does the Agency have policies for oversight of contractors? Yes/No\n\nOIG requested the Department\'s policy for contractor oversight but it was not provided. OCIO\nresponded that contractor oversight was specified in each individual contract.\n\n3b. Does the Agency have a materially correct inventory of major information systems\n(including national security systems) operated by or under the control of such Agency.\nYes/No\n\nThe Cyber Security Assessment and Management (CSAM) system is the official repository for\nthe Department\xe2\x80\x99s system inventory. Our review disclosed a total of 287 FISMA reportable\nsystems, which corresponded to the Department\xe2\x80\x99s inventory count.\n\n3c. Does the Agency maintain an inventory of interfaces between the Agency systems and\nall other systems, such as those not operated by or under the control of the Agency? Yes/No\n\nFISMA 34 requires agencies to maintain an inventory of information systems, which includes an\nidentification of the interfaces between each system, and all other systems or networks, including\nthose not operated by, or under the control of the agency.\n\nWe found the Department was not maintaining an accurate inventory of interfaces in CSAM.\nWe reviewed each of the interfaces listed in each System Security Plan (SSP) 35 for the\n287 FISMA reportable systems. We then compared that list of interfaces to those documented in\nCSAM and found that 162 out of the 287 systems were not accurately reporting interfaces with\nother systems. In most instances, the SSP documented more interfaces than were recorded in\nCSAM. Agencies are responsible for accurately documenting interface data in CSAM and failed\nto accurately account for all interconnections. Since interfaces allow the exchange of data\nbetween two systems, it is important that security controls in each interconnected system\naccurately reflect the risk of inadvertent disclosure of information. Without proper\ndocumentation and testing of those interfaces, the confidentiality, integrity, and availability of\nthe exchanged data could have been compromised without discovery.\n3d. Does the Agency require agreements for interfaces between systems it owns or operates\nand other systems not operated by or under the control of the Agency? Yes/No\n\nInterface agreements are required to be in place and operational on the SSP template provided to\neach agency.\n\n\n\n\n34\n FISMA of 2002, Title III Information Security, dated December 17, 2002.\n35\n The SSP is a required C&A document that provides an overview of the security requirements of the system and describes the\n controls in place (or planned) for meeting those requirements. The SSP also delineates responsibilities and expected behavior\n of all individuals who access the system (National Institute of Standards and Technology (NIST), Special Publication (SP) 800-\n 18, Guide for Developing Security Plans for Federal Information Systems, dated February 2006).\n\n 16\n\x0c3e. The Agency inventory is maintained and updated at least annually. Yes/No\n\nWe found the Department conducted semi-annual inventory reconciliations.\n\n3f. The IG generally agrees with the CIO on the number of Agency-owned systems. Yes/No\n\nOur review of the CSAM inventory found 19 contractor systems. However, during our review\nof the SSPs, we discovered 31 systems were actually hosted or operated by a contractor. The\nnumber of systems owned by the Department should be decreased by the 12 contractor systems\nthat are misreported in CSAM as agency owned systems. This does not change the total number\nof 287 FISMA reportable systems identified in CSAM.\n\n3g. The IG generally agrees with the CIO on the number of information systems used or\noperated by a contractor of the Agency or other organization on behalf of the Agency.\nYes/No\n\nThe number of contractor systems listed in CSAM is inaccurate. We found 12 additional\ncontractor systems being reported as agency owned systems (see 3f).\nQuestion 4:\nEvaluation of Agency Plan of Action and Milestone (POA&M) Process\n\nAssess whether the Agency has developed, implemented, and is managing an Agency-wide\nplan of action and milestones (POA&M) process, providing explanatory detail in the area\nprovided.\n\n4a. Has the Agency developed and documented an adequate policy that establishes a\nPOA&M process for reporting IT security deficiencies and tracking the status of\nremediation efforts? Yes/No\n\nThe OCIO security manual does not include policy for establishing a POA&M 36 process for\nreporting IT security deficiencies and for tracking the status of remediation efforts. Although\nthere are no formal policies, the OCIO has prepared a standard operating procedure (SOP) 37\nconcerning the POA&M Management Process. Our review of the SOP determined that it was\nwritten prior to the implementation of CSAM and is no longer applicable. Also, we found that\nOMB\xe2\x80\x99s requirement 38 to link budgetary resources to POA&Ms has not been met. We found\n1,263 out of 4,502 POA&Ms in CSAM did not have the required budgetary links. As a result of\n\n36\n A POA&M is a tool that identifies tasks that need to be accomplished to assist agencies in identifying, assessing,\n prioritizing, and monitoring the progress of corrective efforts for security weaknesses found in programs and\n systems. It details resources required to accomplish the elements of the plan, milestones in meeting the task, and\n scheduled completion dates for the milestones. The goal of a POA&M should be to reduce the risk of the\n weakness identified.\n37\n POA&M Management Process, Standard Operating Procedure, dated February 27, 2008.\n38\n OMB Memorandum M-02-01, Guidance for Preparing and Submitting Security Plans of Action and Milestones,\n dated October 17, 2001, states that, \xe2\x80\x9cto promote greater attention to security as a fundamental management\n priority, OMB continues to take steps to integrate security into the capital planning and budget process,\xe2\x80\x9d and\n requires each POA&M to be linked to its budgetary and capital planning by including the unique project identifier\n on all POA&Ms.\n 17\n\x0cthis lack of guidance, agencies were unclear about when to enter POA&Ms, what information\nshould be included, and in some cases were not entering them at all (see 4c).\n\n4a(1). Has the Agency fully implemented the policy? Yes/No\n\nThere is not a current Departmental policy for the POA&M process (See 4a).\n\n4b. Is the Agency currently managing and operating a POA&M process? Yes/No\n\nCSAM provided the Department an extremely useful tool for managing and operating POA&Ms.\nHowever, the Department and agencies are not effectively utilizing the tool (see 4c).\n\n4c. Is the Agency\xe2\x80\x99s POA&M process an Agency-wide process, incorporating all known IT\nsecurity weakness, including IG/external audit findings associated with information\nsystems used or operated by the Agency or by a contractor of the Agency or other\norganization on behalf of the Agency? Yes/No\n\nOur review of the POA&M 39 process found the Department does not have effective policies and\nprocedures for reporting IT security deficiencies in CSAM. For example, our review at one\nagency identified at least 35 instances where POA&Ms should have been created, but were not.\nIn fact, the agency has not entered POA&Ms into CSAM for any IT security weakness identified\nduring fiscal year 2009. In another agency, we found 543 weaknesses that were not documented\nand tracked as POA&Ms. This occurred because the OCIO security manual does not include a\npolicy that establishes a POA&M process for reporting IT security deficiencies and tracking the\nstatus of remediation efforts. Although there are no formal policies, the OCIO has prepared a\nStandard Operating Procedure 40 on the POA&M management process. Our review of the SOP\ndetermined that it was written prior to the implementation of CSAM and is no longer applicable.\n\nAlso, oversight of the POA&M process has not been a priority within the Department. As a\nresult, sufficient resources have not been committed to provide Departmental and agency staffs\xe2\x80\x99\nadequate training on POA&M management and oversight to ensure that all parties understand\nhow to accomplish an effective POA&M program. A common theme found during our FY 2009\nreviews was that POA&Ms were considered to have negative consequences by agency security\npersonnel. They believed that the use of POA&Ms was discouraged by agency upper\nmanagement because they were viewed as a failure of the security staffs to perform their\nresponsibilities. Therefore, the security staffs were reluctant to record and track POA&Ms. As a\nresult, the agency\xe2\x80\x99s IT resources are at a higher risk of compromise or malicious activity. OMB\npolicy recognizes that the POA&M process is constructive. It ensures agencies are constantly\nreviewing their security posture and working towards finding and mitigating weaknesses.\n\n\n39\n OMB Memorandum M-02-01, Guidance for Preparing and Submitting Security Plans of Action and Milestones, dated\n October 17, 2001, required each agency to submit to OMB by October 31, 2001 (with brief quarterly updates thereafter), \xe2\x80\x9ca\n plan of action with milestones\xe2\x80\x9d to address all weaknesses identified by program reviews and evaluations. It defines a\n POA&M as a tool that identifies tasks needing to be accomplished to assist agencies in identifying, assessing, prioritizing, and\n monitoring the progress of corrective efforts for security weaknesses found in programs and systems. The goal of a POA&M\n should be to reduce the risk of the weakness identified. CSAM is used as the USDA POA&M repository, and to track and\n report to OMB progress toward mitigating the weaknesses.\n40\n POA&M Management Process, Standard Operating Procedure, dated February 27, 2008.\n\n 18\n\x0c4d. Does the POA&M process prioritize IT security weakness to help ensure significant IT\nsecurity weaknesses are corrected in a timely manner and receive appropriate resources?\nYes/No\n\nWe determined that 100 percent of the POA&Ms entered into CSAM had a priority.\n\n4e. When an IT security weakness is identified, do program officials (including CIOs, if\nthey own or operate a system) develop, implement, and manage POA&Ms for their\nsystem(s)? Yes/No\n\nAgencies are not creating all of the necessary POA&Ms, thus, the current POA&M process is\nnot ensuring that all weaknesses were being entered (see 4c).\n\n4f. For Systems Reviewed:\n4f(1). Are deficiencies tracked and remediated in a timely manner? Yes/No\n\nAgencies are bundling unrelated deficiencies into a single POA&M and are not creating the\nnecessary POA&Ms for some identified weaknesses; therefore, the Department cannot be\nassured that deficiencies are tracked and remediated in a timely manner (see 4c).\n\n4f(2). Are the remediation plans effective for correcting the security weakness? Yes/No\n\nWe found that agencies combined unrelated weaknesses into a single POA&M, which lowered\nthe number of outstanding POA&Ms. For example, we found one agency combined eight\nunrelated weaknesses into one POA&M without any of the details required by NIST. 41 This\npractice distorted the remediation tracking process which made it impossible to understand the\ninternal control problem, determine whether it was an issue that affected other parts of the\nenvironment, and conclude if it was being mitigated.\n\nAlso, as noted in 4c above, agencies are not creating all necessary POA&Ms.\n\n4f(3). Are the estimated dates for remediation reasonable and adhered to? Yes/No\n\nAgencies are not creating all necessary POA&Ms and are bundling multiple deficiencies into\nothers. Therefore, the resources required to accomplish the remediation are not defined, the\ntasks needing to be accomplished are not identified, and the milestones and scheduled dates are\nnot documented (see 4c).\n\n\n\n\n41\n NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, Section 2.6, dated\n May 2004, states that \xe2\x80\x9cthe POA&Ms document identifies: (i) the tasks needing to be accomplished; (ii) the resources required\n to accomplish the elements of the plan; (iii) any milestones in meeting the tasks; and (iv) scheduled completion dates for the\n milestones.\xe2\x80\x9d\n\n 19\n\x0c4g. Do program officials and contractors report their progress on security weakness\nremediation to the CIO on a regular basis (at least quarterly)? Yes/No\n\nWhen POA&Ms are properly entered, the OCIO can easily track their progress by using\npredefined queries in CSAM. Unfortunately, as noted in 4c, agencies are not entering\nPOA&Ms.\n\n4h. Does the Agency CIO centrally track, maintain, and independently review/validate\nPOA&M activities on at least a quarterly basis? Yes/No\n\nAccording to OCIO, the only review/validation of POA&M activities covered about 10 percent\nof the POA&Ms closed during fiscal year 2009. As noted in previous questions, the POA&M\nprocess in the Department is not working effectively.\n\nQuestion 5:\nIG Assessment of the Certification and Accreditation Process\n\nProvide a qualitative assessment of the Agency\'s certification and accreditation (C&A)\nprocess, including adherence to existing policy, guidance, and standards. Agencies shall\nfollow NIST Special Publication 800-37, \xe2\x80\x9cGuide for the Security Certification and\nAccreditation of Federal Information Systems\xe2\x80\x9d for C&A work initiated after May 2004.\nThis includes use of the FIPS 199, \xe2\x80\x9cStandards for Security Categorization of Federal\nInformation and Information Systems,\xe2\x80\x9d to determine a system impact level, as well as\nassociated NIST documents used as guidance for completing risk assessments and security\nplans.\n\n5a. Has the Agency developed and documented an adequate policy for establishing a C&A\nprocess that follows the NIST framework? Yes/No\n\nThe Department has issued adequate guidance 42 for agencies to use during the C&A process.\nThe guidance followed the NIST C&A framework.\n\n5b. Is the Agency currently managing and operating a C&A process in compliance with its\npolicies? Yes/No\n\nBased on the OIG reviews performed throughout FY 2009, we found that agencies are not\nfollowing NIST and Departmental 43 guidance when preparing C&A documentation. Agencies\nare required to submit their system C&A packages and all supporting documentation to the\nDepartment for an in-depth review (referred to as a concurrency review). During the\nconcurrency review, the Department ensures that the documentation prepared to support system\naccreditation 44 is complete, accurate, reliable, and that it meets all NIST and other mandated\n\n\n42\n DM 3555-001 Chapter 11, Part 1, Certification and Accreditation Methodology, dated October 18, 2005.\n43\n NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, dated May 2004,\n DM 3555-001, Certification and Accreditation Methodology, dated October 18, 2005.\n44\n Security accreditation is the official management decision given by a senior agency official to authorize operation of an\n information system and to explicitly accept the risk to agency operations, agency assets, or individuals based on the\n implementation of an agreed-upon set of security controls.\n\n 20\n\x0cdocumentation standards. We evaluated seven C&A concurrency reviews where the Department\nhad concurred with the agencies\xe2\x80\x99 recommendations to accredit the system. We found that the\nagencies\xe2\x80\x99 security certification45 documentation did not support accreditation. We determined\nthat agencies had not followed NIST guidance in all seven cases. Specifically, we found that\nthree SSPs, 46 four risk assessments (RA), and seven testing documents 47 did not meet NIST\nrequirements; and two agencies did not select the required controls to test. In addition, when\nreviewing CSAM, we found there were 34 systems with an expired Authority to Operate (ATO)\nor Interim Authority to Operate (IATO). 48 We have reported problems in the C&A process since\n2001, and attribute these continuing problems to a lack of commitment by agencies to a quality\nC&A process, as well as a lack of Departmental oversight. Agencies do not know if required\nsystem controls have been implemented correctly because the controls may not have been\ndocumented and tested. Systems, and the information in those systems, may be at risk if security\ncontrols have not been implemented correctly.\n\n5c. For systems reviewed, does the C&A process adequately provide:\n5c(1). Appropriate risk categories Yes/No\n\nAll seven C&A submissions in our sample had appropriate risk categories (see 5b).\n\n5c(2). Adequate risk assessments Yes/No\n\nFour of the seven RAs we reviewed during our C&A testing did not meet NIST requirements\n(see 5b).\n\n5c(3). Selection of appropriate controls Yes/No\n\nAppropriate controls had not been selected as required by NIST for two of the seven reviewed\nC&As (see 5b).\n\n5c(4). Adequate testing of controls Yes/No\n\nSystem controls had not been adequately tested for four of the seven C&As reviewed (see 5b).\n\n\n\n\n45\n Security certification is a comprehensive assessment of the management, operational, and technical security controls in an\n information system, which are made in support of security accreditation to determine the extent to which the controls are\n implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security\n requirements for the system.\n46\n The SSP is a required C&A document that provides an overview of the security requirements of the system and describes the\n controls in place (or planned) for meeting those requirements. The SSP also delineates responsibilities and expected behavior\n of all individuals who access the system. (NIST SP 800-18, Guide for Developing Security Plans for Federal Information\n Systems, dated February 2006).\n47\n A Security Testing and Evaluation (ST&E) is one phase of the C&A where an independent party evaluates and conducts\n testing of the controls established in and around a system. The purpose is to determine whether controls as stated in the system\n documentation are adequate and operating as prescribed.\n48\n An ATO or IATO is the last step in the C&A process. If C&A is adequate and meets NIST requirements an ATO is given for a\n period of 3 years. If, after assessing the results of the security certification, the agency deems that the risk to agency operations\n is unacceptable but there is an overarching need to place the system into operation or continue its operation, an IATO may be\n issued for up to 6 months in order for the agency to fix the vulnerabilities.\n\n 21\n\x0c5c(5). Regular monitoring of system risks and the adequacy of controls Yes/No\n\nWe found two agencies were not performing continuous monitoring of security controls in\naccordance with NIST 49 guidance. Neither agency had documented the critical system controls\nthat needed to be monitored, the frequency of that monitoring, or the actions to be taken based on\nthe results of the monitoring. In addition, one agency did not effectively perform annual system\nself-assessments or document the results in CSAM as required. The lack of continuous\nmonitoring was attributed to insufficient resources and agency staffs that did not realize the\nimportance of continuous monitoring.\n5d. For systems reviewed, is the Authorizing Official presented with complete and reliable\nC&A information to facilitate an informed system Authorization to Operate decision based\non risks and controls implemented? Yes/No\n\nThe documentation for all seven C&As in our sample do not follow NIST requirements (see 5b).\n\nQuestion 6:\nIG Assessment of Agency Privacy Program and Privacy Impact Assessment (PIA) Process\n\nProvide a qualitative assessment of the Agency\xe2\x80\x99s process, as discussed in the Senior Agency\nOfficial for Privacy (SAOP) section, for protecting privacy-related information, including\nadherence to existing policy, guidance and standards. Provide explanatory information in\nthe area provided.\n6a. Has the Agency developed and documented adequate policies that comply with OMB\nguidance in M-07-16, M-06-15, and M-06-16 for safeguarding privacy-related information?\nYes/No\n\nThe Department has several manuals and regulations that adequately cover the OMB guidance. 50\n\n6b. Is the Agency currently managing and operating a privacy program with appropriate\ncontrols in compliance with its policies? Yes/No\n\nThe Department needs to take additional actions to minimize the risk of unauthorized release of\n\xe2\x80\x9cprivacy data\xe2\x80\x9d as required by OMB guidance. 51 Due to the complexity and age of the legacy\nsystems within USDA, the Department has not fully implemented its plan to reduce the use of\nsocial security numbers (SSN) as identifiers in application databases. OMB requires that the\nDepartment track all sensitive data extracts (i.e., extracts containing SSNs) to ensure the data are\n\n49\n NIST SP 800-53, Revision 2, Recommended Security Controls for Federal Information Systems, dated December 2007,\n requires agencies to \xe2\x80\x9cmonitor and assess selected security controls in the information system on a continuous basis including\n documenting changes to the system, conducting security impact analyses of the associated changes, and reporting the security\n status of the system to appropriate organizational officials on a regular basis.\xe2\x80\x9d\n50\n Departmental Regulation 3505-003, Access Control Policy, dated August 11, 2009; DM 3515-001, Collection of Web Page\n Cookies & Privacy Requirements, dated August 19, 2004; DM 3515-002, Privacy Impact Assessment, dated February 17, 2005;\n DM 3545-001, Computer Security Training and Awareness, dated February 17, 2005; DM 3550-002, Sensitive but Unclassified\n (SBU) Information Protection, dated February 17, 2005.\n51\n OMB Memorandum M-06-15, Safeguarding Personally Identifiable Information, dated May 22, 2006, OMB Memorandum M-\n 06-16, Protection of Sensitive Agency Information, dated June 23, 2006, OMB Memorandum M-07-16, Safeguarding Against\n and Responding to the Breach of Personally Identifiable Information, dated May 22, 2007.\n\n 22\n\x0cerased within 90 days or once they are no longer being used. The Department was not aware of\nthis requirement and had not implemented a policy or plan to address this task. Also, because of\ntechnical issues associated with getting encryption software to run on USDA workstations and\nthe overall size of the Department and the diversity of programs, full disk encryption has only\nbeen implemented on 53 percent of the Department\xe2\x80\x99s laptops. As a result, the potential exists for\nsensitive information to reside on unencrypted computers/devices. 52\n6c. Has the Agency developed and documented an adequate policy for PIA\xe2\x80\x99s? Yes/No\n\nThe Department has issued policy and procedures 53 that adequately addresses privacy impact\nassessments.\n\n6d. Has the Agency fully implemented the policy and is the Agency currently managing\nand operating a process for performing adequate PIA? Yes/No\n\nWe reviewed the Department\xe2\x80\x99s PIA implementation as required by the e-Government Act of\n2002. 54 The Department is required to publish all PIAs on a publicly accessible website. We\nfound that 13 of the required 122 PIAs were missing from the Department\xe2\x80\x99s website.\n\nQuestion 7:\nConfiguration Management\n\n7a. Is there an Agency-wide security configuration policy? Yes/No\n\nNIST 55 states \xe2\x80\x9calthough the solutions to IT security are complex, one simple yet effective tool is\nthe security configuration checklist.\xe2\x80\x9d Both NIST and the Department 56 have issued policies\nrequiring its use when deploying certain software. We found that agencies are not using the\nrequired checklists when deploying the software covered by NIST requirements. Specifically,\nwe scanned systems at two agencies using a commercially available software tool that compares\nimplemented server settings with those required by NIST and Departmental checklists. One\nagency stated it used a checklist, but did not know if it was NIST compliant (we determined that\nit was not). The other agency stated the security configuration checklist settings caused\noperational problems. As a result, it implemented only 69 percent of the settings. The agency\nhad not documented the reasons for not implementing the remaining 31 percent of the settings.\nThe use of security configuration checklists to deploy software and hardware ensures consistency\nacross the agency and ease of maintenance. When USDA agencies do not use and follow the\nchecklists, helpdesk support, inventory management capabilities, and operating costs are\nimpacted due of the lack of standardization.\n\n\n52\n The next step of the Department\xe2\x80\x99s encryption effort will include external storage media. OCIO stated this will begin in the\n next few months.\n53\n DM 3515-002, Privacy Impact Assessment, dated February 17, 2005.\n54\n e-Government Act of 2002, Public Law 107\xe2\x80\x93347, dated December 17, 2002, requires agencies to conduct PIA for new IT\n investments and online information collections. A PIA is a review of how information about individuals is handled within the\n agency when the agency uses IT to collect new information, or when agencies develop or buy new IT systems to handle\n collections of personally identifiable information.\n55\n NIST SP 800-70, Security Configuration Checklists Program for IT Products \xe2\x80\x93 Guidance for Checklists Users and Developers,\n dated May 2005.\n56\n OCIO issued a memorandum, Required Use of Security Configuration Guides, dated March 10, 2009.\n\n 23\n\x0c7a(1). For each Operating System (OS)/platform/system for which your Agency has a\nconfiguration policy, please indicate the status of implementation for that policy.\n\nAlthough the Department has an agency-wide configuration policy, OIG only tested compliance\nwith the Microsoft Windows Server 2003 OS (see question 7a). We are therefore marking all of\nthe below configuration policies 57 as \xe2\x80\x9cadopted agency-wide policy and have started\nimplementation.\xe2\x80\x9d\n\n \xe2\x80\xa2 Microsoft Windows Server 2003\n \xe2\x80\xa2 Microsoft Windows XP\n \xe2\x80\xa2 Cisco IOS\n \xe2\x80\xa2 Redhat Enterprise Linux 4\n \xe2\x80\xa2 Sun Solaris 10\n \xe2\x80\xa2 Microsoft Windows 2000\n \xe2\x80\xa2 IBM AIX 4\n \xe2\x80\xa2 Oracle Database 10g\n \xe2\x80\xa2 Microsoft Exchange 2007 for Windows Server 2003\n \xe2\x80\xa2 Research in Motion Blackberry\n \xe2\x80\xa2 Apple Mac OS X\n\nIn addition, OMB 58 requires agencies with Windows Vista or Windows XP operating systems,\n(or plans to upgrade to these operating systems), to adopt standard security configurations on\nworkstations by February 1, 2008. The standard security configurations have been developed by\nNIST, the Department of Defense, and the Department of Homeland Security and are commonly\nreferred to as the Federal Desktop Core Configuration (FDCC). Because of the complexity of\nthe Department and its many diverse systems, it did not meet the OMB mandated deadline. The\nDepartment issued a memorandum on February 15, 2008, which required agencies to be FDCC\ncompliant by July 31, 2008. As of September 30, 2009, the Department reported only 8 percent\nof machines had deployed 100 percent of the FDCC standard security configuration settings.\nHowever, for those machines without full deployment of the FDCC standard security\nconfiguration settings, the Department reported an average of about 90 percent of the settings\nwere deployed. We have not validated this percentage or the actual settings deployed. As a\nresult, we do not know the extent to which their workstations are properly secured and in\ncompliance with the FDCC.\n\n7b. Indicate the status of the implementation of Federal Desktop Core Configurations\n(FDCC) at your Agency :\n7b(1). Agency has documented deviations from FDCC standard configuration. Yes/No\n\nWe received a listing of documented FDCC standard configuration deviations provided by the\nDepartment. The listing did not include all agencies and was inconsistent with what we found at\n\n57\n This is a list of operating systems for various hardware devices by vendor which is taken from the Cyberscope\n (OMB FISMA Website) drop down menus that correspond to the equivalent published USDA configuration\n guides. USDA has some guides that did not have a corresponding Cyberscope drop down menu.\n58\n OMB Memorandum 07-11, Implementation of Commonly Accepted Security Configurations for Windows\n Operating Systems, dated March 22, 2007.\n 24\n\x0cthe two agencies reviewed. For example, we found 20 security settings were not implemented in\nthe two agencies, while the Department had 14 deviations documented for these agencies.\n\n7b(2). New Federal Acquisition 2008-004 language, which modified \xe2\x80\x9cPart 39-Acquisition of\nInformation Technology,\xe2\x80\x9d is included in all contracts related to common security settings.\nYes/No.\n\nOur review at two agencies found the required language included in procurement contracts.\nHowever, the Department reports that the acquisition language was not found in all contracts.\n\nQuestion 8:\nIncident Reporting\n\n8a. How often does the Agency comply with documented policies and procedures for\nidentifying and reporting incidents internally? Answer will be a percentage range\n\nThe Department has made progress in the required 59 reporting of security incidents 60 to law\nenforcement and the US-Computer Emergency Readiness Team (US-CERT). 61 However, we\nfound that due to the volume of incidents throughout the year, the Department did not always\nfollow its own security review procedures. We reviewed 49 incidents (5 privacy-related) and\nfound only 18 of the 49 incidents (37 percent) were handled in accordance with Departmental\nprocedures, which require that agencies submit documentation to the OCIO and carry out pre-\ndefined steps. The procedures also require that agencies undertake and document a thorough\ninvestigation of the initial cause of the incident. In addition, the procedures require agencies to\n\nsubmit detailed final reports to the OCIO outlining the steps taken to mitigate the cause of the\nincident. We present the details of our findings below:\n\n \xe2\x80\xa2 19 incidents did not have all required documentation;\n \xe2\x80\xa2 16 incidents were reported as closed before the required reviews were completed;\n \xe2\x80\xa2 12 incidents were not adequately investigated;\n \xe2\x80\xa2 12 incidents had incomplete final reports; and\n \xe2\x80\xa2 5 privacy-related incidents were improperly handled.\n\nOCIO officials stated that errors occurred in handling of the incidents due to the volume of the\nreported incidents. We found that OCIO staff and contractor personnel were unclear as to what\nprocedures to follow when security incidents were reported. For example, OCIO and its\ncontractor staff did not always ensure that agencies included the checklists contained in the\n\n59\n Agriculture Security Operations Center Computer Incident Response Team-Standard Operating Procedures for Reporting\n Security and Personally Identifiable Information Incidents, dated June 9, 2009.\n60\n DM 3505-000, USDA Cyber Security Incident Handling Procedures, dated March 20, 2006, states an incident is a violation or\n imminent threat of violation of computer security policies, acceptable use or standard computer security practices. It is also\n any adverse event whereby some aspect of a computer system is compromised, such as loss of data confidentiality, disruption\n of data integrity, or disruption or denial of service.\n61\n US-CERT provides response support and defense against cyber attacks for the Federal Civil Executive Branch (.gov) and\n information sharing and collaboration with State and local Government, industry, and international partners. US-CERT is the\n operational arm of the National Cyber Security Division (NCSD) at the Department of Homeland Security (DHS). The NCSD\n was established by DHS to serve as the Federal Government\xe2\x80\x99s cornerstone for cybersecurity coordination and preparedness.\n\n 25\n\x0cprocedure\xe2\x80\x99s appendix with their incident submissions. When we inquired as to why the\nchecklists were not included, OCIO personnel stated that since checklists were an appendix to\nthe procedures they were not required. The appendix\xe2\x80\x99s checklists were required when an agency\nsubmits an incident.\n\nOMB 62 has mandated that an incident be reported within 1 hour when it may involve privacy\ninformation. The Department included OMB\xe2\x80\x99s mandated timeframe in its procedures for\nhandling privacy incidents. OCIO officials stated that staff did not always follow procedures\nwhen handling privacy incidents because of the unrealistic timeframe mandated by OMB, even\nthough it had included the timeframe in its procedures. This failure to follow policies and\nprocedures may affect the Department\xe2\x80\x99s ability to rapidly detect incidents and the loss of privacy\ninformation. The rapid detection and reporting of incidents is essential for minimizing data loss\nand destruction, mitigating any exploited weaknesses, and restoring computing services.\n8b. How often does the Agency comply with documented policies and procedures for\ntimely reporting of incidents to US-CERT? Answer will be a percentage range.\n\nWe found 41 of the 49 reviewed incidents (84 percent) were timely reported to US-CERT in\naccordance with Departmental policy.\n\n8c. How often does the Agency follow documented policies and procedures for reporting to\nlaw enforcement? Answer will be a percentage range.\n\nWe found all 49 (100 percent) of the reviewed incidents were reported to OIG in accordance\nwith Departmental policies and procedures.\n\n\n\n\n62\n OMB Memorandum 07-16 requires reporting to US-CERT within 1 hour of discovery/detection.\n 26\n\x0cQuestion 9:\nSecurity Awareness Training\n\nProvide an assessment of whether the Agency has provided IT security awareness training\nto all users with log-in privileges, including contractors. Also provide an assessment of\nwhether the Agency has provided appropriate training to employees with significant IT\nsecurity responsibilities.\n9a. Has the Agency developed and documented an adequate policy for identifying all\ngeneral users, contractors, and system owners/employees who have log-in privileges, and\nproviding them with suitable IT security awareness training? Yes/No\n\nThe Department has made significant improvements to ensure that all employees receive security\nawareness training; however, there is no consistent method for tracking security training for\nUSDA contractors. The Department has a database to maintain a record of all contractors within\nthe Department; however, use of the database is not required and only two agencies are using it.\nTherefore, it is difficult for the Department and the agencies to identify contractors, their access\ncontrols, and whether they have received the required training. 63\n\n9b. Report the following for your Agency:\n9b(1). Total number of people with log-in privileges to Agency systems.\n\nThe Department did not provide the total number of people with log-in privileges to USDA\nsystems in a timely manner. On October 8, 2009, OCIO sent out a data call to all USDA\nagencies requesting that they provide this information. Because the last agency responded on\nNovember 6, 2009, we have not had an opportunity to determine the accuracy of the information.\n\n9b(2). Number of people with log-in privileges to Agency systems that received information\nsecurity awareness training during the past fiscal year, as described in NIST Special\nPublication 800-50, "Building an Information Technology Security Awareness and\nTraining Program.\xe2\x80\x9d\n\nThe Department has a total of 110,828 64 employees and an unknown number of contractors. As\nof July 2009, 120,956 employees and contractors had taken the Department\xe2\x80\x99s security awareness\ntraining.\n\n9b(3). Total number of employees with significant information security responsibilities.\n\nThe Department did not provide a list of employees with significant information security\nresponsibilities in a timely manner. On October 8, 2009, OCIO sent out a data call to all USDA\nagencies requesting that they provide this information. The last agency responded on\nNovember 6, 2009. Therefore, we have not had an opportunity to review the accuracy of the\ninformation.\n\n\n63\n FISMA of 2002, Title III Information Security, dated December 17, 2002 and NIST SP 800-53, Revision 2,\n Recommended Security Controls for Federal Information Systems, dated December 2007.\n64\n As of August 24, 2009.\n 27\n\x0c9b(4). Number of employees with significant security responsibilities that received\nspecialized training, as described in NIST Special Publication 800-16, \xe2\x80\x9cInformation\nTechnology Security Training Requirements: A Role- and Performance-Based Model\xe2\x80\x9d\n\nFederal law, NIST, and the Department 65 require all users with significant security\nresponsibilities to receive specialized role-based training in addition to security awareness\ntraining. We were unable to determine whether all employees that should have received the\nadditional role-based training actually received it. Agencies interpreted the definition of\n\xe2\x80\x9csignificant IT security responsibilities\xe2\x80\x9d differently because the Department\xe2\x80\x99s security training\npolicy did not clearly define what \xe2\x80\x9csignificant IT security responsibilities\xe2\x80\x9d encompassed. For\nexample, one agency determined that only the staff working in its security office needed the\ntraining. Another agency interpreted the definition of significant security responsibilities to\napply to all staff with elevated privileges 66 to the agency\xe2\x80\x99s systems. As a result, employees who\nwere actually assigned significant IT security responsibilities did not receive the required\nadditional training.\n\nQuestion 10:\nPeer-to-Peer File Sharing\n\n10. Does the Agency explain policies regarding the use peer-to-peer file sharing in IT\nsecurity awareness training, ethics training, or any other Agency-wide training? Yes/No\n\nDuring fiscal year 2009, the Department issued a policy 67 stating that the use of commercial\npeer-to-peer (P2P) 68 software was prohibited on all USDA equipment and networks without\nexplicit authorization from the OCIO. The policy further stated that agency personnel,\ncontractors, and partners should not download and install commercial P2P software.\nWe determined the P2P file sharing policy was not in the Department\xe2\x80\x99s IT security awareness\ntraining. This occurred because the Department used the Information Systems Security Line of\nBusiness course. This course was designed to meet the NIST requirement for basic awareness\ntraining across the Government, and did not include individual Department/agency policies or\nprocedures. Therefore, the Department can not verify that every employee and contractor has\nbeen trained on the P2P policy.\n\n\n\n\n65\n NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model, April\n 1998; FISMA, and DM 3545-001, Computer Security Training and Awareness, dated February 17, 2005.\n66\n Elevated privileges are those above a normal system user, such as staff that have administrative privileges to servers, databases\n and networks.\n67\n OCIO Memorandum, \xe2\x80\x9cUse of Peer-to-Peer Software Policy,\xe2\x80\x9d dated March 17, 2009.\n68\n P2P is software often used to obtain freeware, shareware, and bootleg software. The use of this software creates vulnerabilities,\n which can be exploited to allow malicious code and other illegal material into the USDA network.\n\n 28\n\x0cAbbreviations\n\nATO Authority to Operate\nC&A certification and accreditation\nCIO Chief Information Officer\nCSAM Cyber Security Assessment and Management\nDHS Department of Homeland Security\nDM Departmental Manual\nERS Economic Research Service\nFDCC Federal Desktop Core Configuration\nFISMA Federal Information Security Management Act\nFNS Food Nutrition Service\nGAO U.S. Government Accountability Office\nGISRA Government Information Security Reform Act\nIATO Interim Authority to Operate\nIG Inspector General\nIT information technology\nNIST National Institute of Standards and Technology\nNITC National Information Technology Center\nNRCS Natural Resources Conservation Service\nOCFO Office of the Chief Financial Officer\nOCIO Office of the Chief Information Officer\nOIG Office of Inspector General\nOMB Office of Management and Budget\nOS Operating System\nP2P Peer to Peer\nPIA Privacy Impact Analysis\nPOA&M Plan of Action and Milestones\nPL Public Law\nRA risk assessment\nSOP Standard Operating Procedure\nSP Special Publication\nSSN Social Security Number\nSSP System Security Plan\nUS-CERT US-Computer Emergency Readiness Team\nUSDA U.S. Department of Agriculture\n\n\n\n\n 29\n\x0cInformational copies of this report have been distributed to:\n XXXXXXXXXXXXXXX (#)\n XXXXXXXXXXXXXXX (#)\n XXXXXXXXXXXXXXX (#)\n\x0c'