NIST Special Publication 800-18 Guide For Developing .

2y ago
23 Views
2 Downloads
306.65 KB
101 Pages
Last View : Today
Last Download : 2m ago
Upload by : Eli Jorgenson
Transcription

NIST Special Publication 800-18Guide for DevelopingSecurity Plans for InformationTechnology SystemsMarianne SwansonFederal Computer Security ProgramManagers’ Forum Working GroupDecember 1998

Executive SummaryThe objective of system security planning is to improve protection of informationtechnology (IT) resources. All federal systems have some level of sensitivity and requireprotection as part of good management practice. The protection of a system must bedocumented in a system security plan. The completion of system security plans is arequirement of the Office of Management and Budget (OMB) Circular A-130,“Management of Federal Information Resources,” Appendix III, “Security of FederalAutomated Information Resources,” and Public Law 100-235, “Computer Security Act of1987.”The purpose of the security plan is to provide an overview of the security requirements ofthe system and describe the controls in place or planned for meeting those requirements.The system security plan also delineates responsibilities and expected behavior of allindividuals who access the system. The security plan should be viewed as documentationof the structured process of planning adequate, cost-effective security protection for asystem. It should reflect input from various managers with responsibilities concerningthe system, including information owners, the system operator, and the system securitymanager. Additional information may be included in the basic plan and the structure andformat organized according to agency needs, so long as the major sections described inthis document are adequately covered and readily identifiable.In order for the plans to adequately reflect the protection of the resources, a managementofficial must authorize a system to process information or operate. The authorization of asystem to process information, granted by a management official, provides an importantquality control. By authorizing processing in a system, the manager accepts itsassociated risk.Management authorization should be based on an assessment of management,operational, and technical controls. Since the security plan establishes and documents thesecurity controls, it should form the basis for the authorization, supplemented by morespecific studies as needed. In addition, a periodic review of controls should alsocontribute to future authorizations. Re-authorization should occur prior to a significantchange in processing, but at least every three years. It should be done more often wherethere is a high risk and potential magnitude of harm.iii

Table of ContentsExecutive Summary .iii1 Introduction . 11.1 Background. 11.2 Major Application or General Support System Plans . 11.3 Relationship to Other NIST Security Documents. 21.4 Purposes of Security Plans. 21.5 Security Plan Responsibilities. 31.6 Recommended Format . 31.7 Advice and Comment on Plan . 41.8 Audience. 41.9 Organization of Document . 42 System Analysis . 52.1 System Boundaries. 52.2 Multiple Similar Systems . 52.3 System Category . 62.3.1 Major Applications . 62.3.2 General Support System. 73 Plan Development – All Systems . 93.1 Plan Control . 93.2 System Identification. 93.2.1 System Name/Title. 93.2.2 Responsible Organization . 103.2.3 Information Contact(s). 103.2.4 Assignment of Security Responsibility. 113.3 System Operational Status. 113.4 General Description/Purpose . 113.5 System Environment . 123.6 System Interconnection/Information Sharing. 133.7 Sensitivity of Information Handled. 143.7.1 Laws, Regulations, and Policies Affecting the System . 143.7.2 General Description of Sensitivity. 154 Management Controls. 194.1 Risk Assessment and Management. 194.2 Review of Security Controls. 194.3 Rules of Behavior. 204.4 Planning for Security in the Life Cycle. 214.4.1 Initiation Phase . 224.4.2 Development/Acquisition Phase. 224.4.3 Implementation Phase . 234.4.4 Operation/Maintenance Phase . 234.4.5 Disposal Phase. 244.5 Authorize Processing. 245 Operational Controls. 26v

