Information Security: FDA Needs to Rectify Control Weaknesses That Place Industry and Public Health Data at Risk
Released: 2016-09-29T00:00:00

Letter

Background

Information security is a critical consideration for any agency that depends on information systems and computer networks to carry out its mission and is especially important for a federal agency such as FDA, which collects, processes, and stores sensitive information on drugs and other products pending approval; the safety of food, drug, and medical products; and scientific research to inform regulatory decisions. While the use of interconnected electronic information systems allows the agency to accomplish its mission more quickly and effectively, this also exposes FDA’s information to threats from sources internal and external to the agency. Internal threats can include errors, as well as fraudulent or malevolent acts by employees or contractors working within the agency. External threats include the ever-growing number of cyber-based attacks that can come from a variety of sources, including hackers, criminals, foreign nations, terrorists, and other adversarial groups.

Potential cyber attackers have a variety of techniques at their disposal, which can vastly enhance the reach and impact of their actions. For example, these attackers do not need to be physically close to their targets, their attacks can easily cross state and national borders, and they can more readily preserve their anonymity. Additionally, advanced persistent threats—where an adversary that possesses sophisticated levels of expertise and significant resources can use physical and cyber methods to achieve its objectives—pose increasing risks. Further, the interconnectivity among information systems presents increasing opportunities for such attacks.

This risk is highlighted by the rising number of reported security incidents at federal agencies. Specifically, the number of incidents reported by federal agencies to the United States Computer Emergency Readiness Team (US-CERT) has increased dramatically in recent years. It rose from 5,503 in fiscal year 2006 to 77,183 in fiscal year 2015.

Compounding the growing number and types of threats are the deficiencies in security controls on the information systems at federal agencies. These weaknesses have resulted in vulnerabilities in systems and information and continue to place assets at risk of inadvertent or deliberate misuse; information at risk of unauthorized access, modification, or destruction; and critical operations at risk of disruption.

Accordingly, we have designated federal information security as a government-wide high-risk area since 1997, and in 2003 expanded this area to include computerized systems supporting the nation’s critical infrastructure. In February 2015, we further expanded this area to include protecting the privacy of personal information that is collected, maintained, and shared by both federal and nonfederal entities. In September 2015, we reported that more than half of the 24 major federal agencies continued to experience weakness in the controls intended to preserve confidentiality—preventing unauthorized access to information and systems; integrity—preventing unauthorized modification or destruction of information, including access and configuration controls; and availability—ensuring timely and reliable access to and use of information when needed, such as contingency planning controls.

To improve federal information security, the Federal Information Security Modernization Act (FISMA) was enacted in 2014. The law is intended to address the increasing sophistication of cybersecurity attacks, promote the use of automated security tools with the ability to continuously monitor and diagnose the security posture of federal agencies, and provide for improved oversight of federal agencies’ information security programs. FISMA provides a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support federal operations and assets.

Among other things, FISMA requires federal agencies to develop, document, and implement an agency-wide information security program. Agencies are to carry this out using a risk-based approach to information security management. Such a program includes developing and implementing cost-effective security policies, plans, and procedures; assessing risk; providing specialized training; testing and evaluating the effectiveness of controls; planning, implementing, evaluating, and documenting remedial actions to address information security deficiencies; and ensuring continuity of operations.

FISMA also gives the National Institute of Standards and Technology (NIST) responsibility for developing standards and guidelines that include minimum information security requirements. To this end, NIST has issued numerous publications to provide guidance for agencies in implementing an information security program. These include, among others, the NIST Federal Information Processing Standard (FIPS) 199, which provides requirements for agencies to categorize their systems and information, and NIST Special Publication (SP) 800-53, which provides guidance on the selection and implementation of information security and privacy controls for systems.

FDA Is Responsible for Ensuring the Safety, Effectiveness, and Quality of Food and Medical Products

FDA is a consumer protection agency with broad regulatory authority charged with protecting public health by ensuring the safety, effectiveness, and security of human veterinary drugs, biological products, and medical devices; ensuring the safety of foods, cosmetics, and radiation-emitting products; and regulating tobacco products.

FDA’s mission includes helping to speed innovations that make foods safer and medicines and medical devices safer and more effective; ensuring members of the public have accurate, science-based information they need to use medicines, devices, and foods to improve their health; regulating the manufacture, marketing, and distribution of tobacco products and reducing tobacco use by minors; and addressing the nation’s counterterrorism capability by ensuring the security of the supply of foods and medical products.

FDA performs regulatory activities that include reviewing and approving new drugs and certain medical products; inspecting manufacturing facilities for compliance with regulations and good manufacturing practices; and conducting post-market surveillance of food, drug, and medical products to ensure they are safe; tracking and identifying the source of outbreaks of foodborne illnesses; and issuing recall notices and safety alerts for products that threaten the public health.

According to FDA, its fiscal year 2015 appropriation was $4.5 billion. The agency is headed by a Commissioner and is staffed by more than 14,000 employees across the United States and around the world. FDA consists of its Office of the Commissioner and four directorates that oversee the agency’s core functions. These directorates are the Office of Foods and Veterinary Medicine, Office of Global Regulatory Operations and Policy, Office of Medical Products and Tobacco, and Office of Operations. Within these directorates are offices and centers that focus on core parts of the agency’s mission. Examples of these offices and centers are shown in table 1.

FDA Relies on Computer Systems to Support Its Mission

FDA relies extensively on IT to fulfill its mission and support related administrative needs. Among the more than 80 systems reported in its FISMA inventory, the agency has systems dedicated to supporting its product review and evaluation activities, regulatory compliance functions, and product safety monitoring activities, as well as systems to support administrative processes. All of these systems are supported by an IT infrastructure that includes network components, critical servers, and data centers.

In fiscal year 2015, the agency reported spending $585 million on IT, of which approximately $12 million (or about 2 percent of the IT budget) was for information security. This percentage is lower than the approximately 8 percent of their fiscal year 2015 IT spending that the 23 civilian agencies covered by the Chief Financial Officers Act reportedly spent on information security. For fiscal year 2016, FDA requested $640 million for IT and $16 million for information security. In addition, FDA indicated that real-time connectivity and access to data and information is essential for its daily operations, as well as its interactions with the public and other partners. These factors depend on high-quality, high-availability, and high-performing data networks, server and application infrastructure, communications services, simple and complex computer applications, mobile workforce capabilities, and rapid and responsive service delivery.

Examples of the processing activities that key FDA systems perform in supporting of the agency’s mission are listed below:

Support and facilitate post-market product safety surveillance of human drugs, biologics, devices, and combination products. Provide a data repository for collecting, storing, viewing, analyzing, reporting, and tracking the receipt of adverse event data or medication errors.

Establish a single gateway or communications portal for accepting electronic submissions or allowing authorized users to view or obtain information. Examples of electronic submissions include industry- provided trade secrets, adverse event records, and a multitude of different records related to FDA’s regulatory oversight of regulated products.

Provide capabilities for regulatory scientific research, while also supporting FDA’s overall goals and objectives in areas where information technology requires supercomputer-strength computational power.

Support FDA’s research and development activities.

Provide a platform through which FDA organizations may disseminate FDA-related information to interested parties, including the public, health professionals, regulated industries, and the media. Provide information about the various product areas that FDA regulates (food, drugs, medical devices, cosmetics, etc.), timely advisories (e.g., anticipated disease outbreaks such as the Severe Acute Respiratory Syndrome (SARS), buying medicines online, and LASIK surgery), and other FDA activities. Provide links to related reference materials and opportunities for consumers and industry to interact with the FDA.

Provide basic network and security capabilities for the FDA enterprise.

Facilitate receipt and review of electronic drug applications. This function includes scans and checks of the validity of drug submissions from industry and making them available for reviewers, as well as providing file shares for storing successful submissions that are to be reviewed.

In addition, FDA contractors support data centers and systems that provide, among other things, the network infrastructure for the agency’s systems and its public website. The information handled by these systems includes sensitive or confidential business information on drug submissions and adverse event reports, among other types of information.

