Joint task force transformation initiative

Sizin üçün oyun:

Google Play'də əldə edin


Yüklə 5.64 Mb.
səhifə1/186
tarix08.01.2019
ölçüsü5.64 Mb.
  1   2   3   4   5   6   7   8   9   ...   186


NIST Special Publication 800-53

Revision 4




Security and Privacy Controls for Federal Information Systems

and Organizations

JOINT TASK FORCE

TRANSFORMATION INITIATIVE

http://dx.doi.org/10.6028/NIST.SP.800-53r4



nistident_flright_300ppi


NIST Special Publication 800-53

Revision 4




Security and Privacy Controls for Federal Information Systems

and Organizations

JOINT TASK FORCE

TRANSFORMATION INITIATIVE

Computer Security Division

Information Technology Laboratory

National Institute of Standards and Technology

http://dx.doi.org/10.6028/NIST.SP.800-53r4




April 2013

includes updates as of 01-15-2014: page xvii

U.S. Department of Commerce



Rebecca M. Blank, Acting Secretary
National Institute of Standards and Technology

Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director
Authority

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-53, Revision 4


Natl. Inst. Stand. Technol. Spec. Publ. 800-53, Rev. 4, 460 pages (April 2013)
http://dx.doi.org/10.6028/NIST.SP.800-53r4
CODEN: NSPUE2


Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by Federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.


Comments on this publication may be submitted to:

National Institute of Standards and Technology

Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Electronic Mail: sec-cert@nist.gov
Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.


Abstract

This publication provides a catalog of security and privacy controls for federal information systems and organizations and a process for selecting controls to protect organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation from a diverse set of threats including hostile cyber attacks, natural disasters, structural failures, and human errors. The controls are customizable and implemented as part of an organization-wide process that manages information security and privacy risk. The controls address a diverse set of security and privacy requirements across the federal government and critical infrastructure, derived from legislation, Executive Orders, policies, directives, regulations, standards, and/or mission/business needs. The publication also describes how to develop specialized sets of controls, or overlays, tailored for specific types of missions/business functions, technologies, or environments of operation. Finally, the catalog of security controls addresses security from both a functionality perspective (the strength of security functions and mechanisms provided) and an assurance perspective (the measures of confidence in the implemented security capability). Addressing both security functionality and security assurance ensures that information technology products and the information systems built from those products using sound systems and security engineering principles are sufficiently trustworthy.




Keywords

Assurance; computer security; FIPS Publication 199; FIPS Publication 200, FISMA; Privacy Act; Risk Management Framework; security controls; security requirements.



Acknowledgements

This publication was developed by the Joint Task Force Transformation Initiative Interagency Working Group with representatives from the Civil, Defense, and Intelligence Communities in an ongoing effort to produce a unified information security framework for the federal government. The National Institute of Standards and Technology wishes to acknowledge and thank the senior leaders from the Departments of Commerce and Defense, the Office of the Director of National Intelligence, the Committee on National Security Systems, and the members of the interagency technical working group whose dedicated efforts contributed significantly to the publication. The senior leaders, interagency working group members, and their organizational affiliations include:



Department of Defense Office of the Director of National Intelligence

Teresa M. Takai Adolpho Tarasiuk Jr.



DoD Chief Information Officer Assistant DNI and Intelligence Community

Chief Information Officer

Robert J. Carey Charlene Leubecker



Principal Deputy DoD Chief Information Officer Deputy Intelligence Community Chief

Information Officer

Richard Hale Catherine A. Henson



Deputy Chief Information Officer for Cybersecurity Director, Data Management

Dominic Cussatt Greg Hall



Deputy Director, Cybersecurity Policy Chief, Risk Management and Information

Security Programs Division

National Institute of Standards and Technology Committee on National Security Systems

Charles H. Romine Teresa M. Takai



Director, Information Technology Laboratory Chair, CNSS

Donna Dodson Richard Spires



