Seven Practical Steps for Federal Cyber Security and FISMA Compliance

Transcription

1 Gene Kim CTO, Tripwire, Inc. Seven Practical Steps for Federal Cyber Security and FISMA Compliance white paper Configuration Control for Virtual and Physical Infrastructures

2 Introduction The number of security breaches of federal information systems and cases of improper access to these systems continues to grow at an alarming rate. In fact, federal civilian agencies reported three times more cyber security incidents in 2008 than in 2006, according to the Department of Homeland Security (DHS). And that s just the number of reported incidents; an official at the DHS believes the number may be higher. 1 A quick Internet search reveals the continued pervasiveness of security breaches of federal information systems. The following represents a fraction of the security incidents that have been reported already this year: Three State Department contractors, out of idle curiosity, viewed passport files of over 150 high-profile individuals, including actors and politicians from 2002 to Access to these files is only permissible when necessary to perform official government duties. In mid-march of this year, a Romanian hacker was arrested by Romanian police and potentially faces up to 12 years in jail. The hacker, who called himself Wolfenstein, broke into the U.S. Department of Defense in 2006 and compromised servers and attempted to cover his tracks by deleting access logs. 3 On February 11, 2009, unauthorized access to a computer in the Federal Aviation Administration s (FAA s) network may have exposed the personal information of over 45,000 employees and retirees of the FAA. 4 The FAA claims the server was not connected to the operation of air traffic control. Sometime before February 11, 2009, Govtrip.com, the webbased service that handles reservations for a dozen or more U.S. federal agencies, was hacked and changed so that government employees visiting the site were redirected to a site that installed malicious software on employees computers. A spokesperson from the General Services Administration believes that no user information was compromised. 5 In response to this tremendous increase in detected and reported incidents, the Obama administration has intensified its focus on cyber security across all federal agencies. Evidence of this heightened focus is President Obama s mandate on February 9, 2009, for an immediate 60-day review of the plan, programs, and activities underway throughout the government dedicated to cyber security. This brings up an enormous challenge and highlights an uncomfortable truth: cyber security breaches and failures continue to occur, despite federal organizations putting tremendous time and money into cyber security. And compliance activities often focus more on generating paperwork to prove compliance than creating controls that prevent security breaches and enable their quick detection and recovery, further complicating the issue. Clearly, there is concern about and a desire to improve the security of federal information systems. So where and how do we as information security professionals begin to address the challenge faced not only by those responsible for ensuring the security of federal information systems? In this paper, we turn to Gene Kim, Tripwire CTO and founder, and co-author of Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps, to answer that question and provide seven practical steps any information security organization can take to improve information system security and achieve compliance with relevant regulations, standards and internal security and operational policy. Before launching into the seven practical steps, we ll take a look at recent activities the U.S. Government has undertaken to provide cyber security for its information systems. The Federal Information Security Management Act The Federal Information Security Management Act of 2002, (FISMA) is a prime example of a cyber security effort by the United States Government that shows improved security on paper, but has been found difficult to apply. When FISMA was enacted, its purpose was to ensure that federal agencies secure the information contained in the non-defense information systems of the Unites States government. FISMA not only applies to federal agencies, but also to any contractors or organizations responsible for these information systems. 6 FISMA outlines controls that are valuable and necessary for protecting information systems. Grades for FISMA Compliance Rise, but So Do Security Breaches Unfortunately, many see FISMA compliance as a bureaucratic paperwork drill capable of generating a room full of documents to provide evidence for an audit. Each year, the U.S. Office of Management and Budget (OMB) produces a report card for the FISMA compliance level of each federal agency subject to 2 WHITE PAPER Seven Practical Steps for Federal Cyber Security and FISMA Compliance