Accordingly, effective implementation of security controls is necessary to protecting the confidentiality, integrity, and availability of FDA’s information and in preventing the occurrence or lowering the risks of security breaches similar to one the agency experienced in 2013. During that breach, an intruder gained unauthorized access to one FDA system’s user accounts and passwords. Effective controls can help ensure only authorized users (people and processes) access information and systems to lessen the chances of unauthorized disclosures of information, improper changes or modifications to FDA’s information and systems, and system disruptions that could hamper the agency’s ability to perform its mission.

To improve the management of FDA’s information systems security and operations, the agency, in fiscal year 2015, consolidated its network and security operations centers to reorganize the Systems Management Center (SMC). According to FDA, the SMC is the central command and control center and is intended to help establish real-time network awareness to forecast, detect, alert, and report events such as security incidents and facilitate the coordination requirements of its Office of Information Management and Technology. In addition, the agency reported that it established a cybersecurity task force to address short- and long-term concerns with protecting its network boundaries.

Information Security Responsibilities at FDA

Under FISMA, the Commissioner of FDA is responsible for ensuring the confidentiality, integrity, and availability of the information and systems that support the agency and its operations. FISMA also requires that the agency head delegate to the chief information officer (CIO) the overall responsibility for management of the agency’s IT security program. At FDA, the CIO is responsible for evaluating the overall mission requirements for an IT system or application and ensuring that it complies with FDA IT security policies, guidelines, and standards. The CIO is also responsible for, among other things, ensuring effective implementation of FDA’s IT Security Policy; formally appointing a Chief Information Security Officer (CISO) and ensuring that individual complies with FDA’s IT security regulations and guidelines; ensuring that IT security is included in management planning, programming budgets, and the IT capital planning process; and ensuring that annual security reviews are conducted to include annual review and update of security policies and reporting of IT systems to the Office of Management and Budget (OMB).

In addition, FDA’s IT Security Program is headed by the agency’s CISO, who is responsible for ensuring that adequate and appropriate controls are applied to FDA systems for the protection of privacy, and to ensure confidentiality, integrity, and availability, of information. The CISO is to employ security policies and standards for FDA information systems enterprise-wide in accordance with FDA, HHS, OMB, NIST, and other federal security requirements. The CISO also provides guidance on IT system security matters to the Information Systems Security Officers (ISSO) in the center/office they support.

At FDA, ISSOs are responsible for ensuring the implementation of adequate system security for each system supporting a particular center or office. Every center or office system is to have an ISSO assigned as the point of contact for security. Among other things, FDA ISSOs’ responsibilities include (1) ensuring that FDA systems are operated, used, maintained, and disposed of in accordance with FDA’s security policies and procedures; (2) ensuring system security plans are completed and maintained; (3) assisting with system authorization; (4) responding to and reporting security incidents; (5) promoting security awareness; and (6) ensuring media handling procedures are followed.

Security Weaknesses Place Seven FDA Systems and Sensitive Data at Risk

FDA has taken steps to safeguard its systems that receive, process, and maintain sensitive data by, for example, implementing policies and procedures for controlling access to and securely configuring those systems. However, a significant number of weaknesses remain in technical controls—including access controls, change controls, and patch management—that jeopardize the confidentiality, integrity, and availability of its systems. An underlying reason for these weaknesses is that FDA had not yet fully implemented an agency-wide information security program to provide reasonable assurance that controls were operating effectively. These shortcomings put FDA systems at increased and unnecessary risk of unauthorized access, use, or modification that could disrupt its operations. To its credit, FDA, during the course of our work, immediately resolved some of the weaknesses identified and provided information on its proposed actions to address the underlying weaknesses in controls.

FDA Did Not Fully Implement Access Controls

Access controls are designed and implemented to provide reasonable assurance that an agency’s computerized information is reliable. Both logical and physical access controls are intended to prevent, limit, and detect unauthorized access to computing resources, programs, information, and facilities. Access controls include those related to (1) protection of system boundaries, (2) identification and authentication of users, (3) authorization of access permissions, (4) encryption of sensitive information, (5) audit and monitoring of system activity, and (6) physical security of facilities.

As shown in table 2, weaknesses existed in each of these areas for the systems we reviewed. In a separate report with limited distribution, we describe these weaknesses in more detail, along with associated recommendations.

Inadequate design or implementation of access controls increases the risk of unauthorized disclosure, modification, and destruction of sensitive information and disruption of service.

FDA Did Not Always Adequately Protect Its Network Boundaries

Boundary protection controls logical connectivity into and out of networks and controls connectivity to and from devices connected to the network. For example, multiple firewalls can be deployed to prevent both outsiders and trusted insiders from gaining unauthorized access to systems, and intrusion detection technologies can be deployed to defend against attacks from the Internet. Unnecessary connectivity to an organization’s network increases not only the number of access paths that must be managed and the complexity of the task, but also the risk of unauthorized access in a shared environment.

NIST recommends that agencies implement subnetworks to separate publicly accessible system components from their internal networks. NIST also states that agencies should provide adequate protection for networks and employ information control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within information systems. Similarly, NIST recommends that organizations monitor and control communications at information systems’ external boundaries and at key internal boundaries within a system.

FDA did not always adequately ensure that its network boundaries were sufficiently segregated. For example, the contractor supporting the agency’s public-facing website did not isolate the agency’s network from its own network and that of its other customers, which included non-FDA customers. In addition, the contractor did not configure firewall rules to restrict access into FDA’s internal network.

In another example, FDA did not sufficiently restrict inbound connections from one of its untrusted networks and isolate that network from its internal network. The network was untrusted because the agency had not developed and implemented risk management controls for the system. As a result, it poses increased risks to other agency systems.

Further, as illustrated in the following examples, FDA did not always implement other boundary controls.

Network devices at the agency’s field locations were not properly configured and allowed all remote access protocols, such as the unsecure telnet protocol.

Routers at certain international locations were not configured to restrict inbound management traffic from untrusted sites.

Host-based firewalls for four key systems and some workstations were not effectively configured to permit only necessary traffic and provide protection from malicious activity.

As a result, sensitive public health, proprietary business, and personal information maintained by the agency were at increased risk of compromise due to inadequate separation of the service provider’s network from FDA’s network, inadequate separation of the untrusted network from the agency’s network, and weaknesses in other boundary controls.

FDA Did Not Always Implement Controls for Identifying and Authenticating System Users

A computer system must be able to identify and authenticate different users so that activities on the system can be linked to a specific individual. When an organization assigns a unique user account to a specific user, the system is able to distinguish that user from another—a process called identification. The system must also establish the validity of a user’s claimed identity by requesting some kind of information, such as a password, that is known only by the user—a process known as authentication. The combination of identification and authentication—such as a user account/password combination—provides the basis for establishing individual accountability and for controlling access to the system.

NIST SP 800-53 recommends that password management controls should be established for information systems that include minimum password complexity requirements, password lifetime restrictions, prohibitions on password reuse, and user accounts to be temporarily locked out after a certain number of failed login attempts during a specified period of time. Further, FDA password policy outlines requirements consistent with this guidance.

NIST also states that agencies can satisfy certain identification and authentication requirements by complying with the requirements in Homeland Security Presidential Directive 12 and using multifactor authentication such as personal identity verification cards. Multifactor authentication requires the use of two or more different factors to achieve authentication. The factors are defined as something you know (e.g., a password or a personal identification number); something you have (e.g., cryptographic identification device or token); or something you are (e.g., biometric).

FDA implemented personal identity verification cards for multifactor authentication; however, the agency did not always implement strong password controls in accordance with its security policies and NIST guidance on five of the seven systems we reviewed. For example, three local accounts on a database server which contained certificates used to encrypt industry partner submission packages had passwords that had not been changed in more than 5 years. In addition, several service accounts for servers with access to sensitive industry partner regulatory submissions had passwords set to never expire. Further, a Windows administrator’s non-privileged account was unnecessarily elevated to a privileged account by being part of an administrators group. These accounts are used to administer users’ logical access inside FDA mission-critical systems that process confidential business information or trade secrets such as that for drug submissions and adverse event reporting. In another example, the password to a service account for synchronizing user passwords was set to never expire and had not been changed in the last 6 years.