Cybersecurity Advisor, Information Technology Laboratory Co-Chair, CNSS

Donna Dodson Dominic Cussatt



Chief, Computer Security Division CNSS Subcommittee Tri-Chair

Ron Ross Jeffrey Wilk



FISMA Implementation Project Leader CNSS Subcommittee Tri-Chair

Richard Tannich



CNSS Subcommittee Tri-Chair

Joint Task Force Transformation Initiative Interagency Working Group

Ron Ross Gary Stoneburner Richard Graubart Kelley Dempsey



NIST, JTF Leader Johns Hopkins APL The MITRE Corporation NIST

Esten Porter Bennett Hodge Karen Quigg Christian Enloe



The MITRE Corporation Booz Allen Hamilton The MITRE Corporation NIST

Kevin Stine Jennifer Fabius Daniel Faigin Arnold Johnson



NIST The MITRE Corporation The Aerospace Corporation NIST

Lisa Kaiser Pam Miller Sandra Miravalle Victoria Pillitteri



DHS The MITRE Corporation The MITRE Corporation NIST

In addition to the above acknowledgments, a special note of thanks goes to Peggy Himes and Elizabeth Lennon of NIST for their superb technical editing and administrative support. The authors also wish to recognize Marshall Abrams, Nadya Bartol, Frank Belz, Deb Bodeau, Dawn Cappelli, Corinne Castanza, Matt Coose, George Dinolt, Kurt Eleam, Jennifer Guild, Cynthia Irvine, Cass Kelly, Steve LaFountain, Steve Lipner, Tom Macklin, Tim McChesney, Michael McEvilley, John Mildner, Joji Montelibano, George Moore, LouAnna Notargiacomo, Dorian Pappas, Roger Schell, Carol Woody, and the research staff from the NIST Computer Security Division for their exceptional contributions in helping to improve the content of the publication. And finally, the authors also gratefully acknowledge and appreciate the significant contributions from individuals, working groups, and organizations in the public and private sectors, both nationally and internationally, whose thoughtful and constructive comments improved the overall quality, thoroughness, and usefulness of this publication.




FIPS 200 AND SP 800-53

implementing information security standards and guidelines

FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems, is a mandatory federal standard developed by NIST in response to FISMA. To comply with the federal standard, organizations first determine the security category of their information system in accordance with FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, derive the information system impact level from the security category in accordance with FIPS 200, and then apply the appropriately tailored set of baseline security controls in NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations. Organizations have flexibility in applying the baseline security controls in accordance with the guidance provided in Special Publication 800-53. This allows organizations to tailor the relevant security control baseline so that it more closely aligns with their mission and business requirements and environments of operation.

FIPS 200 and NIST Special Publication 800-53, in combination, ensure that appropriate security requirements and security controls are applied to all federal information and information systems. An organizational assessment of risk validates the initial security control selection and determines if additional controls are needed to protect organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation. The resulting set of security controls establishes a level of security due diligence for the organization.




developing common information security foundations

collaboration among public and private sector entities

In developing standards and guidelines required by FISMA, NIST consults with other federal agencies and the private sector to improve information security, avoid unnecessary and costly duplication of effort, and ensure that its publications are complementary with the standards and guidelines employed for the protection of national security systems. In addition to a comprehensive public review and vetting process, NIST is collaborating with the Office of the Director of National Intelligence (ODNI), the Department of Defense (DoD), and the Committee on National Security Systems (CNSS) to establish a unified information security framework for the federal government. A common foundation for information security will provide the Civil, Defense, and Intelligence sectors of the federal government and their contractors, more cost-effective and consistent ways to manage information security-related risk to organizational operations and assets, individuals, other organizations, and the Nation. The unified framework will also provide a strong basis for reciprocal acceptance of authorization decisions and facilitate information sharing. NIST is also working with many public and private sector entities to establish mappings and relationships between the security standards and guidelines developed by NIST and the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC).