3 the act and provides an overall grade for federal information systems. These grades have trended slightly upward in recent years, with the grades for 2005 through 2007 being D+, C- and C, respectively, and a recent OMB report for fiscal year 2008 indicates that cyber security continues to improve. 7 Yet with costs for FISMA projected to balloon from $5.5 billion in fiscal year 2006 to a total of $27.9 billion between 2008 and 2012, 8 an uncomfortable question must be raised: Why has the effectiveness of cyber security programs not increased given that FISMA scores and the cost for FISMA compliance have? New Approaches to Cyber Security and FISMA As the frustration of understaffed agencies trying to meet and prove compliance to FISMA continues to grow, a new initiative has gained support. This initiative, the Consensus Auditing Guidelines (CAG), identifies the high priority security holes to protect from attacks. Rather than competing with FISMA, CAG specifically addresses one of the calls to action of the in-progress update to FISMA 2008 to establish a prioritized baseline of information security measures and controls that can be continuously monitored through automated mechanisms. On top of the CAG initiative, FISMA has recently begun to emphasize measuring security performance. This shift in focus will require effective controls, especially around the correctness of configurations and the enforcement of change control processes. John Gilligan, former Air Force CIO, and the individual driving CAG, reiterated the relevance of correct configurations to cyber security and FISMA, citing that during the NSA vulnerability scanning of the Department of Energy, over 80 percent of successful breaches took advantage of misconfigurations in software. 9 In a radio interview, Mr. Gilligan stated that this source of security risk was a significant driver of some of his other initiatives and activities, which include development of the Federal Desktop Security Standard and his efforts to reform FISMA. The seven practical steps described in this paper reaffirm Mr. Gilligan s view of misconfigurations, emphasizing the need to gain situational awareness and control over access, configurations and change. Characteristics of Highperforming IT Organizations The recommendations in the Visible Ops Security Handbook are based upon the results of an almost 10-year study of IT operations and information security organizations. The study identified the characteristics of high-performing IT organizations those organizations that consistently had the best security, the best compliance posture and the highest ability to maintain predictable and reliable IT operations. These topperformers had figured out how to build sustainable security controls that integrated into daily IT operational processes and delivered value to other organization stakeholders. Studying these high performing IT organizations revealed how to simultaneously maintain an effective security posture, while complying with regulatory requirements. These highperforming IT organizations were: Organizationally aligned High performing information security teams understand how security advances and protects organization goals. Low performing teams focus on things the organization doesn t care about, like the improbable or irrelevant and other technological minutia. Often other groups in the organization consider these low performing teams hysterical. Plugged in High performing information security teams integrate into the right functional groups even though they don t have direct operational responsibility. Low performers aren t present where the work is done and often expend effort helping the wrong people, reinforcing the perception that information security is irrelevant. Adding value High performing information security teams provide value to organization and IT process owners, and they know what they need from these process owners in return. Low performers don t help advance the operational objectives of their colleagues, nor do they clearly articulate what they want people to do differently to meet information security requirements. Consequently, these low performers are often viewed as incompetent. For these organizations, information security simultaneously enabled the organization to respond more quickly to urgent organization needs and helped provide stable, secure and predictable IT services. The Seven Practical Steps In the seven steps discussed in the remainder of this paper, we ll learn how to gain control over production and application/service development processes at the relevant parts of the lifecycle and we ll start generating value for the relevant parties. By doing this, we replicate the observed high-performing 3 WHITE PAPER Seven Practical Steps for Federal Cyber Security and FISMA Compliance