In addition, FDA did not always implement password controls on certain network devices. For example, password management settings were set to default values on two network devices that delivered web applications to FDA users. These default settings were for local accounts, including web administrator and root accounts, and included minimum password lengths set to six characters, with no requirements for password complexity, maximum password lifetime days, password history, and invalid attempts. In another example, a user account password for a network management server that monitors and maintains a history of network devices’ hardware and software changes had not been changed since January 6, 2011. Without implementing strong password requirements, increased risk exists that passwords could be guessed, permitting unauthorized access to FDA systems.

FDA Users Had More Access to Information than Necessary for Official Duties

Authorization is the process of granting or denying access rights and permissions to a protected resource, such as a network, a system, an application, a function, or a file. For example, operating systems have built-in authorization features such as permissions for files and folders. Network devices, such as routers, have access control lists that can be used to authorize a user who can access and perform certain actions on the device. A key component of granting or denying access rights is the concept of “least privilege.” Least privilege is a basic principle for securing computer resources and information. This principle means that a user is granted only those access rights and permissions needed to perform official duties. To improve authorization controls, the Federal CIO instructed agencies, as part of the Cybersecurity Sprint, to tighten policies and practices of privileged users. These steps included, for example, minimizing the number of privileged users and limiting functions that can be performed when using privileged accounts. To avoid unintentionally authorizing user access to sensitive files and directories, an agency must give careful consideration to its assignment of rights and permissions.

NIST Special Publication 800-53 recommends that agencies should grant user accounts only those privileges required for the users to perform their job functions. Additionally, FDA policy states that access to sensitive information must be restricted and based on the concept of need-to-know.

Although FDA has developed and documented access control requirements based on least privilege and need-to-know principles, users were granted excessive permissions that were not needed for their official duties. These permissions enabled administrators and users who did not need such permissions with the authority to read, and in some cases, write and modify submissions that could contain sensitive or confidential business information on drug submissions or adverse event reporting, as illustrated below.

Forty-nine administrators and users with access to 392 production servers had, by default, unnecessary access to file shares containing industry submissions on adverse events.

A group account allowed 753 users unneeded access to adverse event data submissions.

Ninety-two desktop users, via a group account, had unauthenticated access to one key system’s file shares.

4,534 users, which included regulatory reviewers and project managers, had uncontrolled “read access” to file shares on the system that handles sensitive regulatory drug and biologic product submissions.

According to FDA, the high number of users with access was necessary due to the high volume of regulatory submissions reviewed daily, which regularly exceeds 1,500 per day, and because staff must often access multiple sponsor submissions in order to complete their regulatory review in a timely manner.

However, for the data we reviewed, only about 2,400 users per month accessed these files, compared with the 4,534 users who were granted access. Moreover, FDA did not restrict access to privileged users groups by, for example, differentiating high-valued submission assets from low- valued ones, even though the system stored highly sensitive industry trade secret information.

In addition, for this same system, FDA allowed 39 users in the administration group and 104 users in the staff group to have read, write, and modify privileges to the submission files. The server can be accessed without a user interface and FDA does not have visibility of users’ access to the submission files on the server.

As a result, FDA was at increased risk that users could inadvertently or deliberately modify these files and jeopardize the integrity of the submitted information.

FDA Did Not Always Encrypt Certain Sensitive Data

Cryptography underlies many of the mechanisms used to enforce the confidentiality and integrity of critical and sensitive information. Cryptographic tools help control access to information by making it unintelligible to unauthorized users and by protecting the integrity of transmitted or stored information. A basic element of cryptography is encryption. Encryption is the conversion of data into a form, called a cipher text, which cannot be easily understood. Encryption can be used to provide basic data confidentiality and integrity by transforming plain text into cipher text using a special value known as a key and a mathematical process known as an algorithm. NIST SP 800-53 states that agencies should use encryption to protect the confidentiality of remote access sessions and they should encrypt sessions between host systems. The NIST standard for an encryption algorithm is Federal Information Processing Standard (FIPS) 140-2.

FDA did not always ensure that sensitive data were effectively encrypted when transmitted or stored. For example, 59 network devices we reviewed had weak non-FIPS-compliant algorithms to encrypt user passwords. In addition, a web server supporting the receipt of industry submissions and a database server storing certificates to support secure connections for receiving submissions used non-FIPS-compliant algorithms to encrypt passwords. Furthermore, the web server’s password file was encrypted by an algorithm that was outdated and had been withdrawn by NIST over 10 years ago.

As a result of using weak encryption algorithms, FDA is at increased risk that user passwords may be easier to crack and used by unauthorized individuals to gain access to systems and sensitive information.

FDA Did Not Always Audit and Monitor Activity on Its Systems

To establish individual accountability, monitor compliance with security policies, and investigate security violations, agencies need to determine what, when, and by whom specific actions have been taken on a system. Agencies can accomplish this by implementing system or security software that provides an audit trail (a log of system activity) that is used to determine the source of a transaction or attempted transaction and to monitor a user’s activities. Audit and monitoring, key components of risk management, involve the regular collection, review, and analysis of auditable events for indications of inappropriate or unusual activity, and the appropriate investigation and reporting of such activity.

Audit and monitoring controls can help security professionals routinely assess computer security, perform investigations during and after an attack, and even recognize an ongoing attack. Audit and monitoring technologies include network- and host-based intrusion detection systems, audit logging, security event correlation tools, and computer forensics. NIST guidelines state that agencies should retain sufficient audit logs to allow monitoring of key activities, provide support for after- the-fact investigation of security incidents, and meet agency information retention requirements.

FDA did not always implement and integrate auditing and monitoring for the seven systems we reviewed. For example, the agency did not have network monitoring visibility across its entire network. Specifically, it did not monitor IT assets used by a contractor supporting the system that provides the agency’s Internet and public network. In addition, the agency did not always audit or monitor system activity on IT assets for networks supporting scientific research and high-performance computing.

The agency also did not always retain audit logs to allow monitoring of key activities and provide support for after-the-fact investigation of security incidents. To illustrate, databases supporting drug submissions and adverse event reporting did not have logging enabled for monitoring the use of special system privileges such as alter, create, and grant.

Further, FDA did not retain all records of evidence related to a 2013 security breach from an external attack on an FDA Internet application that allowed the attacker to gain access to a backend database and exfiltrate sensitive users account information. Specifically, it did not retain digital forensics data related to the attack commands and the review of dates and times of files and database entries relevant to data exfiltration of users’ account data. Such information could be useful in better understanding what occurred and in preventing future occurrences.

As a result, FDA did not have information necessary for monitoring key database activities and supporting after-the-fact investigations of security incidents. In addition, the lack of evidence could prevent the agency from determining what events occurred within its systems and networks, such as lateral movements by an attacker that may occur from initial entry into a network to network discovery, hosts targeting, and data exfiltration activities to external systems.

FDA Did Not Update Physical Security Policies or Conduct Reviews of Facilities

Physical security controls restrict physical access to computer resources and protect them from intentional or unintentional loss or impairment. Adequate physical security controls over computer resources (e.g., computer facilities, network devices such as routers and firewalls, telecommunications equipment, and transmission lines) should be established that are commensurate with the risks of physical damage or access. NIST SP 800-53 recommends that agencies review and update the current physical and environmental protection policy at an organization-defined frequency and conduct an assessment of risks, including the likelihood and magnitude of harm, to the information system and information it processes, stores, or transmits.

Consistent with federal guidance, FDA’s Information System Security and Privacy Guide states that physical and environmental protection policies are to be reviewed and updated every 3 years. In addition, the agency’s policies for its facilities state that annual physical security reviews are to be conducted. These reviews are to include, among other things, reviewing security measures in effect to compensate for any noncompliance with requirements, and corrective actions initiated or planned to eliminate deficient conditions.