5.MA. Major Application – Operational Controls. 275.MA.1 Personnel Security. 275.MA.2 Physical and Environmental Protection . 285.MA.2.1 Explanation of Physical and Environment Security . 285.MA.2.2 Computer Room Example . 305.MA.3 Production, Input/Output Controls. 305.MA.4 Contingency Planning . 315.MA.5 Application Software Maintenance Controls . 325.MA.6 Data Integrity/Validation Controls . 345.MA.7 Documentation. 355.MA.8 Security Awareness and Training . 366.MA Major Application - Technical Controls . 376.MA.1 Identification and Authentication . 376.MA.1.1 Identification. 376.MA.1.2 Authentication. 386.MA.2 Logical Access Controls (Authorization/Access Controls). 406.MA.3 Public Access Controls. 446.MA.4 Audit Trails. 455.GSS General Support System – Operational Controls. 475.GSS.1 Personnel Controls . 475.GSS.2 Physical and Environmental Protection . 485.GSS.2.1 Explanation of Physical and Environment Security . 485.GSS.2.2 Computer Room Example . 505.GSS.3 Production, Input/Output Controls. 505.GSS.4 Contingency Planning (Continuity of Support). 515.GSS.5 Hardware and System Software Maintenance Controls. 525.GSS.6 Integrity Controls . 545.GSS.7 Documentation. 555.GSS.8 Security Awareness and Training . 555.GSS.9 Incident Response Capability . 566.GSS General Support System - Technical Controls. 586.GSS.1 Identification and Authentication. 586.GSS.1.1 Identification. 586.GSS.1.2 Authentication. 596.GSS.2 Logical Access Controls (Authorization/Access Controls). 616.GSS.3 Audit Trails. 65Rules of Behavior - Major Application. 1ARules of Behavior - General Support System. 1BTemplate(s) for Security Plan. 1CGlossary. 1DReferences .1EIndex. 1Fvi

AcknowledgmentsAcknowledgmentsThe National Institute of Standards and Technology would like to acknowledge theFederal Computer Security Program Managers’ Forum, an organization sponsored by theNational Institute of Standards and Technology. The Forum established a working groupto develop a guideline for developing security plans for all federal systems. Thisdocument evolved from that effort. The members of the working group are identifiedbelow. Please note that some members’ affiliations have changed; however, bothindividual and agency are acknowledged.Robert L. Gignilliant (Chairperson)Department of Health & Human ServicesSadie I. Pitcher (Originating Author)Department of Commerce, RetiredDaniel BartkoDepartment of StateJudy BloomDepartment of JusticePauline BowenFood and Drug AdministrationMarlene BroadusDepartment of StateDoris CarterDepartment of LaborGrace CulverPatent and Trademark OfficeBrenda DyerDepartment of JusticeWilliam GillEnvironmental Protection AgencyAlice GannonOffice of Federal HousingEnterprise OversightJohn HainesDepartment of InteriorW. Ron HessNational Institutes of HealthMary Stone HollandDepartment of StateSherman HowellFederal Deposit Insurance CorporationPhyllis JonesInternal Revenue ServiceJohn KurpielGeneral Services AdministrationSonja D. MartinAgency for International DevelopmentFrancis D. McCuskerPatent and Trademark OfficeDon McGinnisEnvironmental Protection AgencyLouis M. NumkinNuclear Regulatory CommissionSteve PosniakEqual Employment OpportunityCommissionvii

Lloyd ReeseDepartment of Veterans AffairsBob SargisAdministration for Children andFamiliesPhil SibertDepartment of EnergySteve SkolochenkoDepartment of JusticeCarl SpellacyOffice of Thrift SupervisionJosephine M. ThomasSmall Business AdministrationJohn TresslerDepartment of EducationTimothy TurnerOffice of Federal HousingEnterprise OversightRebecca VasvaryNational Oceanographic andAtmospherics AdministrationTed I. WellsPatent and Trademark OfficeTimothy M. WootenFarm Credit AdministrationIn addition, a special thank you is due to Cynthia A. Gosewehr, Census Bureau, forsharing the planning guide template.Finally, NIST would like to thank all the other individuals who contributed to this effort;their assistance was critical to the preparation of this document.viii