4 characteristics. We ll also be able to simultaneously achieve cyber security objectives while simultaneously achieving and maintaining FISMA compliance objectives. Step 1: Gain Situational Awareness To determine the magnitude of the organizational and technology risks so that we can better prioritize our efforts, we must first identify what technologies are being used, what they are being used for and who is responsible for their management. We can do that by answering the following questions: What IT services are being provided to the organization related to cyber security or FISMA compliance (e.g., externally facing Internet systems, systems that have personally identifiable information (PII), etc.)? What are the organizational and IT units, and how are they managed (e.g., the centralized IT services group, an IT outsourcer, etc.)? What are the other relevant regulatory and contractual requirements for the organization process (e.g., HIPAA, NERC, interagency agreements, contractual service level agreements, the Freedom of Information Act (FOIA), etc.)? What technologies and IT processes are being used for an in-scope asset (e.g., Microsoft Windows Server, Sun Solaris, Oracle, Microsoft SQL Server, etc.)? Are there any high-level risk indicators from the past to be aware of (e.g., repeat audit findings, frequent outages, etc.)? Step 2: Reduce and Monitor Privileged Access Excessive access and privileges to all levels of the IT environment application, database, operating systems, network and firewall can allow individuals to modify or disable security configuration settings, shutdown or disable critical services or alter critical application functionality. Such uncontrolled change may disrupt service and create unnecessary security vulnerabilities. In this step, we take the following measures to ensure users have appropriate access and privileges to critical systems: Document all administrators with privileged access and ensure we can reconcile them with authorized staff. Disable or delete any ghost accounts that cannot be reconciled to authorized staff. Work with system managers to reduce the number of administrators to the practical minimum needed. Ensure that access is appropriately revoked or assigned in response to personnel turnover or transfers. To ensure the measures listed above reduce privileged access, we must: Monitor privileged user account adds, removes and changes wherever they are stored, including service accounts that do system maintenance and tasks such as backing up accounts and managing the enterprise batch scheduler. Reconcile each privileged user account add, remove and change with an authorized change order from the relevant manager. This reconciliation process may be manual (a signed paper form) or automated (with a change ticket from a change management system). Reconcile each privileged account with an authorized user. For example, reconcile the account with an HR record. Alternatively, reconcile each account with an authorized service such as a backup program. Routinely re-accredit accounts quarterly or yearly, depending on turnover to ensure that management can reconcile privileged accounts to reports from HR and payroll. Step 3: Define and Enforce Configuration Standards All layers of the IT infrastructure have configuration and logical security settings designed to limit the risk of human error, fraud and security incidents by ensuring that the technology only performs as expected. Examples of these settings include proper password settings, network configuration settings and logical security settings for the database. Risk can be introduced if these settings are improperly configured. In this step, we use guidance from respected third parties and vendors like the Center for Internet Security, the SANS Institute and the National Institute of Science and Technology (NIST) to ensure our configuration and logical security settings are properly defined, implemented and verified. To ensure adherence to configuration standards, we must: Work with IT management and relevant managers on a policy that defines which security standard or standards should be used. Mandate that all production technologies that pose a risk to cyber security or FISMA related objectives use these secure configuration settings, and create a plan for deploying technologies with these settings. 4 WHITE PAPER Seven Practical Steps for Federal Cyber Security and FISMA Compliance