While FDA developed and documented physical security policies for its facilities, they had not been reviewed and updated for about 14 years. For example, the physical security policy for its headquarters facilities was dated February 2001, and the physical security policy for field activities was dated October 2000. Neither of these policies had been reviewed and updated since they were established, even though the agency’s policy requires this to occur every 3 years. In addition, the agency had not conducted required annual physical security reviews of three of its data center facilities. FDA only provided documentation to support that it had reviewed one of them, which occurred in July 2013 and was not within the annual requirement.

According to FDA’s CISO and a policy analyst, gaps in reviewing and updating policies and procedures were due to personnel resource constraints and a lack of a streamlined process to review policy and procedures at the agency. As a result, FDA has diminished assurance that its computing resources are protected from inadvertent or deliberate misuse or damage.

FDA Conducted Background Investigations, but Weaknesses in Other Controls Increased Risk

In addition to access controls, other important controls should be in place to provide reasonable assurance that the confidentiality, integrity, and availability of an agency’s information is protected. These controls include policies, procedures, and techniques for (1) implementing personnel security, such as background investigations, (2) managing and implementing system configurations, (3) effectively planning for system contingencies, and (4) developing and implementing procedures for disposing of media containing sensitive information. While FDA conducted background investigations according to its policy, weaknesses in other controls increased the risk of unauthorized use, disclosure, modification, or loss of the FDA’s mission-sensitive information.

FDA Conducted Background Investigations for the Personnel Reviewed

The greatest harm or disruption to a system can often come from the actions, both intentional and unintentional, of individuals. These intentional and unintentional actions can be reduced through the implementation of security controls over personnel. Background checks should be done prior to an individual’s authorization to access information systems, and personnel in sensitive positions should be periodically rescreened. Furthermore, FDA policy requires positions to be designated by sensitivity and risk level, and describes requirements for conducting background investigations for employees and contractors, including periodic reinvestigations of individuals in positions of higher risk or sensitivity.

FDA conducted background investigations for the employees and contractors we reviewed. Specifically, each of the 14 employees and contractors we selected had up-to-date background investigations that were consistent with the risk designation of their positions. As a result, FDA reduced its risk that it has employed or contracted for individuals with unsuitable backgrounds for accessing its systems.

FDA Did Not Always Implement Controls for Configuration Management

Configuration management is an important control that involves the identification and management of security features for all hardware and software components of an information system at a given point and systematically controls changes to that configuration during the system’s life cycle. Configuration management involves, among other things, (1) verifying the correctness of the security settings in the operating systems, applications, or computing and network devices and (2) obtaining reasonable assurance that systems are configured and operating securely and as intended. In addition, establishing controls over the modification of information system components and related documentation helps to prevent unauthorized changes and ensure that only authorized systems and related program modifications are implemented. This is accomplished by instituting policies, procedures, and techniques that help make sure that all hardware, software, and firmware programs and program modifications have been properly authorized, tested, and approved.

According to NIST SP 800-53, configuration management activities should include documenting approved configuration-controlled changes to information systems, retaining and reviewing records of the changes, auditing those records, and coordinating and providing oversight for configuration change control activities through a mechanism such as a change control board. Patch management, a component of configuration management, is important for mitigating the risks associated with known software vulnerabilities. When a software vulnerability is discovered, the software vendor may develop and distribute a patch or work-around to mitigate the vulnerability. Without the patch, an attacker can exploit the vulnerability to read, modify, or delete sensitive information; disrupt operations; or launch attacks against other systems. Outdated and unsupported software is more vulnerable to attack and exploitation because vendors may no longer provide updates, including security updates, to correct software flaws.

FDA has developed, documented, and established policies and procedures to manage configuration changes. In addition, for the systems we reviewed, FDA officials demonstrated that system changes were first requested, tracked, and approved at the system level prior to being forwarded via an automated tool to FDA’s change control board as required by policy. However, FDA officials could not provide documentation to demonstrate that emergency changes to software code to remediate security vulnerabilities were tested, validated, and documented in response to the 2013 breach of its Internet-facing web application. Further, the agency did not always implement secure configuration settings for its systems. For example:

FDA did not appropriately configure 336 devices, which could prevent proper identity enforcement of these network devices and could allow unauthorized access to other networks and devices.

FDA used out-of-date and unsupported software on servers storing sensitive data on industry partner regulatory submissions for several of the systems we reviewed. In addition, Windows file share servers and other application servers on several systems we reviewed were out of date and had reached end-of-life, in some cases for more than 4 years past the support date.

Two firewalls for managing contractors’ access to FDA’s network had operating system versions that were close to end-of-life for support, and FDA had no mitigation plans in place to manage this risk.

Similarly, FDA has developed, documented, and established a policy for managing patches that includes time frames for applying patches based on risk, and emergency and out-of-cycle patches within 48 hours of discovery. However, FDA did not always document emergency changes to software code on an application that supported its Internet services. These changes were made in response to an external Internet attack that resulted in a breach of the system’s user account data.

In addition, software security updates and patches were not always installed to address known security vulnerabilities, nor were they timely. For example:

FDA had not applied security updates and patches for network devices, switches, firewalls, specialized network devices, and servers, as well as contractor-operated network devices, in accordance with NIST’s Common Vulnerability Scoring System (CVSS) guidelines for patching devices. CVSS prescribes that patches be installed within 30 days for critical or high-risk vulnerabilities, 60 days for moderate-risk vulnerabilities, and 90 days for low-risk vulnerabilities. FDA’s policy also requires that they follow these patching time frames. However, hundreds of these devices had not been updated with the latest patches in over 3 years.

The agency had not patched 25 servers supporting its infrastructure.

For example, one sever had not been patched for 6 months, from February to August of 2015.

FDA had not applied critical security patches to 74 of 82 host virtual servers supporting its infrastructure. In some cases these patches contained major updates to fix multiple security vulnerabilities.

Various file share servers for three FDA systems we reviewed had not been patched since 2009.

Without proper implementation of configuration management policies and procedures and adequate security controls, FDA systems are susceptible to many known vulnerabilities.

FDA Did Not Always Plan for Contingencies

Losing the capability to process, retrieve, and protect electronically maintained information can significantly affect an agency’s ability to accomplish its mission. If contingency planning is inadequate, even relatively minor interruptions can result in lost or incorrectly processed data, which can cause financial losses, expensive recovery efforts, and inaccurate or incomplete information. Contingency planning consists of interim measures to recover information system services after a disruption. Interim measures may include relocation of information systems and operations to an alternate site, recovery of information system functions using alternate equipment, or performance of information system functions using manual methods.

NIST SP 800-53 recommends that agencies establish a contingency planning policy in the event of unplanned disruptions and provide contingency training and exercises at an agency-defined frequency, among other things. In addition, NIST SP 800-34 recommends that a test plan should be designed and tested to examine applicable contingency planning elements such as notification procedures and system recovery on an alternate platform from backup media to validate the contingency capability. Further, FDA policy also requires functional testing of its contingency plans annually.

Consistent with NIST guidelines, FDA’s Information System Security and Privacy Guide states that contingency planning policies are to be updated every 3 years, while information system contingency plans are to be reviewed annually. FDA’s policy also requires that contingency plans be tested on an annual basis.

However, FDA did not follow its own requirements for updating and reviewing contingency policy and plans. For example, FDA’s contingency planning policy was established in 2007 but was still marked as a draft document and had yet to be reviewed and updated. Further, FDA did not review, at least annually, the contingency plans for six of the seven applications and general support systems that we reviewed during fiscal year 2015 and had not developed and documented a contingency plan for the seventh system.

In addition, FDA did not adequately test five of the six contingency plans we reviewed. For example:

For two major applications, FDA conducted procedures to mitigate system disruptions and documented those activities as tests. However, the actions performed to mitigate disruptions were not based on planned tests.

A planned migration was conducted for a general support system to transfer operations to a facility. However, this migration was not the result of a planned contingency test.

The plans for two general support systems had not been tested since 2013. However, the tests did appropriately assess elements such as notification procedures, and system recovery.