Guide for Developing SecurityPlans for Information Technology Systems1IntroductionToday’s rapidly changing technical environment requires federal agencies to adopt aminimum set of management controls to protect their information technology (IT)resources. These management controls are directed at individual information technologyusers in order to reflect the distributed nature of today’s technology. Technical andoperational controls support management controls. To be effective, these controls allmust interrelate. This document provides a guideline for federal agencies to follow whendeveloping the security plans that document the management, technical, and operationalcontrols for federal automated information systems.1.1 BackgroundThe completion of system security plans is a requirement of the Office of Managementand Budget (OMB) Circular A-130, “Management of Federal Information Resources,”Appendix III, “Security of Federal Automated Information Resources,” updated in 1996,and of Public Law 100-235, “Computer Security Act of 1987.”OMB Circular A-130, Appendix III, does not distinguish between sensitive and nonsensitive systems. Rather, consistent with the Computer Security Act of 1987, theCircular recognizes that federal automated information systems have varied sensitivityand criticality. All federal systems have some level of sensitivity and require protectionas part of good management practice. The generic term “system” is used in thisdocument to mean either a major application or a general support system.1.2 Major Application or General Support System PlansAll applications and systems must be covered by system security plans if they arecategorized as a “major application” or “general support system.” Specific securityplans for other applications are not required because the security controls for thoseapplications or systems would be provided by the general support systems in which theyoperate. For example, a department-wide Financial Management System would be amajor application requiring its own security plan. A local program designed to trackexpenditures against an office budget might not be considered a major application andwould be covered by a general support system security plan for an office automationsystem or a local area network (LAN). Standard commercial off-the-shelf software (suchas word processing software, electronic mail software, utility software, or other generalpurpose software) would not typically be considered a major application and would becovered by the plans for the general support system on which they are installed.1Use for All Systems

Guide for Developing SecurityPlans for Information Technology Systems1.3 Relationship to Other NIST Security DocumentsThis document completes the NIST trilogy of IT security program-level guidance. Theplanning guide is intended to be a companion to NIST Special Publication 800-12, AnIntroduction to Computer Security: The NIST Handbook (Handbook) and NIST SpecialPublication 800-14, Generally Accepted Principles and Practices for SecuringInformation Technology Systems (Principles and Practices). The NIST Handbookcontains over 200 pages of guidance in securing computer-based resources. Thedocument explains important concepts, cost considerations, and interrelationships ofsecurity controls. It provides a broad overview of computer security and provides the“why” to many security-related issues. The Handbook served as the template forderiving the practices recommended in the NIST Special Publication 800-14, GenerallyAccepted Principles and Practices for Securing Information Technology Systems.The Principles and Practices document provides the “what” should be done in securingIT resources. The principles section contains the intrinsic expectations that must be metwhether the system is small, large or owned by a government agency or by a privatecorporation. The practices section is the next level in the foundation of the document. Thepractices show what should be done to enhance or measure an existing computer securityprogram or to aid in the development of a new program.This planning guide builds on the practices portion in this document, most practices arefurther expanded and in some cases, excerpts are provided for clarity. The NISTHandbook and the Principles and Practices documents should be referenced for furtherinformation. The NIST Handbook should be used to obtain additional detail orexplanation on any of the controls listed. The Principles and Practices document shouldbe used as a reference to describe the controls and used as a guide for reviewing the plan.Each planning guide control chapter easily maps to the NIST Handbook and thePrinciples and Practices document since the chapters in all three documents are listedunder the same three controls, i.e., management, operational, and technical.The NIST Handbook and the Principles and Practices documents can be obtained fromthe NIST Computer Security Resource Clearinghouse Web site at the URL:http://csrc.nist.gov/1.4 Purposes of Security PlansThe purposes of system security plans are to: Provide an overview of the security requirements of the system and describe thecontrols in place or planned for meeting those requirements; and Delineate responsibilities and expected behavior of all individuals who access thesystem.2Use for All Systems