5 Define a time limit for initial implementation, and set expectations for how quickly corrective measures must be taken on non-compliant configurations. To ensure the above configuration controls are implemented correctly, we must: Assess and continuously monitor configuration settings. For example, we may need to assess and monitor settings stored in Unix or Windows files or Windows registry settings. Test configuration settings against internal security policies, external compliance requirements and industry best practices. Report on any variances. Verify that corrective actions to non-compliant configurations are properly implemented in the required time frame. Step 4: Integrate and Help Enforce Change Management Processes Once IT systems are in a known and trusted state, all changes made to those systems should be authorized, scheduled and substantiated by change management. To do this, we will need to: Help assess the potential impact of changes on information security and operations. Improve procedures for change authorization, scheduling, implementation and substantiation. Ensure that change requests comply with information security requirements, corporate policy and industry standards. To accomplish these objectives, we ll need to do the following: Get invited to Change Advisory Board (CAB) meetings. CAB meetings are used to assess risks of proposed changes, approve or deny change requests, review the status of planned changes, agree on implementation schedules and review the success of implemented changes. By attending, we have a say in the review and approval of those changes subject to the change approval process. Build and electrify the fence. Implement a control that assesses configuration settings against internal and external standards, gives visibility to changes made to systems, helps determine whether the change was authorized and compliant, and in the advent of a security breach, provides forensics data to support an investigation. Ensure tone from the top and help define the consequences. Words and actions from agency management on down set the tone for the behavior of everyone in the organization. We must convince top management to set the tone regarding information security as: The only acceptable number of unauthorized changes is zero. Our CIO, for example, may be able to accomplish this by simply sending an to all organizational units expressing this policy, explaining the potential damage unauthorized change can cause, and specifying consequences for those who intentionally circumvent policy. Substantiate that the electric fence is working. To prove compliance with change management processes, we must prepare for audits in advance. We ll need the following evidence: change requests and their approvals, changes detected on all relevant IT systems, reconciliations of detected changes to approved changed requests and corrective actions taken for unauthorized changes. By taking these actions, we will have integrated information security into the necessary preventive change management processes. We also will have created detective controls to ensure that those preventive controls are working. Finally, we will have created evidence to prove to auditors that effective change controls exist. Step 5: Create a Library of Trusted server builds When information security is not integrated into release management processes, IT systems may be deployed without adequate controls, resulting in negative outcomes like security breaches and compliance and audit findings. In this step, we create a library of known, trusted, and approved server builds that can be used to quickly and easily deploy an authorized, secure configuration. These secure builds combine mandatory and recommended configurations to reduce the likelihood of operational and information security failures that create vulnerabilities an intruder can exploit. To create this library, we must document the standards we will use, which requires us to: Develop standards that specify how to secure and harden the builds we release into production or check into the definitive software library (DSL). For guidance, we turn to configuration standards for information security developed by trusted external organizations such as CIS, the SANS Institute, and IT system vendors. As these external standards evolve, we ll need to update our documentation. Work with the server provisioning and release management teams to integrate independent configuration standards and 5 WHITE PAPER Seven Practical Steps for Federal Cyber Security and FISMA Compliance

6 checklists. We ll also need to take standard risk-reducing measures, such as: Turnoff unnecessary features and modules that are enabled by default Disable un-needed services (e.g., http, DNS, and SMB) Disable un-needed open network ports Delete or disable unnecessary user accounts Change default passwords Ensure that relevant passwords are changed before systems move from development to production for example, developers who know ODBC and application passwords for a new order entry system no longer need these passwords when the system enters production. Include standard configuration monitoring agents in each trusted build. Once we ve defined the policies and standards that create the library of approved builds, we need to ensure these controls are working by: Assessing production configurations against known internal and external standards to ensure they are in a known, approved and secure state. Monitoring the approved build library to ensure that all adds, removes and changes conform to internal and external standards. Reconciling all adds, removes, and changes to an authorized change order. This task may be done manually or may be automated. Step 6: Integrate Into Release Management Testing and Acceptance Procedures To protect the production environment, information security requires standardization and documentation; implementation controls like checklists; and continuous control of production variance. Release management shares many of these key objectives. And while Development tends to focus on specific components, release management focuses on collections of components and whether they work together. To be effective, release management often relies on checklists and templates. In this step, we must engage with release management to ensure that information security requirements are added to their lists. To do this, we must: Develop templates for release management and interface with this team as well as quality assurance (QA) and project management to ensure that information security and regulatory compliance requirements are methodically collected at the start of each project. Establish an agreed-upon protocol for when and how release management should engage information security. For example, an agreed-upon protocol should be established regarding releases that include code that involve authorization, encryption, financial transactions and compliance requirements. Integrate automated security testing tools into the release testing process and run them against code, builds and releases. Use vulnerability scanning and management testing tools, even if they could potentially crash applications during testing it s better to find vulnerabilities in pre-production rather than in production. Use the same tools in the preproduction and production environments to prepare IT operations for potential problems when these tools are used in the production environment. Compare releases and approved builds being deployed against known and trusted states to mitigate the risks introduced by human error, missed steps, mis-configurations and other sources. In some situations, the security testing conducted by QA is sufficient for us to approve a release. In other cases, we must conduct independent security testing. Either way, arming QA with the same tools information security uses reduces findings for security testing and typically at a lower cost, with less stress, and with higher success rates for releases because corrections are made by QA. The previous preventive controls are the release testing protocols, including checklists and test procedures. To ensure these controls are working, we must: Verify that deployed image configurations match the approved and tested builds by testing them against known internal and external standards. Detect all changes made to the test environments. Reconcile changes to an authorized change order either manually or automatically. Step 7: Ensure That All Production Activities Go Through Change Management Production actions such as activating or deactivating an IT system that supports the production environment must be defined as a change. Not defining such actions as a change could result in an unauthorized deactivation of a critical application, which 6 WHITE PAPER Seven Practical Steps for Federal Cyber Security and FISMA Compliance