FDA staff attributed these weaknesses to the lack of a streamlined process for reviewing policies and procedures, and personnel resource constraints such as the lack of contracted staff to support FDA contingency planning and operations during an organizational transition.

By not finalizing its contingency planning policy and not annually reviewing and testing contingency plans, FDA has reduced assurance that it has implemented controls necessary for effectively continuing operations in the event of a disruption.

FDA Had Not Developed and Implemented Media Sanitization Procedures

The destruction of media and its disposal are key to ensuring the confidentiality of information. Media can include magnetic tapes, optical disks (such as compact disks), and hard drives. Agencies safeguard used media to ensure that the information they contain is appropriately controlled or disposed of. Media that is improperly disposed of can lead to the inappropriate or inadvertent disclosure of an agency’s sensitive information or the personally identifiable information of its employees and customers.

NIST SP 800-53 recommends that agencies sanitize media prior to disposal and employ sanitization mechanisms to ensure information cannot be retrieved or reconstructed. FDA’s policy for sanitizing computer-related storage media, including server backup tapes, states that techniques used to sanitize media can include degaussing, among other things.

However, FDA did not sanitize media backup tapes that were being stockpiled for disposal. Specifically, for two data center locations, media tapes were stored outside of servers and scheduled for sanitization, but had yet to be sanitized and disposed of. At one of the two data centers, we observed a number of older tapes, and FDA staff said these tapes were awaiting disposal. Specifically, staff mentioned that the legacy tapes held data from operations in prior location and were in a “holding pattern” and tentatively scheduled for decommission. Similarly, FDA staff from the second data center acknowledged that approximately 900 tapes were also awaiting disposal and that these tapes contained older servers, databases, and files resulting from a migration to updated servers tapes.

According to the data center staff, the agency had not developed, documented, and implemented a procedure for sanitizing media, but planned to have a solution by October 2016. Until FDA fully implements a process for media sanitization, the agency is at an increased risk that its sensitive information may not be adequately protected.

FDA Did Not Fully Implement Its Information Security Program, Limiting the Effectiveness of Information Security Controls

A key reason for the weaknesses in controls over FDA’s information and information systems is that it has not yet fully implemented its agency- wide information security program to ensure that controls are effectively established and maintained. If an agency does not fully implement its program, security controls may be inadequate or inconsistently applied; responsibilities may be unclear, misunderstood, or improperly implemented; and organizational and system risks may not be assessed and monitored properly. FISMA requires each agency to develop, document, and implement an information security program that, among other things, includes a periodic assessment of risk and magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of information or information systems; policies and procedures that (1) are based on risk assessments, (2) cost-effectively reduce information security risks to an acceptable level, (3) ensure that information security is addressed throughout the life cycle of each system, and (4) ensure compliance with applicable requirements; subordinate plans for providing adequate information security for networks, facilities, and systems or a group of information systems, as appropriate; security awareness training to inform personnel of information security risks and of their responsibilities in complying with agency policies and procedures, as well as training personnel with significant security responsibilities for information security; periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices, to be performed with a frequency depending on risk, but no less than annually, and that includes testing of management, operational, and technical controls for every system identified in the agency’s required inventory of major information systems; a process for planning, implementing, evaluating, and documenting remedial actions to address any deficiencies in information security policies, procedures, or practices; and procedures for detecting, reporting, and responding to security incidents.

FDA has taken steps to implement an information security program and manage information security risks for its major applications and general support systems. However, key components of its information security program have not been fully or consistently implemented.

FDA Has Taken Steps to Assess Risks, but Some Practices Have Not Been Fully Implemented.

According to NIST SP 800-30, risk is determined by identifying potential threats to the organization and vulnerabilities in its systems, determining the likelihood that a particular threat may exploit vulnerabilities, and assessing the resulting impact on the organization’s mission, including the effect on sensitive and critical systems and data. Identifying and assessing information security risks are essential to determining what controls are required. Moreover, by increasing awareness of risks, these assessments can generate support for the policies and controls that are adopted in order to help ensure that the policies and controls operate as intended.

FDA policy requires that risk assessment results for its systems be reviewed annually, and risk assessments be updated prior to issuing a new authority to operate, whenever there are significant system changes, or every 3 years. FDA’s assessment of risk is conducted as part of its security assessments.

Although FDA assessed risk for six of the seven systems we reviewed, it did not document the likelihood that a particular threat could exploit system vulnerabilities. For example, FDA only identified information system control weaknesses and vulnerabilities for six of the reviewed systems, but did not determine the likelihood and impact of threats to those systems. For the seventh system, FDA did not assess risk or issue a formal authority to operate. Finally, two of the six risk assessments had not been reviewed annually.

During the course of our work, FDA completed the annual review of the risk assessment for one of the two systems, and we have verified this action. However, until FDA completes comprehensive risk assessments and reviews them annually, the agency will have less assurance that it has identified the necessary controls to protect its assets.

Policies and Procedures Were Not Always Complete or Had Not Been Reviewed in a Timely Manner

A key element of an effective information security program is to develop, document, and implement risk-based policies, procedures, and technical standards that govern the security over an agency’s computing environment. Information security policy is essential to establishing roles, responsibilities, and requirements necessary for implementing an information security program. The supporting procedures provide the information and guidance on implementing the policies. According to NIST, an agency should develop policies and procedures for each of the NIST families of security controls to facilitate the implementation of the controls. Additionally, HHS and FDA policy require that policies be reviewed every 3 years to ensure that they are sufficient and consistent with federal requirements.

FDA generally took steps to develop and document policies and procedures for its information security program, but did not always document them or ensure procedures were complete. For example, while the agency has developed policies to cover 17 of 18 NIST control families, it did not develop one for system maintenance. In addition, the agency did not develop or document procedures for implementing controls in 8 of the 18 control families. The 8 control families were Audit and Accountability, Identification and Authentication, Maintenance, Media Protection, Physical and Environmental Protection, Security Planning, Systems Communication and Protection, and System Information and Integrity. Of the procedures for 10 control families that FDA provided, 3 were complete. However, procedures for 7 families were incomplete and did not include steps suggested by NIST. For example, procedures for security awareness and training did not include procedures for covering role-based training, and those for assessment and authorization did not address continuous monitoring as recommended by NIST.

Further, FDA did not review its policies according to its own requirements. Specifically, 11 of 18 NIST-recommended policies were not reviewed within the agency-defined frequency of 3 years. For example, the agency’s personnel security policy was last reviewed in 1986. Policies for other controls such as those for access controls, identification and authentication, and incident response had not been reviewed in at least 7 years. FDA conducted an internal review in 2013 to identify the policies that needed to be reviewed and updated, and had established a plan of actions and milestones for updating them by November 2013. However, the agency did not meet its own deadline for reviewing and updating 11 of the 17 policies it had developed. According to FDA staff, the policies had not been reviewed and updated because the process had been too cumbersome and required a sign-off from a number of stakeholders. FDA’s CISO also stated that they had been understaffed, which led to a large backlog of policies to be reviewed.

Having incomplete policies and procedures or not reviewing them reduces FDA’s assurance that roles and responsibilities have been clearly assigned and understood and that personnel have the information needed to implement its policies, which could lessen the agency’s ability to efficiently and effectively protect its information systems.

FDA Developed System Security Plans for Six of Seven Reviewed Systems, but They Were Incomplete and Not Annually Reviewed

FISMA requires that agencies develop and document system security plans for all major federal information systems. This requirement should be viewed as an essential part of planning adequate, cost-effective security protection for a system. According to NIST, system security plans should provide an overview of the security requirements of the system, and document and describe the security controls and security control enhancements in place or planned for meeting those requirements. NIST also recommends that the plans be reviewed and approved by authorizing officials or designated representatives. NIST states that plans should be reviewed and updated at least annually to ensure that they continue to reflect the correct information about the system such as changes in system owners, interconnections, and authorization status, among other things. Consistent with NIST, HHS and FDA policy require FDA to review system security plans annually.