Guide for Developing SecurityPlans for Information Technology Systems1.5 Security Plan ResponsibilitiesThe System Owner1 is responsible for ensuring that the security plan is prepared and forimplementing the plan and monitoring its effectiveness. Security plans should reflectinput from various individuals with responsibilities concerning the system, includingfunctional “end users,” Information Owners,2 the System Administrator, and the SystemSecurity Manager.Agencies may require contractor compliance with this guide as a contract requirement. Asecurity plan in the format specified in this document or in another agreed upon format issuggested in those cases where vendors are operating a system under contract to thefederal government. In those instances where a contractor or other entity (e.g., state orlocal government) operates a system that supports a federal function, a security plan isrequired.OMB Circular A-130 requires a summary of the security plan to be incorporated into thestrategic IRM plan required by the Paperwork Reduction Act (44 U.S.C. Chapter 35).Agencies should develop policy on the security planning process. Security plans areliving documents that require periodic reviews, modifications, and milestone orcompletion dates for planned controls. Procedures should be in place outlining whoreviews the plans and follows up on planned controls. In addition, procedures are neededdescribing how security plans will be used in the authorization for processing process.1.6 Recommended FormatWhile the format in this guide is recommended, it is recognized that some agencies havedeveloped plans using other formats that meet the A-130 requirements described in thisdocument. This document is intended as guidance only and should not be construed asthe only format allowed. A standardized approach, however, not only makes thedevelopment of the plan easier by providing examples, but also provides a baseline toreview plans. The level of detail included within the plan should be consistent with thecriticality and value of the system to the organization’s mission (i.e., a more detailed planis required for systems critical to the organization’s mission). The security plan shouldfully identify and describe the controls currently in place or planned for the system andshould include a list of rules of behavior.1The System Owner is responsible for defining the system’s operating parameters, authorizedfunctions, and security requirements. The information owner for information stored within, processed by,or transmitted by a system may or may not be the same as the System Owner. Also, a single system mayutilize information from multiple Information Owners.2The Information Owner is responsible for establishing the rules for appropriate use and protectionof the subject data/information (rules of behavior). The Information Owner retains that responsibility evenwhen the data/information are shared with other organizations.3Use for All Systems

Guide for Developing SecurityPlans for Information Technology Systems1.7 Advice and Comment on PlanIndependent advice and comment on the security plan shall be solicited prior to the plan’simplementation. Independent advice and comment must be obtained from individualswithin or outside the organization, who are not responsible for the system’s development,implementation, or operation. Organizational policy should define who will provide theindependent advice. Individuals providing advice and comment should be independent ofthe system owner’s reporting chain and should have adequate knowledge or experience toensure the plan contains appropriate information and meets organizational security policyand standards. Appropriate individuals might include an organization’s IT SecurityProgram Manager, IT managers of other systems, outside contractors, or personnel fromanother federal organization.1.8 AudienceThis guide has two distinct uses. It is to be used by those individuals responsible for ITsecurity at the system level and at the organization level. The document is intended as aguide when creating security plans. It is written specifically for individuals with little orno computer security expertise. The document also can be used as an auditing tool byauditors, managers, and IT security officers. The concepts presented are generic and canbe applied to organizations in private and public sectors.1.9 Organization of DocumentChapter 1 introduces the document and explains its relationship to other NIST guidanceon IT security. Chapter 2 describes the system analysis process. Chapter 3 providesguidance on the general information contained in all security plans. Chapter 4 presentsthe management controls that should be considered. Chapter 5 describes the operationalcontrols and Chapter 6 presents the technical controls. Chapter 5 and Chapter 6 havebeen split into two formats: one format for major applications and another format forgeneral support systems. Differences between the operational and technical controls ofmajor applications and general support systems warrant separate sections. The formatsare depicted by 5.MA and 6.MA for major applications and 5.GSS and 6.GSS for generalsupport systems. Appendix A provides an example of Rules of Behavior for a majorapplication. Appendix B provides an example of Rules of Behavior for a general supportsystem. To assist the reader in preparing the plan with the appropriate format, AppendixC contains two security plan templates, one for major applications and one for generalsupport systems. Appendix D contains a glossary of terms. The terms found in theglossary are highlighted in this document the first time used. Appendix E lists referencesthat may be useful in preparing security plans and finally, an Index is provided forlocating specific topics.4Use for All Systems