7 in turn could jeopardize power delivery and affect other critical organization objectives. To do this, we will need to work with change management and production service delivery managers to ensure all production actions are authorized, scheduled and audited by change management. Information security, change management, and relevant managers will need to answer the following questions and generally agree on the answers: Under what conditions are activations, deactivations and restarts changes that require approval? Consider, for example, whether changes require approval if the change delivers a new IT service, enables a service that has security or regulatory requirements, or introduces outage risk to a missioncritical service. Who must approve standard and emergency changes? Once we ve created policies based on the answers to these questions, we must verify that these policies are followed. We can do this by monitoring all activations and deactivations and reconciling them with an authorized and scheduled change. Such monitoring lets information security ensure that activity that could introduce information security risks is adequately reviewed and mitigated. Steps for Secure, Compliant Federal Information Systems Maintaining strong cyber security of federal information systems is more than a checklist and paperwork exercise; it requires generating value for the relevant parties in the organization. Many of the steps described in this paper require us to demonstrate that the security measures we promote align with, advance and protect the organization s goals. In addition, to further gain support for integrating security into everyday organization processes, we must ensure we integrate with the right groups even when we don t have direct operational responsibility for the work they do. Configuration control solutions like Tripwire Enterprise offer us the ability to demonstrate the value of critical security measures with configuration assessment that ensures the correctness of configurations and enhanced file integrity monitoring that helps maintain configurations in that correct state. Tripwire Enterprise also provides proof that these security measures are working even supporting INFOCON requirements. Such proof is invaluable for both audit purposes and for further achieving buy-in from other IT process owners. By taking these seven practical steps to build relationships, institute preventive controls into IT production operations, and verify the effectiveness of those preventive controls, we can simultaneously meet IT operational and security goals and achieve compliance with relevant regulations like FISMA. 1 Number of reported cyber incidents jumps. A February 17, 2009 article by Ben Bain in FederalComputer Week. 2 Former State Department worker sentenced for passport snooping. A March 23, 2009 article in Computeworld by Grant Gross. action/article.do?command=viewarticlebasic&articleid= &intsrc=hm_list 3 Romanian DoD hacker nabbed. A March 20, 2009 article by Greg Masters in SC Magazine. article/129193/ 4 FAA Computers Hacked, Employee Data at Risk. February 11, 2009 article by Thomas Claburn in InformationWeek. security/attacks/showarticle.jhtml?articleid= Hackers break into government travel site, feed users attack code. February 18, 2009 article by Gregg Keizer in Computerworld. com/action/article.do?command=viewarticlebasic&articleid= The National Institute of Science and Technology (NIST), the organization charged with ensuring compliance with FISMA, developed a set of comprehensive guidelines, the 800 series of special publications, entities subject to FISMA must follow to secure federal 7 Fiscal Year 2008 Report to Congress on Implementation of The Federal Information Security Management Act of A report from the U.S. Office of Management and Budget 8 Ibid. 9 Federal News Radio, December 12, 2008, Interview with John Gilligan. 7 WHITE PAPER Seven Practical Steps for Federal Cyber Security and FISMA Compliance

8 About Tripwire Tripwire helps over 6,500 enterprises worldwide reduce security risk, attain compliance and increase operational efficiency across virtual and physical environments. With its industry leading configuration assessment and change auditing software solutions, IT organizations achieve and maintain configuration control. Tripwire is headquartered in Portland, Oregon, with offices worldwide Tripwire, Inc. Tripwire is a registered trademark of Tripwire, Inc. All other product and company names are property of their respective owners. All rights reserved. WPFCS1