FDA created security plans and generally documented controls for six of the seven applications and general support systems we reviewed. However, the agency did not always ensure that the plans were complete, or that plans were reviewed. For example, FDA did not always fully describe the extent to which controls were implemented for each of the six system security plans we examined. Specifically, it did not document 76 of 83 NIST-required high-impact control enhancements in the security plan for the high-impact system used in reporting adverse events. In addition, the agency did not document the control descriptions for 171 of 262 security controls and control enhancements; specifically, the description of the implementation of 171 security controls and enhancements was left blank in the plan for the system supporting FDA’s infrastructure. The system has an important role in securing the agency’s other systems since 68 of those systems inherit their controls from it. FDA also did not demonstrate that any of the six plans we reviewed were approved or reviewed by authorizing or senior agency officials.

According to an information system security officer, these shortfalls were related to deficiencies in their security management tool and a lack of resources. Officials stated that the tool that they used for entering information into system security plans had software flaws, which did not allow them to properly capture system security plan control descriptions; officials stated that they plan to replace the tool but could not give a firm timeline.

Until FDA develops and documents a plan for one system supporting its research and updates system security plans to reflect current federal control requirements, the agency lacks assurance that the appropriate controls have been identified for the seven systems we reviewed and increases the likelihood that the controls will not be fully implemented.

FDA Provided Security Awareness Training but Did Not Always Track and Fully Train Users with Significant Security Responsibilities

According to FISMA, an agency-wide information security program must include security awareness training for agency personnel, contractors, and other users of information systems that support the agency’s operations and assets. This training must cover (1) information security risks associated with users’ activities and (2) users’ responsibilities in complying with agency policies and procedures designed to reduce these risks. FISMA also includes requirements for training personnel who have significant responsibilities for information security. According to NIST, agencies should also document and monitor individual information system security training activities, including basic security awareness training and specialized information system security training.

Consistent with federal law and guidelines, FDA’s Information System Security and Privacy Control Parameters Guide states that the agency should provide role‐based security‐related training to all personnel with significant information security responsibilities. The agency’s policy also requires that employees with significant security responsibilities participate in role-based training appropriate to their security role before receiving access to the system, when required by system or role changes and every 3 years thereafter.

FDA tracked and provided security awareness training in fiscal years 2015 and 2016 to each of the 16 users we selected for review. The agency tracks its user awareness training through a vendor-provided web-based application. According to FDA, it previously provided awareness training to about 98 percent of its users during fiscal year 2015.

However, the agency did not always track role-based training for those with significant security responsibilities. For example, FDA’s tracking system only identified 6 of the 16 individuals selected as having received role-based training. According to FDA personnel, the resulting list was not complete because the agency is re-engineering its process for tracking compliance of specialized security training.

In addition, it did not fully provide role-based training to those with significant security responsibilities. FDA demonstrated that 6 of the 16 individuals with significant security responsibilities we reviewed received specialized IT training. FDA responded that the remaining 10 individuals were not system administrators who required specialized training.

However, 9 of the remaining 10 individuals had significant security responsibilities, which included the deputy chief information security officer and several information systems security officers.

According to FDA staff, the agency is currently developing role-based training courses for executives and contracting officer’s representatives, and will update its IT administrator module on or around October 1, 2016. Until FDA implements procedures that provide reasonable assurance that it tracks and provides role-based training to employees with significant information security responsibilities, the agency will have less assurance that staff have the adequate knowledge, skills, and abilities consistent with their roles to protect the confidentiality, integrity, and availability of the information.

FDA Did Not Fully Test Controls or Monitor Them Effectively

A key element of an information security program is to test and evaluate policies, procedures, and controls to determine whether they are effective and operating as intended. This type of oversight is a fundamental element because it demonstrates management’s commitment to the security program, reminds employees of their roles and responsibilities, and identifies areas of noncompliance and ineffectiveness. FISMA requires that the frequency of tests and evaluations of management, operational, and technical controls be based on risks and occur no less than annually. OMB directs agencies to meet their FISMA-required controls testing by drawing on security control assessment results that include, but are not limited to, continuous monitoring activities. OMB also requires agencies to develop and maintain an information system continuous monitoring (ISCM) strategy and implement an ISCM program in accordance with NIST guidelines. OMB required agencies to develop their ISCM strategies by February 28, 2014.

Continuous monitoring of security controls employed within or inherited by the system is an important aspect of managing risk to information from the operation and use of information systems. The objective of continuous monitoring is to determine if the set of deployed security controls continues to be effective over time in light of the inevitable changes that occur to a system and within an agency. Such monitoring is intended to assist in maintaining an ongoing awareness of information security, vulnerabilities, and threats to support agency risk management decisions. The monitoring of security controls using automated support tools can help facilitate continuous monitoring.

FDA has taken steps to monitor security controls through bi-weekly vulnerability scanning using automated tools. The agency also conducted annual assessments of its information systems. However, the agency did not fully or annually assess controls for 2 of the 7 systems we reviewed. To illustrate, FDA did not assess any of the security controls for a system supporting its scientific research activities. For the other system, which supports FDA’s IT infrastructure, the agency had not conducted an assessment since 2013, thus not meeting FISMA’s requirement to assess controls at least annually. Further, we found that FDA has not developed and documented a continuous monitoring strategy for its information systems. HHS’s inspector general previously reported this weakness in fiscal years 2013 and 2014.

According to FDA staff, the agency plans to assess the infrastructure system during fiscal year 2016 since the system was being restructured during fiscal year 2015. In addition, the agency plans to implement a pilot program for continuous monitoring in August 2016. Further, the agency plans to implement the Department of Homeland Security’s Continuous Diagnostics and Mitigation tool in 2016 to improve continuous monitoring of its IT assets. Until it fully tests controls for all systems and develops and documents a continuous monitoring strategy, FDA has less assurance that controls over its information and information systems are in place and operating as intended.

Identified Security Weaknesses Were Not Always Remedied in a Timely Fashion or Based on Risk

FISMA requires that agency-wide information security programs include a process for planning, implementing, evaluating, and documenting remedial actions to address any deficiencies in the information security policies, procedures, and practices of the agency. Agencies should establish procedures to reasonably ensure that all information security control weaknesses, regardless of how or by whom they are identified, are addressed through the agency’s remediation processes. For each identified control weakness, the agency is to develop and implement a plan of actions and milestones (POA&M) based on findings from security control assessments, security impact analyses, continuous monitoring of activities, audit reports, and other sources. When considering appropriate corrective actions to be taken, the agency should, to the extent possible, consider the potential agency-wide implications and design appropriate corrective actions to systemically address the deficiency.

FDA’s Plans of Action and Milestones Guide is generally consistent with federal guidance, and the agency’s guide specifically requires that high- risk weaknesses be corrected within 60 days.

FDA had also generally developed and documented POA&Ms for addressing security control weaknesses and made efforts to consider agency-wide implications of security weaknesses. However, it did not always complete remedial actions in a timely manner in accordance with the agency’s established deadlines or risk requirements. To illustrate, for the seven major applications and general support systems we examined, 183 of 611 (roughly 30 percent) of the POA&Ms had not been remedied by their scheduled completion date, 30 of which were identified as high risk and not corrected within the agency-defined requirement of 60 days. Of the 183 delayed POA&Ms, 102 had a scheduled completion date of 2013 or earlier. As a further example, FDA’s remedial action plans listed two high-risk weaknesses identified by its Office of Inspector General in 2006 and 2007, but FDA had not mitigated these weaknesses even though the agency had planned completion dates in 2012.

FDA personnel stated that they faced challenges in remediating POA&Ms in a timely manner and based on risk. According to FDA personnel, there was a large volume of open POA&Ms and insufficient resources, which delayed addressing weaknesses in a timely manner: as of the first quarter of 2015, FDA had 1,265 open POA&Ms. FDA staff also noted that risk is considered in prioritizing remediation, but that other factors such as available resources and business impacts are also considered. FDA personnel stated that, because of the large number of open POA&Ms, they will go after “low-hanging fruit,” favoring remediation of a larger number of POA&Ms over concentrating on high-risk weaknesses.