Guide for Developing SecurityPlans for Information Technology Systems What mechanisms are in place for holding users responsible for their actions? What are the termination procedures for a friendly termination and an unfriendlytermination?5.MA.2 Physical and Environmental ProtectionPhysical and environmental security controls are implemented to protect the facilityhousing system resources, the system resources themselves, and the facilities used tosupport their operation. An organization's physical and environmental security programshould address the following seven topics which are explained below. In this section,briefly describe the physical and environmental controls in place for the majorapplication5.MA.2.1 Explanation of Physical and Environment SecurityAccess Controls. Physical access controls restrict the entry and exit of personnel (andoften equipment and media) from an area, such as an office building, suite, data center, orroom containing a local area network (LAN) server. Physical access controls shouldaddress not only the area containing system hardware, but also locations of wiring used toconnect elements of the system, supporting services (such as electric power), backupmedia, and any other elements required for the system's operation. It is important toreview the effectiveness of physical access controls in each area, both during normalbusiness hours and at other times -- particularly when an area may be unoccupied.Fire Safety Factors. Building fires are a particularly important security threat because ofthe potential for complete destruction of both hardware and data, the risk to human life,and the pervasiveness of the damage. Smoke, corrosive gases, and high humidity from alocalized fire can damage systems throughout an entire building. Consequently, it isimportant to evaluate the fire safety of buildings that house systems.Failure of Supporting Utilities. Systems and the people who operate them need to have areasonably well-controlled operating environment. Consequently, failures of electricpower, heating and air-conditioning systems, water, sewage, and other utilities willusually cause a service interruption and may damage hardware. Organizations shouldensure that these utilities, including their many elements, function properly.Structural Collapse. Organizations should be aware that a building may be subjected to aload greater than it can support. Most commonly this results from an earthquake, a snowload on the roof beyond design criteria, an explosion that displaces or cuts structuralmembers, or a fire that weakens structural members.Plumbing Leaks. While plumbing leaks do not occur every day, they can be seriouslydisruptive. An organization should know the location of plumbing lines that might28Use for Major Application

Guide for Developing SecurityPlans for Information Technology Systemsendanger system hardware and take steps to reduce risk (e.g., moving hardware,relocating plumbing lines, and identifying shutoff valves.)Interception of Data. Depending on the type of data a system processes, there may be asignificant risk if the data is intercepted. Organizations should be aware that there arethree routes of data interception: direct observation, interception of data transmission,and electromagnetic interception.Mobile and Portable Systems. The analysis and management of risk usually has to bemodified if a system is installed in a vehicle or is portable, such as a laptop computer.The system in a vehicle will share the risks of the vehicle, including accidents and theft,as well as regional and local risks. Organizations should: Securely store laptop computers when they are not in use; and Encrypt data files on stored media, when cost-effective, as a precaution againstdisclosure of information if a laptop computer is lost or stolen.29Use for Major Application

Guide for Developing SecurityPlans for Information Technology Systems5.MA.2.2 Computer Room ExampleAppropriate and adequate controls will vary depending on the individual systemrequirements. The example list shows the types of controls for an application residing ona system in a computer room. The list is not intended to be all-inclusive or to imply thatall systems should have all controls listed.Example Physical/Environmental ControlsFor Computer RoomIn PlaceCard keys for building and work-area entrancesTwenty-four hour guards at all entrances/exitsCipher lock on computer room doorRaised floor in computer roomDedicated cooling systemH