SECURITY REQUIREMENTS

from the perspective of different communities of interest

The term security requirement is used by different communities and groups in different ways and may require additional explanation to establish the particular context for the various use cases. Security requirements can be stated at a very high level of abstraction, for example, in legislation, Executive Orders, directives, policies, standards, and mission/business needs statements. FISMA and FIPS Publication 200 articulate security requirements at such a level.

Acquisition personnel develop security requirements for contracting purposes that address the protections necessary to achieve mission/business needs. Systems/security engineers, system developers, and systems integrators develop the security design requirements for the information system, develop the system security architecture and the architecture-specific derived security requirements, and subsequently implement specific security functions at the hardware, software, and firmware component level.

Security requirements are also reflected in various nontechnical security controls that address such matters as policy and procedures at the management and operational elements within organizations, again at differing levels of detail. It is important to define the context for each use of the term security requirement so the respective communities (including individuals responsible for policy, architecture, acquisition, engineering, and mission/business protection) can clearly communicate their intent.

Organizations may define certain security capabilities needed to satisfy security requirements and provide appropriate mission and business protection. Security capabilities are typically defined by bringing together a specific set of safeguards/countermeasures (i.e., security controls) derived from the appropriately tailored baselines that together produce the needed capability.




TECHNOLOGY AND POLICY NEUTRALITY

characteristics of security controls

The security controls in the catalog with few exceptions, have been designed to be policy- and technology-neutral. This means that security controls and control enhancements focus on the fundamental safeguards and countermeasures necessary to protect information during processing, while in storage, and during transmission. Therefore, it is beyond the scope of this publication to provide guidance on the application of security controls to specific technologies, environments of operation, communities of interest, or missions/business functions. Application-specific areas are addressed by the use of the tailoring process described in Chapter Three and the use of overlays described in Appendix I. It should also be noted that while the security controls are largely policy- and technology-neutral, that does not imply that the controls are policy- and technology-unaware. Understanding policy and technology is necessary so that the controls are meaningful and relevant when implemented.

In the few cases where specific technologies are called out in security controls (e.g., mobile, PKI, wireless, VOIP), organizations are cautioned that the need to provide adequate security goes well beyond the requirements in a single control associated with a particular technology. Many of the needed safeguards and countermeasures are obtained from the other security controls in the catalog allocated to the initial control baselines as starting points for the development of security plans and overlays using the tailoring process. There may also be some overlap in the protections articulated by the security controls within the different control families.

In addition to the customer-driven development of specialized security plans and overlays, NIST Special Publications and Interagency Reports may provide guidance on recommended security controls for specific technologies and sector-specific applications (e.g., Smart Grid, healthcare, Industrial Control Systems, and mobile).

Employing a technology- and policy-neutral security control catalog has the following benefits:


  • It encourages organizations to focus on the security capabilities required for mission/business success and the protection of information, irrespective of the information technologies that are employed in organizational information systems.

  • It encourages organizations to analyze each security control for its applicability to specific technologies, environments of operation, missions/business functions, and communities of interest.

  • It encourages organizations to specify security policies as part of the tailoring process for security controls that have variable parameters.

The specialization of security plans using the tailoring guidance and overlays, together with a robust set of technology- and policy-neutral security controls, promotes cost-effective, risk-based information security for organizations—in any sector, for any technology, and in any operating environment.




INFORMATION SECURITY DUE DILIGENCE

managing the risk to organizational missions/business functions