By not resolving identified weaknesses in a timely manner, or in accordance with its own policy, FDA faces an increased likelihood that weaknesses, including high-risk vulnerabilities, will go uncorrected, be exploited, and result in greater harm to agency systems and information.

FDA Did Not Fully Implement Elements of Its Incident Response Program

Even with strong information security controls, incidents can still occur. Agencies can reduce the risks associated with these events by detecting and promptly responding before significant damage is done. A key element of an effective incident response program includes implementing comprehensive policies, procedures, and controls in order to rapidly detect incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore computing services. NIST SP 800-53 recommends that agencies review and update their incident response policy and procedures at an organization-defined frequency. NIST also recommends that an organization coordinate its incident handling activities with contingency planning activities so that during a severe incident, the agency has actions in place to keep its business operational. NIST further recommends that agencies implement lessons learned from ongoing incident handling activities into incident response procedures, training, and testing, and implements the resulting changes accordingly.

While FDA has developed and documented an incident response policy, the agency did not comply with its own policy of updating its incident response policy every 3 years. The policy has not been updated since it was created in January 2007.

Further, neither FDA’s incident response policy nor its procedures require or describe steps for coordinating incident response activities with planning for contingencies or system disruptions. The agency also did not update its incident response procedures using the results of lessons learned from prior incident response table top exercises we examined. For example, results from a 2012 table top exercise indicated that FDA should better train its employees so that newer, less-experienced staff are better able to respond to significant cyber incidents, and that FDA should update its procedures to include training requirements. However, the lessons learned were not incorporated into FDA’s incident response procedures. Without effective incident response practices in place, FDA has reduced assurance that its systems and information are protected and that it can respond to incidents.

In response to our findings, FDA staff mentioned that the agency is in the process of incorporating lessons learned from incident handling activities into its incident response procedures, training, and testing. In addition, the agency stated that it is taking various steps to address incident response based on our feedback from previous surveys and data requests. The agency stated that it has discontinued its incident response standard operating procedure and was developing a new one based on NIST SP 800-61. The agency’s staff also mentioned that personnel will undergo security training and that FDA is piloting various products to improve the agency’s overall security posture, including incident response. We have not yet verified that the agency has implemented these actions, but such actions could improve FDA’s incident response capability.

Conclusions

Although FDA has implemented numerous controls and taken steps intended to protect its information and information systems, pervasive control weaknesses continue to jeopardize the confidentiality, integrity, and availability of its sensitive information. In fiscal year 2015, the agency centralized the management and location of its network and security operations with intended goals that include establishing real-time network awareness and improved incident detection. The agency also immediately resolved some of the weaknesses we identified during this review. Nonetheless, significant weaknesses in controls for preventing or limiting unauthorized access to its systems and information, as well as weaknesses in other controls, such as those for ensuring that software and hardware are updated and securely configured and that sensitive media is disposed of, put FDA’s systems at risk. This is significant considering that these systems handle proprietary business data from companies in multiple industries and sensitive public health data.

An underlying cause for many of these weaknesses is that FDA has not fully implemented its agency-wide information security program, such as developing and documenting appropriate policies and procedures, ensuring security controls are tested effectively, remediating weaknesses in a timely manner, and planning for contingencies or system disruptions and effectively managing risks. The widespread weaknesses in technical controls and the incomplete implementation of program elements suggest that the agency has not made effective information security a high enough priority. Until FDA implements these practices and controls, it will have limited assurance that its information and information systems are adequately protected against unauthorized access, disclosure, modification, or loss.

Recommendations for Executive Action

To effectively implement key elements of the Food and Drug Administration’s (FDA) information security program, we are recommending that the Secretary of Health and Human Services direct the Commissioner of FDA to implement the following 15 recommendations: 1. Complete a risk assessment and authorization to operate for one FDA system. 2. Ensure that completed risk assessments for six systems reviewed address the likelihood and impact of threats to FDA. 3. Develop a policy for system maintenance. 4. Develop procedures for the following 8 security control families: Audit and Accountability, Identification and Authentication, Maintenance, Media Protection, Physical and Environmental Protection, Security Planning, Systems Communication and Protection, and System Information and Integrity. 5. Enhance procedures for the following 7 security control families: Access Control, Awareness and Training, Security Assessment and Authorization, Configuration Management, Program Management, Personnel Security, and System and Services Acquisition. 6. Review and update as needed per FDA’s frequency, the policies for the following 11 security control families: Access Control, Audit and Accountability, Contingency Planning, Identification and Authentication, Incident Response, Media Protection, Physical and Environmental Protection, Security Planning, Personnel Security, System and Services Acquisition, and System and Information Integrity. 7. Develop and document a security plan for one system supporting FDA’s scientific research. 8. Update security plans to ensure the plans fully and accurately document the controls selected and intended for protecting each of the six systems. 9. Review and approve security plans for the six systems reviewed at least annually. 10. Implement a process to effectively monitor and track training for personnel with significant security roles and responsibilities. 11. Ensure that personnel with significant security responsibilities receive role-based training. 12. Test controls at least annually for the two systems that support FDA’s scientific research and IT infrastructure. 13. Implement remedial actions in accordance with FDA’s prescribed time frames or update milestones if actions are delayed. 14. Update FDA’s incident response policy in accordance with agency requirements. 15. Update incident response procedures to include (1) instructions for coordinating incident response with contingency planning and (2) lessons learned from incident response tests.

We are also making 166 technical recommendations in a separate report with limited distribution. These recommendations address information security weaknesses related to boundary protection, identification and authentication, authorization, cryptography, physical security, configuration management, and media protection.

Agency Comments and Our Evaluation

We received written comments on a draft of this report from the Department of Health and Human Services (HHS). In the comments (reprinted in appendix II), the department stated that FDA concurred with our recommendations, has begun implementing several of them, and is actively working to address all the recommendations as quickly and completely as possible. The department also stated that FDA has acquired third-party expertise to assist in these efforts to immediately address the recommendations in our report.

The department emphasized its commitment to protecting the public health and proprietary business information at FDA, including by implementing layered defenses and other compensating controls. HHS further noted that FDA has not experienced a major cybersecurity-related breach that exposed industry or public health information and that information security remains a high priority at FDA. The department added that since hiring its CIO in 2015, FDA has undertaken steps to better ensure the prevention, detection, and correction of incidents. These include the development of an IT strategic plan and the restructuring of cybersecurity leadership, among other initiatives.

In addition, HHS noted that we did not identify an elevated risk of exposure and/or exfiltration of trade secret and/or other sensitive information. However, this does not accurately reflect the results of our review. As stated in the report, we identified a significant number of weaknesses in technical controls—including access controls, change controls, and patch management—that jeopardize the confidentiality, integrity, and availability of the seven moderate- and high-impact systems we reviewed. Moreover, several of these weaknesses affected FDA’s general support systems, which are connected to numerous systems beyond the ones we reviewed. As previously mentioned, these weaknesses place the seven FDA systems, including those that receive, process, and maintain sensitive industry and public health data, at increased and unnecessary risk of unauthorized access, use, or modification.

The department also made additional comments regarding our report and methodology. In particular, it stated that our methodology did not use an industry-standard approach to assessing risk, defined as the likelihood of a given threat source exploiting a particular vulnerability and the resulting significance of the impact of that adverse event on the organization, or quantify this risk in our overall assessment. We did not perform a comprehensive risk assessment of FDA’s information systems and information because that is FDA’s responsibility, not ours. However, we did consider the elements of risk to agency systems and information during our review. For example, as stated in the report, in selecting the seven systems we reviewed, we considered FDA’s categorization of the impact or magnitude of harm to the agency’s operations, assets, and individuals should the confidentiality, integrity, or availability of the systems and the information they contain be compromised. Six of the seven systems we selected were assigned a Federal Information Processing Standard rating of moderate or high impact by FDA, indicating that the loss of confidentiality, integrity, or availability of these systems or the information they contain would have either a serious or severe/catastrophic impact on the organization. We also considered how each control weakness, vulnerability, or program shortcoming we identified could impair or diminish the effectiveness of a security control or be exploited to facilitate unauthorized system activity. Our report identifies numerous weaknesses and vulnerabilities along with their potential impact if the vulnerabilities are exploited. It is also noteworthy that our work determined that for the reviewed systems, FDA had not determined the likelihood and impact of threats to those systems.