This document completes the NIST trilogy of IT security program-level guidance. The planning guide is intended to be a companion to NIST Special Publication 800-12, An Introduction to Computer Security: The NIST Handbook (Handbook) and NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing

Related Documents:

2.1 NIST SP 800-18 4 2.2 NIST SP 800-30 4 2.3 NIST SP 800-34 4 2.4 NIST SP 800-37 4 2.5 NIST SP 800-39 5 2.6 NIST SP 800-53 5 2.7 NIST SP 800-53A 5 2.8 NIST SP 800-55 5 2.9 NIST SP 800-60 5 2.10 NIST SP 800-61 6 2.11 NIST SP 800-70 6 2.12 NIST SP 800-137 6 3 CERT-RMM Crosswalk of NIST 800-Series Special Publications 7

NIST SP 800-30 – Risk Assessment NIST SP 800-37 – Risk Management Framework NIST SP 800-39 – Risk Management NIST SP 800-53 – Recommended Security Controls NIST SP 800-53A – Security Control Assessment NIST SP 800-59 – National Security Systems NIST SP 800-60 – Security Category Mapping NIST

NIST Risk Management Framework 1. Categorize information system (NIST SP 800-60) 2. Select security controls (NIST SP 800-53) 3. Implement security controls (NIST SP 800-160) 4. Assess security controls (NIST SP 800-53A) 5. Authorize information system (NIST SP 800-37) 6. Monitor security controls (NIST SP 800-137) Source: NIST CSRC, http .

Source: 9th Annual API Cybersecurity Conference & Expo November 11-12, 2014 - Houston, TX. 11 Industry Standards and Committee Initiatives WIB M2784-X-10 API 1164 ISA 99/IEC 62443 NIST SP 800-82 NIST SP 800-12 NIST SP 800-53 NIST SP 800-53A NIST SP 800-39 NIST SP 800-37 NIST SP 800-30 NIST SP 800-34 ISO 27001,2 ISO 27005 ISO 31000

Apr 08, 2020 · Email sec-cert@nist.gov Background: NIST Special Publication (SP) 800-53 Feb 2005 NIST SP 800-53, Recommended Security Controls for Federal Information Systems, originally published Nov 2001 NIST SP 800-26, Security Self-Assessment Guide for IT Systems, published Dec 2006 NIST SP 800-53, Rev. 1 published July 2008 NIST SP 800-53A, Guide for

NIST 800-53 Compliance Controls 1 NIST 800-53 Compliance Controls The following control families represent a portion of special publication NIST 800-53 revision 4. This guide is intended to aid McAfee, its partners, and its customers, in aligning to the NIST 800-53 controls with McAfee

NIST Special Publication 800-55 Revision 1 . Performance M. easurement Guide for Information Security . Elizabeth Chew, Marianne Swanson, Kevin Stine, Nadya Bartol, Anthony Brown, and Will Robinson I N F O R M A T I O N S E C U R I T Y Computer Security Division Information Technology Laboratory Gaithersburg, MD 20899-8930 July 2008File Size: 1MBPage Count: 80Explore furtherNIST Special Publication (SP) 800-55 Rev. 1, Performance .csrc.nist.gov14 Cybersecurity Metrics KPIs You Must Track in 2021 .www.upguard.comTop 20 Cybersecurity KPIs to Track in 2021 SecurityScorecardsecurityscorecard.comNIST Special Publication 800-series General Information NISTwww.nist.govKey Components of an Information Security Metrics Program Plancore.ac.ukRecommended to you b

Proposed installation of underground storage tank (USTs) within groundwater protection zones (GPZs) has led to some conflict between the EA and developers in the past. Although standards for