The security controls in NIST Special Publication 800-53 are designed to facilitate compliance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Compliance is not about adhering to static checklists or generating unnecessary FISMA reporting paperwork. Rather, compliance necessitates organizations executing due diligence with regard to information security and risk management. Information security due diligence includes using all appropriate information as part of an organization-wide risk management program to effectively use the tailoring guidance and inherent flexibility in NIST publications so that the selected security controls documented in organizational security plans meet the mission and business requirements of organizations. Using the risk management tools and techniques that are available to organizations is essential in developing, implementing, and maintaining the safeguards and countermeasures with the necessary and sufficient strength of mechanism to address the current threats to organizational operations and assets, individuals, other organizations, and the Nation. Employing effective risk-based processes, procedures, and technologies will help ensure that all federal information systems and organizations have the necessary resilience to support ongoing federal responsibilities, critical infrastructure applications, and continuity of government.





PRIVACY CONTROLS

providing privacy protection for federal information

Appendix J, Privacy Control Catalog, is a new addition to NIST Special Publication 800-53. It is intended to address the privacy needs of federal agencies. The Privacy Appendix:



  • Provides a structured set of privacy controls, based on best practices, that help organizations comply with applicable federal laws, Executive Orders, directives, instructions, regulations, policies, standards, guidance, and organization-specific issuances;

  • Establishes a linkage and relationship between privacy and security controls for purposes of enforcing respective privacy and security requirements which may overlap in concept and in implementation within federal information systems, programs, and organizations;

  • Demonstrates the applicability of the NIST Risk Management Framework in the selection, implementation, assessment, and ongoing monitoring of privacy controls deployed in federal information systems, programs, and organizations; and

  • Promotes closer cooperation between privacy and security officials within the federal government to help achieve the objectives of senior leaders/executives in enforcing the requirements in federal privacy legislation, policies, regulations, directives, standards, and guidance.

There is a strong similarity in the structure of the privacy controls in Appendix J and the security controls in Appendices F and G. For example, the control AR-1 (Governance and Privacy Program) requires organizations to develop privacy plans that can be implemented at the organizational or program level. These plans can also be used in conjunction with security plans to provide an opportunity for organizations to select the appropriate set of security and privacy controls in accordance with organizational mission/business requirements and the environments in which the organizations operate. Incorporating the same concepts used in managing information security risk, helps organizations implement privacy controls in a more cost-effective, risked-based manner while simultaneously protecting individual privacy and meeting compliance requirements. Standardized privacy controls provide a more disciplined and structured approach for satisfying federal privacy requirements and demonstrating compliance to those requirements.



cautionary note

implementing changes based on revisions to special publication 800-53

When NIST publishes revisions to Special Publication 800-53, there are four primary types of changes made to the document: (i) security controls or control enhancements are added to or withdrawn from Appendices F and G and/or to the low, moderate, and high baselines; (ii) supplemental guidance is modified; (iii) material in the main chapters or appendices is modified; and (iv) language is clarified and/or updated throughout the document.

When modifying existing tailored security control baselines at Tier 3 in the risk management hierarchy (as described in Special Publication 800-39) and updating security controls at any tier as a result of Special Publication 800-53 revisions, organizations should take a measured, risk-based approach in accordance with organizational risk tolerance and current risk assessments. Unless otherwise directed by OMB policy, the following activities are recommended to implement changes to Special Publication 800-53:


  • First, organizations determine if any added security controls/control enhancements are applicable to organizational information systems or environments of operation following tailoring guidelines in this publication.

  • Next, organizations review changes to the supplemental guidance, guidance in the main chapters and appendices, and updated/clarified language throughout the publication to determine if changes apply to any organizational information systems and if any immediate actions are required.

  • Finally, once organizations have determined the entirety of changes necessitated by the revisions to the publication, the changes are integrated into the established continuous monitoring process to the greatest extent possible. The implementation of new or modified security controls to address specific, active threats is always the highest priority for sequencing and implementing changes. Modifications such as changes to templates or minor language changes in policy or procedures are generally the lowest priority and are made in conjunction with established review cycles.





Dostları ilə paylaş:
  1   2   3   4   5   6   7   8   9   ...   186
Orklarla döyüş:

Google Play'də əldə edin


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2017
rəhbərliyinə müraciət

    Ana səhifə