HHS also stated that our report did not consider other FDA tools, resources, and capabilities designed to prevent, detect, and correct incidents, such as its ability to prevent or mitigate breaches like the one that occurred in October 2013. We recognize that FDA has implemented numerous security controls and key elements of its information security program; however, the weaknesses we identified nevertheless pose increased and unnecessary risk to its systems and information. For example, as noted in our report, FDA had not updated its incident response policy since 2007 or incorporated other key elements. Having a complete and up-to-date incident response capability is essential to ensuring that FDA staff have the knowledge and tools to effectively respond to security incidents, such as breaches.

Finally, the department stated that our report does not consistently or clearly distinguish which of the systems reviewed contained sensitive information and which do not. It noted, for example, that FDA’s Scientific Network is a research and development network that does not contain trade secret information. However, as we noted in our report, FDA’s systems operate in an interconnected and networked environment, and the agency had not ensured that the Scientific Network, for example, was adequately isolated from other systems containing sensitive data, nor had it developed and implemented risk management controls for this system. These weaknesses could provide an attacker with a pathway from this less-secure system to other systems containing sensitive public health or proprietary business data. Such weaknesses therefore pose an increased risk to the sensitive information FDA collects and maintains.

As agreed with your offices, unless you publicly announce the contents of this report earlier, we plan no further distribution until 30 days from the report date. At that time, we will send copies to relevant congressional committees, the Secretary of Health and Human Services, the Commissioner of FDA, and other interested parties. In addition, the report will be available at no charge on the GAO website at http://www.gao.gov.

If you or your staff have any questions about this report please contact Gregory C. Wilshusen at (202) 512-6244 or wilshuseng@gao.gov or Dr. Nabajyoti Barkakati at (202) 512-4499 or barkakatin@gao.gov. Contact points for our Offices of Congressional Relations and Public Affairs may be found on the last page of this report. GAO staff who made key contributions to this report are listed in appendix III.

Appendix I: Objective, Scope, and Methodology

The objective of our review was to evaluate the extent to which the Food and Drug Administration (FDA) has implemented information security controls to effectively protect the confidentiality, integrity, and availability of its information on selected information systems.

To determine the effectiveness of the FDA’s security controls, we gained an understanding of the overall network environment, identified interconnectivity and control points, and examined controls for the agency’s networks and facilities. We reviewed controls over the network infrastructure and selected systems that processed confidential commercial and proprietary business information. We performed our work at FDA headquarters in Silver Spring, Maryland, and at several data centers in Ashburn, Virginia, and Silver Spring, Maryland.

We selected a non-generalizable sample of seven systems for review that (1) receive, transmit, and/or process sensitive drug information; (2) are essential to FDA’s mission, support its business processes, and contain or process sensitive proprietary business information; and (3) were assigned a Federal Information Processing Standard rating of moderate or high impact. These systems perform the following support functions:

Support and facilitate post-market product safety surveillance of human drugs, biologics, devices, and combination products. Provide a data repository for collecting, storing, viewing, analyzing, reporting, and tracking the receipt of adverse event data or medication errors.

Establish a single gateway or communications portal for accepting electronic submissions or allowing authorized users to view or obtain information. Examples of electronic submissions include industry- provided trade secrets, adverse event records, and a multitude of different records related to FDA’s regulatory oversight of regulated products.

Provide capabilities for regulatory scientific research, while also supporting FDA’s overall goals and objectives in areas where information technology requires supercomputer-strength computational power.

Support FDA’s research and development activities.

Provide a platform through which FDA organizations may disseminate FDA-related information to interested parties, including the public, health professionals, regulated industries, and the media. Provide information about the various product areas that FDA regulates (food, drugs, medical devices, cosmetics, etc.), timely advisories (e.g., anticipated disease outbreaks such as the Severe Acute Respiratory Syndrome (SARS), buying medicines online, and LASIK surgery), and other FDA activities. Provide links to related reference materials and opportunities for consumers and industry to interact with the FDA.

Provide basic network and security capabilities for the FDA enterprise.

Facilitate receipt and review of electronic drug applications, to include scans and checks of the validity of drug submissions from industry and making them available for reviewers, as well as providing file shares for storing successful submissions that are to be reviewed To evaluate FDA’s controls over its information systems, we used our Federal Information System Controls Audit Manual, which contains guidance for reviewing information system controls that affect the confidentiality, integrity, and availability of computerized information; National Institute of Standards and Technology (NIST) standards and guidelines; Department of Health and Human Services guidelines; FDA policies and procedures; and standards and guidelines from relevant security and IT security organizations, such as the National Security Agency and the Center for Internet Security, and the Interagency Security Committee. reviewed firewall configurations, among other things, to determine whether system boundaries had been adequately protected; reviewed the complexity and expiration of password settings to determine if password management was being enforced; analyzed administrative users’ system access permissions to determine whether their authorizations exceeded that necessary to perform their assigned duties; observed configurations for providing secure data transmissions across the network to determine whether sensitive data were being encrypted; reviewed software security settings to determine if modifications of sensitive or critical system resources had been monitored and logged; observed physical access controls to determine if computer facilities and resources were being protected from espionage, sabotage, damage, and theft; examined configuration settings and access controls for routers, network management servers, switches, and firewalls; inspected key servers and workstations to determine if critical patches had been installed and/or were up-to-date; examined contingency plans for seven systems to determine whether those plans had been developed and tested; reviewed media handling procedures to determine if equipment used for clearing sensitive data had been tested to ensure correct performance; and reviewed personnel clearance procedures to determine whether staff had been properly cleared prior to gaining access to sensitive information or information systems.

Using the requirements identified by the Federal Information Security Modernization Act of 2014 (FISMA), which establishes key elements for an effective agency-wide information security program, and associated NIST guidelines, Department of Health and Human Services and Food and Drug Administration Requirements, we evaluated FDA’s information security program by reviewing assessments of risk for six FDA systems to determine whether threats and vulnerabilities were being identified; analyzing FDA policies, procedures, and practices to determine their effectiveness in providing guidance to personnel responsible for securing information and information systems; analyzing security plans for six systems to determine if those plans had been documented and updated according to federal guidance; examining the security awareness training for employees and contractors to determine whether they had received training according to federal requirements; examining training records for personnel who have significant responsibilities to determine whether they had received training commensurate with those responsibilities; analyzing FDA’s procedures and results for testing and evaluating security controls to determine whether management, operational, and technical controls for seven systems had been sufficiently tested at least annually and based on risk; reviewing FDA’s implementation of continuous monitoring practices to determine whether the agency had developed and implemented an information system continuous monitoring strategy to manage its IT assets and monitor the security configurations and vulnerabilities for those assets; examining FDA’s process to correct weaknesses and to determine whether remedial action plans complied with federal guidance; and reviewing FDA’s implementation of incident response practices.

To determine the reliability of FDA’s computer-processed data, we evaluated the materiality of the data to our audit objective and assessed the data by various means, including reviewing related documents, interviewing knowledgeable agency officials, and reviewing internal controls. Through a combination of methods, we concluded that the data were sufficiently reliable for the purposes of our work.

We conducted this performance audit from February 2015 to August 2016 in accordance with generally accepted government auditing standards. Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objectives. We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objective.

Appendix II: Comments from the Department of Health and Human Services

Appendix III: GAO Contacts and Staff Acknowledgments

GAO Contacts

Staff Acknowledgments

In addition to the individuals named above, Gary Austin, West Coile, Larry Crosland, and Chris Warweg (Assistant Directors); Vernetta Marquis (Analyst in Charge); Alexander Anderegg, Angela Bell, Saar Dagani, Angel Ip, Lee McCracken, Constantine Papanastasiou, Dwayne Staten, and Michael Stevens made key contributions to this report.