1 / 24

Effectively Integrating Information Security into the Enterprise Performance Life Cycle (EPLC)

Effectively Integrating Information Security into the Enterprise Performance Life Cycle (EPLC) Daniel Sands, NIH Chief Information Security Officer April 8, 2009. Agenda. Introduction Understanding Information Security IT Governance and the Project Manager

tangia
Download Presentation

Effectively Integrating Information Security into the Enterprise Performance Life Cycle (EPLC)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Effectively Integrating Information Security into the Enterprise Performance Life Cycle (EPLC) Daniel Sands, NIH Chief Information Security Officer April 8, 2009

  2. Agenda Introduction Understanding Information Security IT Governance and the Project Manager EPLC Information Security Activities Certification and Accreditation Process and Key Documents Tips for Strengthening your Security Posture Conclusion Resources

  3. Information Security has become aMission-Essential Function Federal agencies rely substantially on IT to run their daily operations and deliver products and services. Almost all projects involve the use and production of data and information system technologies Growing complexity of the federal government IT infrastructure—and the proliferation of laws, regulations and directives to govern and protect it. Constantly evolving information security threat and risk environment. Leading to increasing resources being channeled to protection of sensitive information, including PII, encryption, Federal Desktop Core Configuration (FDCC), HSPD-12, incident response, risk management, audit and oversight, role-based training…and the list continues.

  4. Current State of Affairs • Continuing serious attacks on federal information systems, large and small; targeting key federal operations and assets. • Significant exfiltration of critical and sensitive information and implantation of malicious software. • Attacks are organized, disciplined, aggressive, and well resourced; many are extremely sophisticated. • Adversaries: nation states, terrorists groups, hackers, criminals, and any individual or groups with intentions of compromising a federal information system. • Increasing number of trusted employees taking dangerous and imprudent actions with respect to organizational information systems.

  5. The Security Threat Landscape has Transformed Dramatically and Requires Vigilant Security Efforts 20th Century 21st Century Adversaries were script kiddies and hackers interested in the technology. Boasted of successful attacks to their friends via chat. Adversaries are nation states and criminals for hire. Motivated by money or national interest, stealing intellectual property and personal information is a top priority. Defaced web pages and produced worms exploiting readily available vulnerabilities, did no real damage. Attack networks via web, email and open ports, silently burrow into internal computers, steal admin passwords & SSNs with keyloggers Peripheral web sites and network infrastructure were primarily targeted, attacks were relatively small in scale, defense was at the perimeter firewall. End users on internal network are now the primary target of current phishing and other malware attacks. Botnets are world-wide and difficult to detect and eradicate.

  6. What is Information Security? Security is a constant process of identifying threats to the confidentiality, integrity and availability of our information and information systems, determining risks and vulnerabilities, and mitigating threats through theexecution of cost-effective security controls.

  7. Three Tenets of Information Security Confidentiality: Addresses the protection of private, sensitive or trusted information resources from unauthorized access or disclosure Integrity: Refers to the accuracy, completeness & consistence of information resources Availability: Ensures reliable & timely access to information resources by appropriate personnel Security planning is a high priority—if information resources are unavailable, unreliable, or disclosed in an inappropriate manner, NIH could suffer damage to its reputation and incur serious financial, operational or human life losses.

  8. IT Governance and EPLC To ensure effective IT Governance of all projects, HHS mandates use of the Enterprise Performance Lifecycle (EPLC) framework to improve the quality of project planning and execution and to reduce overall project risk. NIH seeks to improve the manner that our IT project are governed and managed so that the most benefit is gained at the least impact to the NIH’s resources, budget and business priorities. Information security governance requires the establishment and maintenance of a framework and supporting management structure and processes to provide assurance that information security strategies are: aligned with and support business objectives consistent with applicable laws and regulations provide assignment of responsibility—all in an effort to manage risk. Information security is most useful and cost-effective when it’s integrated beginning at project initiation and continued throughout the EPLC through system disposal. Failure to adequately address information security requirements in a timely manner may lead to project delays, added costs and may impact performance.

  9. Security Areas of Focus for the Project Manager Ensuring potential security concerns are identified at the initiation of the project, designed into the system, reviewed periodically and maintained throughout the lifecycle. Address the hardware, software and communications. Engaging all relevant individuals to participate on the Security team. Ensuring adequately trained staff (developers, database administrators, users, etc.) Complying with relevant laws, regulations, policies and practices that define the security approach and controls. Ensuring adequate funds are included in the budget (to cover initial and ongoing review activities, resource requirements and implementation of security solutions and all ongoing security maintenance costs).

  10. EPLC Information Security ActivitiesPhase 1: Initiation Business Needs Determination: Define a problem that might be solved through product acquisition. Consider the basic system idea, preliminary requirements, feasibility and technology assessment. Are upfront security concerns identified, e.g., will you be running a website and collecting personally identifiable information (compliance with Section 208 machine-readable privacy policy, Section 508, Privacy Act requirements, encryption, etc) Establish the Security Team: business owner, system owner, IC Information Systems Security Officer (ISSO), IC Chief Information Officer (CIO), other key participants. Document and assign security roles and responsibilities.

  11. EPLC Information Security ActivitiesPhase 2: Concept Project Manager develops a “Security Approach” (addresses the entire system and guides later phases—clearly defines security strategy in line with business requirements). System Categorization: Identify the information that will be transmitted, processed, or stored by the system, as well as who is required access to the information and how they will access it (in high level terms). Conduct a high-level preliminary risk assessment to identify the basic security needs of the system and define the threat environment in which the system will operate. Determine if the system will be independent or a component of an already-defined system. If there are interconnections with other systems, individuals from those systems must be included in the project team.

  12. EPLC Information Security ActivitiesPhases 3-6: Planning, Requirements, Design & Development Perform a requirements analysis: Conduct an in-depth study of the basic security needs of the system. Develop and incorporate security requirements into specifications. Determine if there are additional functional requirements based on the system’s environment, i.e., are there enterprise security architecture requirements. Analyze the need for legal, regulatory, protection and/or functional security requirements Conduct a formal Risk Assessment to identify system protection requirements. Ensure the acquisition documents include security contract language. Determine the costs associated with the acquisition and integration attributable to information security over the lifecycle (hardware, software, personnel and training) as part of the CPIC requirements. Categorize the system with impact levels of low, moderate, or high in regard to confidentiality, integrity, and availability in accordance with FIPS 199, Standards for Security Categorization of Federal Information Systems and NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories. FIPS 200, Minimum Security Requirements for Federal Information and Information Systemsspecifies the minimum security requirements for systems in 17 security-related areas. NIH must meet these requirements by using the security controls specified in NIST SP 800-53, Recommended Security Controls for Federal Information Systems.

  13. EPLC Information Security ActivitiesPhases 3-7: Planning, Requirements, Design, Development and Test (cont) System Security Plan is developed to provide an overview of the security requirements of the system and to describe the controls in place or planned for meeting those requirements. Delineates responsibilities and expected behavior of individuals who access the system. The System Security Plan is a living document. Project Manager, system owner and security personnel need to actively participate in the security planning process and will have input into the determination of security controls applied to their system. Establish related security documents that align the system security requirements with the NIH information security program, i.e., documentation required to support the Certification and Accreditation (C&A) of the system. Supporting documents include a configuration management plan, contingency plans, incidence response, awareness and training, rules of behavior, risk assessment, security test and evaluation results, system interconnection agreements, formal C&A authorizations/accreditations, and plans of action and milestones (POA&M). Develop user manuals and operations/administrative manuals. Implement and test security controls identified in the security plan. Develop test plan/script/scenarios.

  14. EPLC Information Security ActivitiesPhase 8: Implementation Develop test data and test units, subsystems and the entire system. Technically evaluate the system to ensure compliance with federal laws, regulations, policies, guidelines and standards. Verify and validate (IV&V) that all the functionality described in the specifications is included in the deliverables. Integrate the system at the operational site, enable security control settings and ensure proper installation in accordance with vendor instructions proper security implementation guidance. Security Certification by the Certification Authority: Verification that controls are effectively implemented, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. Usually performed by IC ISSO. Security Accreditation by the Designated Approving Authority: Formal Authorization of a system to process, store and transmit information. Granted by a senior official (usually IC CIO) and based on the verified effectiveness of the controls and consideration of any identified residual risk to the NIH assets or operations. The process determines if the remaining known vulnerabilities in the system pose an acceptable level of risk to NIH operations, assets or individuals. Based on this process, the System Owner is given: 1) Authority to operate, 2) Interim authorization to operate, or 3) Denial of authorization to operate.

  15. EPLC Information Security Tasks/ConcernsPhase 9: Operations & Maintenance Configuration Management and Control: Continue to consider potential security impacts due to changes in the system or its surrounding environment. Establish baselines of hardware and software components, and for subsequently controlling and maintaining an inventory of any changes to the system. Continuous Monitoring: Ensure that documents are updated as necessary in response to continuous testing and monitoring. Ensure Authority to Operate, System Certification and Accreditations, Privacy Impact Assessments, etc. are reviewed and updated at appropriate times for continued operations. Conduct periodic audits/assessments to monitor and ensure security controls are functioning as required. Monitor the system and/or users (system logs and reports, automated tools, review change management, and monitor external sources). Address the Plan of Actions and Milestones (POA&M)

  16. EPLC Information Security Tasks/ConcernsPhase 10: Disposition Preserve Information: Retain information, as necessary to conform to legal requirements to accommodate potential changes in technology that might impact the ability to retrieve the information in the future. Follow any prescribed records retention schedule. Ensure access authorities have been removed, data is properly migrated, and all hardware and data storage devices have been sanitized to ensure no sensitive data is compromised. Dispose of hardware and software in accordance with NIH policy.

  17. Certification and Accreditation (C&A) Process The Federal Information Security Management Act (FISMA) and OMB Circular A-130, both require that federal agencies perform IT security risk assessments and prepare security plans for all systems. To ensure property security, all NIH information systems must be certified and accredited based on NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems. C&A of systems includes an independent, comprehensive review of management, operational, and technical controls using a risk-based and cost-effective approach to security. The C&A Process ensures that information systems are: Operating with appropriate management review Performing ongoing security control monitoring Submitted for reaccreditations every three years or when a significant change to the information system or its environment has occurred. Using HHS and NIH guidance, your CIO and ISSO will help determine what level of effort is required.

  18. Key Documents Associated with the Certification and Accreditation Process Risk Assessment – provides the data needed to formulate a security plan that addresses the risks identified for a given system. Security Plan – overview of the security requirements and the agreed-upon security controls. Privacy Impact Assessment – to identify if personally identifiable information is contained in the system (and if so, is their a Privacy Act System of Records Notice. Contingency and Disaster Recovery Plan Security Testing and Evaluation Report Plan of Actions and Milestones (POA&M)

  19. Tips for Strengthening your Security Posture Select a strong security team. People make or break your security program. Make sure they are trained on their responsibilities and ensure they receive adequate, ongoing training to support those responsibilities. Make sure users of your application understand and agree to follow any additional system rules of behavior. Develop secure code and scan applications for vulnerabilities, prior to production and after all changes to existing code. Perform regular system security assessments, and ensure applications are configured securely and patched as necessary. Utilize access control management, role-based authentication and least privilege. Check to ensure outward facing web applications are Section 208 and 508 compliant.

  20. Tips for Strengthening your Security Posture Recognize that all contractors perform work on behalf of the government and are required to comply with all federal laws, policies, and practices (including the requirement for background investigations). Ensure appropriate language/clauses are included in contracts, including nondisclosure agreements. Be able to identify sensitive information, including personally identifiable information, and be familiar with breach notification requirements. Carefully perform the privacy impact assessment. Ensure sensitive data at rest and in transit is encrypted per policy requirements (including data on mobile computers and devices). Ensure all important data is properly backed-up. Your IC Information Systems Security Officer and Chief Information Officer will be valuable resources as you orchestrate the lifecycle of your application.

  21. Information security is not something you do once and forget, but a continuous process. Security is basically the application of common sense policies and procedures that result in real security controls that protect our systems and support our mission. Information security may be expensive and time consuming; but failure to adequately address it will come back and haunt you! Conclusion

  22. Conclusion • Information security is not just a paperwork drill. • There are dangerous adversaries out there capable of launching serious attacks on our information systems that can result in severe or catastrophic damage to the mission of the NIH. • Never underestimate the capabilities of those adversaries. • Never overestimate the ability of your organization and your personnel to protect critical enterprise missions. • Information technology – if you can’t protect it, don’t deploy it.

  23. Key Sources of Authority & Requirements for Information Security Public Law 107-347,Federal Information Security Management Act of 2002 (FISMA), [supersedes the Computer Security Act (1987)]enacted as part of, the E-Government Act of 2002, codifies the security requirements contained in Appendix III of OMB Circular A-130. In addition, it requires agency Inspector Generals to conduct independent audits of agency information security programs, through testing security controls on a subset of agency systems, and report the results to the OMB, which in turn reports the findings to Congress. FISMA charges NIST with special responsibilities to develop guidance to improve federal-wide information security planning, implementation, management, and operation. http://csrc.nist.gov/policies/FISMA-final.pdf OMB Circular A-130, Management of Federal Information Resources (1985), establishes requirements for effective and efficient management of federal information resources. Appendix III, Security of Federal Automated Information Resources, establishes the requirements for agency security programs to safeguard the sensitive information they process. http://www.whitehouse.gov/omb/circulars/a130/a130.html Public Law 104-106 [40 USC Section 1401] (1996) Information Technology Management Reform Act (Clinger-Cohen Act) Grants authority to the head of each agency to acquire information technology (IT) resources and makes them responsible for effectively managing IT investments. http://irm.cit.nih.gov/itmra/itmra96.html Public Law 93-579, U.S. Code 532(a), the Privacy Act (1974), requires the U.S. Government to safeguard personal data processed by federal agency computer systems. It also requires the government to provide ways for individuals to determine what personal information is being recorded and to correct inaccurate information. http://www.usdoj.gov/foia/privstat.htm NIST SP 800-100, Information Security Handbook: A Guide for Managers NIST 800-64, Security Considerations in the System Development Life Cycle FIPS 199, Standards for Security Categorization of Federal Information Systems NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories FIPS 200, Minimum Security Requirements for Federal Information and Information Systems NIST SP 800-53, Recommended Security Controls for Federal Information Systems. NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems NIH Information Security and Awareness Homepage: http://ocio.nih.gov/security/index.html NIH Policy Guidelines and Regulations: http://ocio.nih.gov/security/sec_policy.html NIH System Certification and Accreditation Webpage: http://ocio.nih.gov/nihsecurity/NIH_System_CnA.htm

  24. Protecting NIH Research OCIO

More Related