# INFORMATION TECHNOLOGY SECURITY POLICY HANDBOOK

# 

# Version 3.1

![](media/image1.jpeg){width="4.590277777777778in"
height="4.519444444444445in"}

  ----------------------------------- -----------------------------------
                                      

  ----------------------------------- -----------------------------------

**March 17, 2008**

+-----------------------------------+----------------------------------+
|                                   | **Department of the Interior**   |
|                                   |                                  |
|                                   | **Office of the Chief            |
|                                   | Information Officer**            |
|                                   |                                  |
|                                   | **Cyber Security Division**      |
+-----------------------------------+----------------------------------+

# Document Change History

+------+--------+--------------------------+------------+------------+
| **V  | **Rel  | **Summary of Changes**   | **Section  | **Changes  |
| ersi | ease** |                          | Number/**  | Made By**  |
| on** |        |                          |            |            |
|      | **     |                          | *          |            |
| **   | Date** |                          | *Paragraph |            |
| Numb |        |                          | Number**   |            |
| er** |        |                          |            |            |
+------+--------+--------------------------+------------+------------+
| 1.0  | 03/1   | Initial Draft Release    | N/A        | N/A        |
|      | 5/2007 |                          |            |            |
+------+--------+--------------------------+------------+------------+
| 2.0  | 09/1   | Second Draft -           | All        | Mike Blake |
|      | 5/2007 | incorporated comments    | sections   |            |
|      |        | from Bureaus/Offices     |            | Ken Van    |
|      |        |                          |            | Langen     |
|      |        |                          |            |            |
|      |        |                          |            | Lydia      |
|      |        |                          |            | Lourbacos  |
+------+--------+--------------------------+------------+------------+
| 3.0  | 01/0   | Final Draft & Initial    | All        | Larry      |
|      | 7/2008 | Promulgation -           | sections   | Ruffin     |
|      |        | Incorporated comments    |            |            |
|      |        | from Bureaus/Offices     |            |            |
+------+--------+--------------------------+------------+------------+
| 3.1  | 03/1   | Corrected CA-1 DAA       | All        | Larry      |
|      | 7/2008 | Delegation for OHTA.     | sections   | Ruffin     |
|      |        |                          |            |            |
|      |        | Completed review for     |            |            |
|      |        | document sensitivity and |            |            |
|      |        | removed previous footer  |            |            |
|      |        | markings and corrected   |            |            |
|      |        | page numbering.          |            |            |
|      |        |                          |            |            |
|      |        | Modified AC-7 changing   |            |            |
|      |        | the number of            |            |            |
|      |        | consecutive invalid      |            |            |
|      |        | access attempts by a     |            |            |
|      |        | user from 3 to 5 and the |            |            |
|      |        | IA-5 password history    |            |            |
|      |        | from 10 to at least 24   |            |            |
|      |        | passwords remembered and |            |            |
|      |        | maximum password age was |            |            |
|      |        | modified from 90 to 60   |            |            |
|      |        | days to align with the   |            |            |
|      |        | FDDC OMB/NIST approved   |            |            |
|      |        | settings.                |            |            |
|      |        |                          |            |            |
|      |        | Authorization and Access |            |            |
|      |        | Control Security         |            |            |
|      |        | Standard modified        |            |            |
|      |        | password length from 8   |            |            |
|      |        | to 12 to align with the  |            |            |
|      |        | FDCC OMB/NIST approved   |            |            |
|      |        | settings.                |            |            |
|      |        |                          |            |            |
|      |        | Authorization and Access |            |            |
|      |        | Control Security         |            |            |
|      |        | Standard modified        |            |            |
|      |        | Non-User Account         |            |            |
|      |        | Management requirement   |            |            |
|      |        | to allow not having      |            |            |
|      |        | expiration dates         |            |            |
|      |        | enforced through         |            |            |
|      |        | technical means so as to |            |            |
|      |        | prevent potential        |            |            |
|      |        | adverse impact to        |            |            |
|      |        | operations but requiring |            |            |
|      |        | compensating processes   |            |            |
|      |        | and procedures be in     |            |            |
|      |        | place to ensure that     |            |            |
|      |        | such accounts have       |            |            |
|      |        | passwords changed at     |            |            |
|      |        | least once every 60      |            |            |
|      |        | days; modified password  |            |            |
|      |        | lengths for non-user     |            |            |
|      |        | accounts to be a minimum |            |            |
|      |        | 12 instead of 15; and    |            |            |
|      |        | modified Non-user        |            |            |
|      |        | password complexities to |            |            |
|      |        | require the same 3       |            |            |
|      |        | levels of minimum        |            |            |
|      |        | complexity as any other  |            |            |
|      |        | type of account.         |            |            |
|      |        |                          |            |            |
|      |        | Made corresponding       |            |            |
|      |        | modifications throughout |            |            |
|      |        | document for maximum 60  |            |            |
|      |        | day password age.        |            |            |
+------+--------+--------------------------+------------+------------+

#   {#section-1 .TOC-Heading}

# Table of Contents {#table-of-contents .TOC-Heading}

[INFORMATION TECHNOLOGY SECURITY POLICY HANDBOOK
1](#information-technology-security-policy-handbook)

[Version 3.1 1](#version-3.1)

[Document Change History i](#document-change-history)

[Table of Figures: xv](#table-of-figures)

[Tables: xv](#tables)

[Executive Summary 1](#executive-summary)

[Introduction 3](#__RefHeading___Toc193514325)

[Purpose and Applicability 3](#purpose-and-applicability)

[Relationship to other guidance documents
3](#relationship-to-other-guidance-documents)

[Security Policy Replacement 3](#security-policy-replacement)

[Scope 3](#scope)

[Authorities 4](#authorities)

[Organizational Responsibilities 8](#organizational-responsibilities)

[Information Technology Security Program Leadership Roles
10](#information-technology-security-program-leadership-roles)

[Senior Leadership: 10](#senior-leadership)

[Information Technology Security Program Leadership
15](#information-technology-security-program-leadership)

[Mandatory Access Levels for DOI IT Security Resources (Security
Clearance)
25](#mandatory-access-levels-for-doi-it-security-resources-security-clearance)

[Policy Controls 28](#policy-controls)

[Access Control (AC) 40](#access-control-ac)

[AC-1 -- Access Control Policy and Procedures
41](#ac-1-access-control-policy-and-procedures)

[AC-2 -- Account Management 41](#ac-2-account-management)

[AC-2 Account Management Procedures
43](#ac-2-account-management-procedures)

[AC-3 -- Access Enforcement 43](#ac-3-access-enforcement)

[AC-4 -- Information Flow Enforcement
45](#ac-4-information-flow-enforcement)

[AC-5 -- Separation of Duties 46](#ac-5-separation-of-duties)

[AC-5 Assignment of Security Responsibilities
47](#ac-5-assignment-of-security-responsibilities)

[AC-5 Separation of Duties Implementation
47](#ac-5-separation-of-duties-implementation)

[AC-6 -- Least Privilege 48](#ac-6-least-privilege)

[AC-7 -- Unsuccessful Login Attempts
49](#ac-7-unsuccessful-login-attempts)

[AC-7 Account Lockout Policy 49](#ac-7-account-lockout-policy)

[AC-7 Account Lockout Application 50](#ac-7-account-lockout-application)

[AC-7 Additional Account Lockout Minimum Standards
50](#ac-7-additional-account-lockout-minimum-standards)

[AC-8 -- System Use Notification 50](#ac-8-system-use-notification)

[AC-8 Primary Warning Banners 51](#ac-8-primary-warning-banners)

[AC-9 -- Previous Logon Notification
53](#ac-9-previous-logon-notification)

[AC-10 -- Concurrent Session Control
53](#ac-10-concurrent-session-control)

[AC-11 -- Session Lock 53](#ac-11-session-lock)

[AC-12 -- Session Termination 54](#ac-12-session-termination)

[AC-13 -- Supervision and Review -- Access Control
54](#ac-13-supervision-and-review-access-control)

[AC-14 -- Permitted Actions without Identification or Authentication
55](#ac-14-permitted-actions-without-identification-or-authentication)

[AC-15 -- Automated Marking 56](#ac-15-automated-marking)

[AC-16 -- Automated Labeling 56](#ac-16-automated-labeling)

[AC-17 -- Remote Access 57](#ac-17-remote-access)

[AC-17 Teleworking 58](#ac-17-teleworking)

[AC-17 Remote Access and PII 58](#ac-17-remote-access-and-pii)

[AC-18 -- Wireless Access Restrictions
60](#ac-18-wireless-access-restrictions)

[AC-18 Wireless Access and Networking
61](#ac-18-wireless-access-and-networking)

[AC-19 -- Access Control for Portable and Mobile Devices
62](#ac-19-access-control-for-portable-and-mobile-devices)

[AC-20 -- Use of External Information Systems
63](#ac-20-use-of-external-information-systems)

[AC-20 Use of DOI IT Resources 65](#ac-20-use-of-doi-it-resources)

[AC-20 Use of Personally-Owned and Contractor-Owned Equipment
65](#ac-20-use-of-personally-owned-and-contractor-owned-equipment)

[AC-20 Requirements for the Use of Contractor-Owned Equipment
65](#ac-20-requirements-for-the-use-of-contractor-owned-equipment)

[Awareness and Training (AT) 66](#awareness-and-training-at)

[AT-1 -- Security Awareness and Training Policy and Procedures
66](#at-1-security-awareness-and-training-policy-and-procedures)

[AT-2 -- Security Awareness 67](#at-2-security-awareness)

[AT-3 -- Security Training 67](#at-3-security-training)

[AT-3 IT Security Awareness and Training Materials
67](#at-3-it-security-awareness-and-training-materials)

[AT-3 IT Security Awareness and Training Process
67](#at-3-it-security-awareness-and-training-process)

[AT-3 Training Requirement Exemptions
68](#at-3-training-requirement-exemptions)

[AT-3 Training Non-Compliance 68](#at-3-training-non-compliance)

[AT-3 Specialized or Role-Based IT Security Training
68](#at-3-specialized-or-role-based-it-security-training)

[AT-3 Roles Requiring Specialized Training
69](#at-3-roles-requiring-specialized-training)

[AT-3 Training Topics and Learning Levels
71](#at-3-training-topics-and-learning-levels)

[AT-3 Professional Security Certifications
71](#at-3-professional-security-certifications)

[AT-4 -- Security Training Records 71](#at-4-security-training-records)

[AT-4 Tracking and Reporting Awareness and Specialized Training
71](#at-4-tracking-and-reporting-awareness-and-specialized-training)

[AT-5 -- Contacts with Security Groups and Associations
72](#at-5-contacts-with-security-groups-and-associations)

[Audit and Accountability (AU) 73](#audit-and-accountability-au)

[AU-1 -- Audit and Accountability Policy and Procedures
73](#au-1-audit-and-accountability-policy-and-procedures)

[AU-1 Audit Trail Requirements 74](#au-1-audit-trail-requirements)

[AU-2 -- Auditable Events 74](#au-2-auditable-events)

[AU-3 -- Content of Audit Records 75](#au-3-content-of-audit-records)

[AU-3 PII Audit Extracts 76](#au-3-pii-audit-extracts)

[AU-4 -- Audit Storage Capacity 76](#au-4-audit-storage-capacity)

[AU-5 -- Response to Audit Processing Failures
77](#au-5-response-to-audit-processing-failures)

[AU-6 -- Audit Monitoring, Analysis and Reporting
77](#au-6-audit-monitoring-analysis-and-reporting)

[AU-7 -- Audit Reduction and Report Generation
78](#au-7-audit-reduction-and-report-generation)

[AU-8 -- Time Stamps 78](#au-8-time-stamps)

[AU-9 -- Protection of Audit Information
79](#au-9-protection-of-audit-information)

[AU-10 -- Non-Repudiation 80](#au-10-non-repudiation)

[AU-11 -- Audit Retention 80](#au-11-audit-retention)

[Certification, Accreditation, and Security Assessment (CA)
81](#certification-accreditation-and-security-assessment-ca)

[CA-1 -- Certification, Accreditation and Security Assessment Policies
and Procedures
81](#ca-1-certification-accreditation-and-security-assessment-policies-and-procedures)

[CA-1 C&A Implementation Methodology
82](#ca-1-ca-implementation-methodology)

[CA-1 Certification and Accreditation Requirement
92](#ca-1-certification-and-accreditation-requirement)

[CA-1 Certification and Accreditation Frequency
92](#ca-1-certification-and-accreditation-frequency)

[CA-1 IT System Accreditation Boundary
92](#ca-1-it-system-accreditation-boundary)

[CA-1 Certification and Accreditation Key Roles
94](#ca-1-certification-and-accreditation-key-roles)

[CA-2 -- Security Assessments 98](#ca-2-security-assessments)

[CA-2 Bureau or Office Program and System Self-Assessments
99](#ca-2-bureau-or-office-program-and-system-self-assessments)

[CA-2 DOI Compliance Reviews 101](#ca-2-doi-compliance-reviews)

[CA-2 DOI Security Documentation Compliance Reviews
102](#ca-2-doi-security-documentation-compliance-reviews)

[CA-2 Security Test and Evaluation (ST&E)
104](#ca-2-security-test-and-evaluation-ste)

[CA-3 -- Information System Connections
107](#ca-3-information-system-connections)

[CA-4 -- Security Certification 107](#ca-4-security-certification)

[CA-4 IT Security Accreditation Package Documents
108](#ca-4-it-security-accreditation-package-documents)

[CA-5 -- Plan of Action and Milestones
110](#ca-5-plan-of-action-and-milestones)

[CA-5 Plan of Actions and Milestones (POA&M) Contents
110](#ca-5-plan-of-actions-and-milestones-poam-contents)

[CA-5 Plan of Actions and Milestones (POA&M) Management
110](#ca-5-plan-of-actions-and-milestones-poam-management)

[CA-5 Reporting Findings from Audits, Compliance Reviews or
Self-Assessments
111](#ca-5-reporting-findings-from-audits-compliance-reviews-or-self-assessments)

[CA-6 -- Security Accreditation 111](#ca-6-security-accreditation)

[CA-6 Accreditation Decisions 111](#ca-6-accreditation-decisions)

[CA-6 Security Accreditation Decision Letter
112](#ca-6-security-accreditation-decision-letter)

[CA-7 -- Continuous Monitoring 113](#ca-7-continuous-monitoring)

[Configuration Management (CM) 114](#configuration-management-cm)

[CM-1 -- Configuration Management Policy and Procedures
114](#cm-1-configuration-management-policy-and-procedures)

[CM-2 -- Baseline Configuration 114](#cm-2-baseline-configuration)

[CM-2 C&A Boundary Inventory Management
115](#cm-2-ca-boundary-inventory-management)

[CM-3 -- Configuration Change Control
115](#cm-3-configuration-change-control)

[CM-3 Security Patch Management Program
116](#cm-3-security-patch-management-program)

[CM-4 -- Monitoring Configuration Changes
120](#cm-4-monitoring-configuration-changes)

[CM-5 -- Access Restrictions for Change
121](#cm-5-access-restrictions-for-change)

[CM-6 -- Configuration Settings 121](#cm-6-configuration-settings)

[CM-6 Secure System Configurations
122](#cm-6-secure-system-configurations)

[CM-7 -- Least Functionality 122](#cm-7-least-functionality)

[CM-8 -- Information System Component Inventory
123](#cm-8-information-system-component-inventory)

[Contingency Planning (CP) 125](#contingency-planning-cp)

[CP-1 -- Contingency Planning Policy and Procedures
125](#cp-1-contingency-planning-policy-and-procedures)

[CP-1 Minimum Contingency Planning Procedures
126](#cp-1-minimum-contingency-planning-procedures)

[CP-2 -- Contingency Plan 126](#cp-2-contingency-plan)

[CP-3 -- Contingency Training 126](#cp-3-contingency-training)

[CP-4 -- Contingency Plan Testing and Exercises
127](#cp-4-contingency-plan-testing-and-exercises)

[CP-5 -- Contingency Plan Update 128](#cp-5-contingency-plan-update)

[CP-6 -- Alternate Storage Site 129](#cp-6-alternate-storage-site)

[CP-7 -- Alternate Processing Site 129](#cp-7-alternate-processing-site)

[CP-8 -- Telecommunication Services
130](#cp-8-telecommunication-services)

[CP-9 -- Information System Backup 131](#cp-9-information-system-backup)

[CP-10 -- Information System Recovery and Reconstitution
132](#cp-10-information-system-recovery-and-reconstitution)

[Identification and Authentication (IA)
134](#identification-and-authentication-ia)

[IA-1 -- Identification and Authentication Policy and Procedures
134](#ia-1-identification-and-authentication-policy-and-procedures)

[IA-2 -- User Identification and Authentication
135](#ia-2-user-identification-and-authentication)

[IA-2 Use of PIV Cards 136](#ia-2-use-of-piv-cards)

[IA-2 User Authentication for E-Government Transactions
136](#ia-2-user-authentication-for-e-government-transactions)

[IA-3 -- Device Identification and Authentication
136](#ia-3-device-identification-and-authentication)

[IA-4 -- Identifier Management 137](#ia-4-identifier-management)

[IA-4 Identifier Management 137](#ia-4-identifier-management-1)

[IA-5 -- Authenticator Management 138](#ia-5-authenticator-management)

[IA-6 -- Authentication Feedback 140](#ia-6-authentication-feedback)

[IA-7 -- Cryptographic Module Authentication
140](#ia-7-cryptographic-module-authentication)

[Incident Response (IR) 141](#incident-response-ir)

[IR-1 -- Incident Response Policy and Procedures
141](#ir-1-incident-response-policy-and-procedures)

[IR-1 Incident Response Capability
142](#ir-1-incident-response-capability)

[IR-2 -- Incident Response Training
142](#ir-2-incident-response-training)

[IR-3 -- Incident Response Testing and Exercises
143](#ir-3-incident-response-testing-and-exercises)

[IR-4 -- Incident Handling 143](#ir-4-incident-handling)

[IR-5 -- Incident Monitoring 144](#ir-5-incident-monitoring)

[IR-5 Monitoring and Detecting Incidents
144](#ir-5-monitoring-and-detecting-incidents)

[IR-6 -- Incident Reporting 145](#ir-6-incident-reporting)

[IR-6 Reporting Incidents to Law Enforcement
145](#ir-6-reporting-incidents-to-law-enforcement)

[IR-6 Adverse Event or Reportable Incident
146](#ir-6-adverse-event-or-reportable-incident)

[IR-6 Incident Reporting Event Categories
146](#ir-6-incident-reporting-event-categories)

[IR-6 Incident Prioritization 148](#ir-6-incident-prioritization)

[IR-6 Incident Reporting Format 150](#ir-6-incident-reporting-format)

[IR-6 Chain of Custody 152](#ir-6-chain-of-custody)

[IR-7 -- Incident Response Assistance
153](#ir-7-incident-response-assistance)

[IR-7 Additional Incident Response Guidance
153](#ir-7-additional-incident-response-guidance)

[Maintenance (MA) 154](#maintenance-ma)

[MA-1 -- System Maintenance Policy and Procedures
154](#ma-1-system-maintenance-policy-and-procedures)

[MA-2 -- Controlled Maintenance 154](#ma-2-controlled-maintenance)

[MA-3 -- Maintenance Tools 156](#ma-3-maintenance-tools)

[MA-4 -- Remote Maintenance 157](#ma-4-remote-maintenance)

[MA-5 -- Maintenance Personnel 158](#ma-5-maintenance-personnel)

[MA-6 -- Timely Maintenance 159](#ma-6-timely-maintenance)

[Media Protection (MP) 160](#media-protection-mp)

[MP-1 -- Media Protection Policy and Procedures
160](#mp-1-media-protection-policy-and-procedures)

[MP-1 Information Protection Measures
160](#mp-1-information-protection-measures)

[MP-1 Electronic Transmission of Sensitive Information
161](#mp-1-electronic-transmission-of-sensitive-information)

[MP-1 Protection of Classified or National Security Information
161](#mp-1-protection-of-classified-or-national-security-information)

[MP-2 -- Media Access 161](#mp-2-media-access)

[MP-3 -- Media Labeling 162](#mp-3-media-labeling)

[MP-3 Sensitive but Unclassified (SBU), and For Official Use Only (FOUO)
Designations
162](#mp-3-sensitive-but-unclassified-sbu-and-for-official-use-only-fouo-designations)

[MP-4 -- Media Storage 163](#mp-4-media-storage)

[MP-5 -- Media Transport 164](#mp-5-media-transport)

[MP-6 -- Media Sanitization and Disposal
166](#mp-6-media-sanitization-and-disposal)

[Physical and Environmental Protection (PE)
168](#physical-and-environmental-protection-pe)

[PE-1 -- Physical and Environmental Protection Policy and Procedures
168](#pe-1-physical-and-environmental-protection-policy-and-procedures)

[PE-1 Physical and Environmental Protection Controls Implementation
169](#pe-1-physical-and-environmental-protection-controls-implementation)

[PE-2 -- Physical Access Authorizations
169](#pe-2-physical-access-authorizations)

[PE-3 -- Physical Access Control 169](#pe-3-physical-access-control)

[PE-4 -- Access Control for Transmission Medium
171](#pe-4-access-control-for-transmission-medium)

[PE-5 -- Access Control for Display Medium
172](#pe-5-access-control-for-display-medium)

[PE-6 -- Monitoring Physical Access
172](#pe-6-monitoring-physical-access)

[PE-7 -- Visitor Control 173](#pe-7-visitor-control)

[PE-8 -- Access Records 173](#pe-8-access-records)

[PE-9 -- Power Equipment and Power Cabling
174](#pe-9-power-equipment-and-power-cabling)

[PE-10 -- Emergency Shutoff 174](#pe-10-emergency-shutoff)

[PE-11 -- Emergency Power 175](#pe-11-emergency-power)

[PE-12 -- Emergency Lighting 175](#pe-12-emergency-lighting)

[PE-13 -- Fire Protection 175](#pe-13-fire-protection)

[PE-14 -- Temperature and Humidity Controls
176](#pe-14-temperature-and-humidity-controls)

[PE-15 -- Water Damage Protection 176](#pe-15-water-damage-protection)

[PE-16 -- Delivery and Removal 177](#pe-16-delivery-and-removal)

[PE-17 -- Alternate Work Site 177](#pe-17-alternate-work-site)

[PE-18 -- Location of Information System Components
178](#pe-18-location-of-information-system-components)

[PE-19 -- Information Leakage 178](#pe-19-information-leakage)

[Planning (PL) 179](#planning-pl)

[PL-1 -- Security Planning Policy and Procedures
179](#pl-1-security-planning-policy-and-procedures)

[PL-1 Bureau and Office IT Security Program Plans
179](#pl-1-bureau-and-office-it-security-program-plans)

[PL-2 -- System Security Plan 180](#pl-2-system-security-plan)

[PL-2 IT System Security Plan Overview
180](#pl-2-it-system-security-plan-overview)

[PL-2 Compliance -- IT System Security Plan Elements
181](#pl-2-compliance-it-system-security-plan-elements)

[PL-3 -- System Security Plan Update
181](#pl-3-system-security-plan-update)

[PL-4 -- Rules of Behavior 182](#pl-4-rules-of-behavior)

[PL-4 Rules of Behavior Contents 182](#pl-4-rules-of-behavior-contents)

[PL-4 Rules of Behavior Compliance Monitoring
183](#pl-4-rules-of-behavior-compliance-monitoring)

[PL-5 -- Privacy Impact Assessments (PIAs)
183](#pl-5-privacy-impact-assessments-pias)

[PL-6 -- Security Related Activity Planning
184](#pl-6-security-related-activity-planning)

[Personnel Security (PS) 185](#personnel-security-ps)

[PS-1 -- Personnel Security Policy and Procedures
185](#ps-1-personnel-security-policy-and-procedures)

[PS-2 -- Position Categorization 186](#ps-2-position-categorization)

[PS-2 Position Designations of Personnel (Federal and Contractor)
186](#ps-2-position-designations-of-personnel-federal-and-contractor)

[PS-3 -- Personnel Screening 186](#ps-3-personnel-screening)

[PS-4 -- Personnel Termination 186](#ps-4-personnel-termination)

[PS-5 -- Personnel Transfer 188](#ps-5-personnel-transfer)

[PS-6 -- Access Agreements 189](#ps-6-access-agreements)

[PS-7 -- Third-Party Personnel Security
189](#ps-7-third-party-personnel-security)

[PS-7 Effective Administration of Contract Staff
189](#ps-7-effective-administration-of-contract-staff)

[PS-8 -- Personnel Sanctions 198](#ps-8-personnel-sanctions)

[Risk Assessment (RA) 199](#risk-assessment-ra)

[RA-1 -- Risk Assessment Policy and Procedures
199](#ra-1-risk-assessment-policy-and-procedures)

[RA-1 DOI Risk Assessment Methodology
200](#ra-1-doi-risk-assessment-methodology)

[RA-2 -- Security Categorization 200](#ra-2-security-categorization)

[RA-2 Analyzing System and Information Security Category Impact Levels
200](#ra-2-analyzing-system-and-information-security-category-impact-levels)

[RA-2 Sensitive Information 201](#ra-2-sensitive-information)

[RA-2 Personally Identifiable Information
202](#ra-2-personally-identifiable-information)

[RA-3 -- Risk Assessment 205](#ra-3-risk-assessment)

[RA-3 Risk Assessments Frequency 206](#ra-3-risk-assessments-frequency)

[RA-3 Conducting the Risk Assessment
206](#ra-3-conducting-the-risk-assessment)

[RA-4 -- Risk Assessment Update 206](#ra-4-risk-assessment-update)

[RA-4 Significant Change 207](#ra-4-significant-change)

[RA-5 -- Vulnerability Scanning 207](#ra-5-vulnerability-scanning)

[RA-5 Internal Scanning Programs 208](#ra-5-internal-scanning-programs)

[RA-5 Penetration Testing Guidelines
208](#ra-5-penetration-testing-guidelines)

[System and Services Acquisition (SA)
210](#system-and-services-acquisition-sa)

[SA-1 -- System and Services Acquisition Policy and Procedures
210](#sa-1-system-and-services-acquisition-policy-and-procedures)

[SA-1 Acquisition of Security-Related Products and Services
Considerations
211](#sa-1-acquisition-of-security-related-products-and-services-considerations)

[SA-2 -- Allocation of Resources 211](#sa-2-allocation-of-resources)

[SA-2 IT System Finding Considerations
211](#sa-2-it-system-finding-considerations)

[SA-3 -- Life Cycle Support 212](#sa-3-life-cycle-support)

[SA-3 IT System Life Cycle Phases
212](#sa-3-it-system-life-cycle-phases)

[SA-4 -- Acquisitions 213](#sa-4-acquisitions)

[SA-4 Configuration Settings and Implementation Guidance
215](#sa-4-configuration-settings-and-implementation-guidance)

[SA-4 Contractor Operations 215](#sa-4-contractor-operations)

[SA-4 Requirements for Contractor Operations
215](#sa-4-requirements-for-contractor-operations)

[SA-5 -- Information System Documentation
217](#sa-5-information-system-documentation)

[SA-5 System Documentation Minimum Requirements
218](#sa-5-system-documentation-minimum-requirements)

[SA-5 System Documentation Changes
218](#sa-5-system-documentation-changes)

[SA-6 -- Software Usage Restrictions
218](#sa-6-software-usage-restrictions)

[SA-6 Software Use Policy and Provisions for Copyrighted Software
219](#sa-6-software-use-policy-and-provisions-for-copyrighted-software)

[SA-7 -- User Installed Software 223](#sa-7-user-installed-software)

[SA-8 -- Security Engineering Principles
223](#sa-8-security-engineering-principles)

[SA-9 -- External Information System Services
224](#sa-9-external-information-system-services)

[SA-10 -- Developer Configuration Management
225](#sa-10-developer-configuration-management)

[SA-10 Configuration Management Provisions for System Developers
225](#sa-10-configuration-management-provisions-for-system-developers)

[SA-11 -- Developer Security Testing
226](#sa-11-developer-security-testing)

[System and Communications Protection (SC)
227](#__RefHeading___Toc193514574)

[SC-1 -- System and Communications Protection Policy and Procedures
228](#sc-1-system-and-communications-protection-policy-and-procedures)

[SC-2 -- Application Partitioning 228](#sc-2-application-partitioning)

[SC-3 -- Security Function Isolation
229](#sc-3-security-function-isolation)

[SC-4 -- Information Remnants 230](#sc-4-information-remnants)

[SC-5 -- Denial of Service Protection
230](#sc-5-denial-of-service-protection)

[SC-6 -- Resource Priority 231](#sc-6-resource-priority)

[SC-7 -- Boundary Protection 231](#sc-7-boundary-protection)

[SC-8 -- Transmission Integrity 232](#sc-8-transmission-integrity)

[SC-9 -- Transmission Confidentiality
233](#sc-9-transmission-confidentiality)

[SC-10 -- Network Disconnect 234](#sc-10-network-disconnect)

[SC-11 -- Trusted Path 234](#sc-11-trusted-path)

[SC-12 -- Cryptographic Key Establishment and Management
234](#sc-12-cryptographic-key-establishment-and-management)

[SC-13 -- Use of Validated Cryptography
234](#sc-13-use-of-validated-cryptography)

[SC-14 -- Public Access Protections
235](#sc-14-public-access-protections)

[SC-15 -- Collaborative Computing 235](#sc-15-collaborative-computing)

[SC-15 Instant Messaging (IM), Internet Relay Chat (IRC), Web
Conferencing, and Peer-to-Peer (P2P) Usage
235](#sc-15-instant-messaging-im-internet-relay-chat-irc-web-conferencing-and-peer-to-peer-p2p-usage)

[SC-15 Emergency Authorizations 236](#sc-15-emergency-authorizations)

[SC-16 -- Transmission of Security Parameters
237](#sc-16-transmission-of-security-parameters)

[SC-17 -- Public key Infrastructure Certificates
237](#sc-17-public-key-infrastructure-certificates)

[SC-18 -- Mobile Code 237](#sc-18-mobile-code)

[SC-18 Mobile Code Implementation
238](#sc-18-mobile-code-implementation)

[SC-19 -- Voice Over Internet Protocol
239](#sc-19-voice-over-internet-protocol)

[SC-20 -- Secure Name/Address Resolution Service (Authoritative Source)
239](#sc-20-secure-nameaddress-resolution-service-authoritative-source)

[SC-21 -- Security Name/Address Resolution Service (Recursive or Caching
Resolver)
240](#sc-21-security-nameaddress-resolution-service-recursive-or-caching-resolver)

[SC-22 -- Architecture and Provisioning for Name/Address Resolution
Service
240](#sc-22-architecture-and-provisioning-for-nameaddress-resolution-service)

[SC-23 -- Session Authenticity 241](#sc-23-session-authenticity)

[System and Information Integrity (SI)
243](#system-and-information-integrity-si)

[SI-1 -- System and Information Integrity Policy and Procedures
243](#si-1-system-and-information-integrity-policy-and-procedures)

[SI-2 -- Flaw Remediation 244](#si-2-flaw-remediation)

[SI-3 -- Malicious Code Protection 245](#si-3-malicious-code-protection)

[SI-4 -- Information System Monitoring Tools and Techniques
246](#si-4-information-system-monitoring-tools-and-techniques)

[SI-5 -- Security Alerts and Advisories
247](#si-5-security-alerts-and-advisories)

[SI-6 -- Security Functionality Verification
248](#si-6-security-functionality-verification)

[SI-7 -- Software and Information Integrity
249](#si-7-software-and-information-integrity)

[SI-8 -- Spam Protection 250](#si-8-spam-protection)

[SI-9 -- Information Input Restrictions
251](#si-9-information-input-restrictions)

[SI-10 -- Information Input Accuracy, Completeness, Validity and
Authenticity
251](#si-10-information-input-accuracy-completeness-validity-and-authenticity)

[SI-11 -- Error Handling 252](#si-11-error-handling)

[SI-12 -- Information Output Handling and Retention
253](#si-12-information-output-handling-and-retention)

[Standards 254](#standards)

[ACCEPTABLE USE SECURITY STANDARD
255](#acceptable-use-security-standard)

[Mandatory Standard Guidelines 255](#mandatory-standard-guidelines)

[Standard Detail 255](#standard-detail)

[AUDIT SECURITY STANDARD 260](#audit-security-standard)

[Mandatory Standard Guidelines 260](#mandatory-standard-guidelines-1)

[Standard Detail 260](#standard-detail-1)

[Security Audit 260](#security-audit)

[Security Audit Follow-Up 261](#security-audit-follow-up)

[Notice of Finding and Recommendations
261](#notice-of-finding-and-recommendations)

[AUTHORIZATION and ACCESS CONTROL SECURITY STANDARD
262](#__RefHeading___Toc193514624)

[Mandatory Standard Guidelines 262](#mandatory-standard-guidelines-2)

[Standard Detail 262](#standard-detail-2)

[Authorization and Access Guidelines
262](#authorization-and-access-guidelines)

[User Account and Password Guidelines
262](#user-account-and-password-guidelines)

[CONTINGENCY and DISASTER RECOVERY SECURITY STANDARD
268](#contingency-and-disaster-recovery-security-standard)

[Mandatory Standard Guidelines 268](#mandatory-standard-guidelines-3)

[Standard Detail 268](#standard-detail-3)

[DATA MANAGEMENT SECURITY STANDARD
271](#data-management-security-standard)

[Mandatory Standard Guidelines 271](#mandatory-standard-guidelines-4)

[Standard Detail 271](#standard-detail-4)

[FIREWALL MANAGEMENT SECURITY STANDARD
275](#firewall-management-security-standard)

[Mandatory Standard Guidelines 275](#mandatory-standard-guidelines-5)

[GOVERNMENT-OWNED COMPUTERS AND PED SECURITY STANDARD
276](#government-owned-computers-and-ped-security-standard)

[Mandatory Standard Guidelines 276](#mandatory-standard-guidelines-6)

[Standard Detail 276](#standard-detail-5)

[INFORMATION CLASSIFICATION SECURITY STANDARD
281](#information-classification-security-standard)

[Mandatory Standard Guidelines 281](#mandatory-standard-guidelines-7)

[Standard Detail 281](#standard-detail-6)

[INTRUSION DETECTION MANAGEMENT SECURITY STANDARD
285](#intrusion-detection-management-security-standard)

[Mandatory Standard Guidelines 285](#mandatory-standard-guidelines-8)

[Standard Detail 285](#standard-detail-7)

[MEDIA SANITIZATION and DISPOSAL SECURITY STANDARD
287](#media-sanitization-and-disposal-security-standard)

[Mandatory Standard Guidelines 287](#mandatory-standard-guidelines-9)

[Standard Detail 287](#standard-detail-8)

[NETWORK ACCESS SECURITY STANDARD
290](#network-access-security-standard)

[Mandatory Standard Guidelines 290](#mandatory-standard-guidelines-10)

[Standard Detail 290](#standard-detail-9)

[NON-GOVERNMENT OWNED COMPUTER AND PED SECURITY STANDARD
296](#non-government-owned-computer-and-ped-security-standard)

[Mandatory Standard Guidelines 296](#mandatory-standard-guidelines-11)

[PATCH MANAGEMENT SECURITY STANDARD
298](#patch-management-security-standard)

[Mandatory Standard Guidelines 298](#mandatory-standard-guidelines-12)

[Standard Detail 298](#standard-detail-10)

[ROUTER AND SWITCH MANAGEMENT SECURITY STANDARD
300](#router-and-switch-management-security-standard)

[SECURITY ARCHITECTURE FRAMEWORK MANAGEMENT SECURITY STANDARD
301](#security-architecture-framework-management-security-standard)

[Mandatory Standard Guidelines 301](#mandatory-standard-guidelines-13)

[Standard Detail 301](#standard-detail-11)

[SERVER MANAGEMENT SECURITY STANDARD
302](#server-management-security-standard)

[Mandatory Standard Guidelines 302](#mandatory-standard-guidelines-14)

[Standard Detail 302](#standard-detail-12)

[SYSTEMS DEVELOPMENT LIFE CYCLE SECURITY STANDARD
306](#systems-development-life-cycle-security-standard)

[Mandatory Standard Guidelines 306](#mandatory-standard-guidelines-15)

[Standard Detail 306](#standard-detail-13)

[VIRUS PROTECTION SECURITY STANDARD
310](#virus-protection-security-standard)

[Mandatory Standard Guidelines 310](#mandatory-standard-guidelines-16)

[Standard Detail 310](#standard-detail-14)

[VULNERABILITY SCAN SECURITY STANDARD
312](#vulnerability-scan-security-standard)

[Mandatory Standard Guidelines 312](#mandatory-standard-guidelines-17)

[Standard Detail 312](#standard-detail-15)

[Appendices 314](#appendices)

[Appendix A - Glossary of Information Security Terms
315](#appendix-a---glossary-of-information-security-terms)

[Appendix B - NETWORK PERIMETER SECURITY STANDARD
375](#appendix-b---network-perimeter-security-standard)

[Introduction 375](#introduction)

[References 375](#references)

[Scope 375](#scope-2)

[Responsibilities 376](#responsibilities)

[Procedures 377](#procedures-1)

[Firewall Implementation Guidelines
377](#firewall-implementation-guidelines)

[DMZ Configuration 378](#dmz-configuration)

[Registering Public Servers 379](#registering-public-servers)

[Intrusion Detection 379](#intrusion-detection)

[Network Sharing and Trust Relationships with Non-DOI Entities
380](#network-sharing-and-trust-relationships-with-non-doi-entities)

[Virtual Private Exchange (VPX) 380](#virtual-private-exchange-vpx)

[Other Perimeter Security Equipment
381](#other-perimeter-security-equipment)

[Internal Security Perimeter 381](#internal-security-perimeter)

[Network Assurance Testing 381](#network-assurance-testing)

[Network Vulnerability Testing 381](#network-vulnerability-testing)

[Patches 382](#patches)

[NETWORK PERIMETER SECURITY STANDARD - Appendix A
382](#network-perimeter-security-standard---appendix-a)

[NETWORK PERIMETER SECURITY STANDARD - DMZ-Internal Rules
384](#network-perimeter-security-standard---dmz-internal-rules)

[NETWORK PERIMETER SECURITY STANDARD - Internet-Internal Rules
385](#network-perimeter-security-standard---internet-internal-rules)

[NETWORK PERIMETER SECURITY STANDARD - Appendix B -- Dual Firewall
Architecture
387](#network-perimeter-security-standard---appendix-b-dual-firewall-architecture)

[Appendix C 388](#appendix-c)

[Wireless Security Technical Implementation Guide (Version 2.0, July 15,
2005) 388](#__RefHeading___Toc193514697)

[Introduction 388](#introduction-1)

[WLAN Security Features 388](#wlan-security-features)

[Wired Equivalent Privacy Encryption
389](#wired-equivalent-privacy-encryption)

[MAC Address Filtering 389](#mac-address-filtering)

[Enhancing WLAN Security 389](#enhancing-wlan-security)

[Network Compartmentalization 389](#network-compartmentalization)

[Rapid WEP Rekeying 390](#rapid-wep-rekeying)

[Virtual Private Networks (VPNs) 390](#virtual-private-networks-vpns)

[Physical Controls 390](#physical-controls)

[Summary 390](#summary)

[Intended Audience 390](#intended-audience)

[Naming Conventions 391](#naming-conventions)

[Requirements 391](#requirements)

[Introduction 391](#introduction-2)

[Physical Access 392](#physical-access)

[System Access 394](#system-access)

[Identification 394](#identification)

[Client Station or User 395](#client-station-or-user)

[Authentication 396](#authentication)

[WLAN 396](#wlan)

[Client Station or User 397](#client-station-or-user-1)

[Network Compartmentalization 400](#network-compartmentalization-1)

[Management Server Interfaces 401](#management-server-interfaces)

[Simple Network Management Protocol (SNMP)
402](#simple-network-management-protocol-snmp)

[802.1x - Port-based Network Access Control
403](#x---port-based-network-access-control)

[Encryption 403](#encryption)

[WEP (Wired Equivalent Privacy) and Enhanced 802.11i Encryption
404](#wep-wired-equivalent-privacy-and-enhanced-802.11i-encryption)

[Session Encryption 405](#session-encryption)

[Integrity Protection 406](#integrity-protection)

[WLAN Integrity 406](#wlan-integrity)

[Data Integrity 406](#data-integrity)

[Client Station and Server Integrity
407](#client-station-and-server-integrity)

[Information Handling 407](#information-handling)

[Auditing 407](#auditing)

[Availability Protection 408](#availability-protection)

[Redundancy 409](#redundancy)

[Critical System Parameter Recovery Information
409](#critical-system-parameter-recovery-information)

[Data Backup and Recovery 409](#data-backup-and-recovery)

[Power Protection 410](#power-protection)

[Anti-Virus 410](#anti-virus)

[Bluetooth 411](#bluetooth)

[Link Key Generation---Bluetooth Bonding
412](#link-key-generationbluetooth-bonding)

[Management 412](#management)

[Technical 412](#technical)

[Operational 413](#operational)

[Handheld Devices 413](#handheld-devices)

[Management 413](#management-1)

[Technical 414](#technical-1)

[Checklist for WLANs 414](#checklist-for-wlans)

[Requirements (RQ) 414](#requirements-rq)

[System Access 415](#system-access-1)

[Encryption 419](#encryption-1)

[Availability Protection 421](#availability-protection-1)

[Suggested Considerations 421](#suggested-considerations)

[Remote Access 422](#remote-access-3)

[Simple Network Management Protocol (SNMP)
423](#simple-network-management-protocol-snmp-2)

[Wireless Ethernet Security Tools
424](#wireless-ethernet-security-tools)

[Checklist for Bluetooth 426](#checklist-for-bluetooth)

[Checklist for Handhelds 427](#checklist-for-handhelds)

[Suggested Considerations 427](#suggested-considerations-2)

[Appendix D 429](#appendix-d)

[Disk and Data Sanitization Policy, Guidance, and Procedures (September
2007)
429](#disk-and-data-sanitization-policy-guidance-and-procedures-september-2007)

[PURPOSE 429](#purpose)

[SCOPE 429](#scope-3)

[BACKGROUND 430](#background)

[REFERENCES 430](#references-1)

[RESPONSIBILITIES 430](#responsibilities-1)

[EXPLANATION OF SECURITY RISKS 430](#explanation-of-security-risks)

[Guidance 431](#guidance)

[Recommended Guidance for the Sanitization of Other Computer Storage
Media
434](#recommended-guidance-for-the-sanitization-of-other-computer-storage-media)

[Appendix E -- Certification and Request for Determination of
Non-Sensitive Data
437](#appendix-e-certification-and-request-for-determination-of-non-sensitive-data)

# Table of Figures:

[Figure 1: Essential Information Technology Security Program Components
8](#__RefHeading___Toc193514769)

[Figure 1: Warning Banner for Non-Trust Systems
52](#__RefHeading___Toc193514770)

[Figure 2: Warning Banner for Trust Systems
53](#__RefHeading___Toc193514771)

[Figure 4: Weaknesses & Contractor Procedures
217](#__RefHeading___Toc193514772)

# Tables:

[Table 1: OMB Published Directives 4](#__RefHeading___Toc193514773)

[Table 2: Applicable Laws, Guidelines, Regulation, and Guidance
Directives 6](#__RefHeading___Toc193514774)

[Table 3: Security Control Classes, Families, and Identifiers
29](#__RefHeading___Toc193514775)

[Table 4: Access Controls 40](#__RefHeading___Toc193514776)

[Table 5: AC-2 -- Account Management Mandatory Policy Enhancement(s):
41](#__RefHeading___Toc193514777)

[Table 6: AC-3 -- Access Enforcement Mandatory Policy Enhancement(s)
44](#__RefHeading___Toc193514778)

[Table 7: AC-4 -- Information Flow Enforcement Recommended Policy
Enhancement(s) 45](#__RefHeading___Toc193514779)

[Table 8: AC-7 -- Unsuccessful Login Attempts Recommended Policy
Enhancement(s) 49](#__RefHeading___Toc193514780)

[Table 9: AC-12 -- Session Termination Mandatory Policy Enhancement(s)
54](#__RefHeading___Toc193514781)

[Table 10: AC-13 -- Supervision and Review -- Access Control Mandatory
Policy Enhancement(s) 55](#__RefHeading___Toc193514782)

[Table 11: AC-14 -- Permitted Actions without Identification or
Authentication Mandatory Policy Enhancement(s)
55](#__RefHeading___Toc193514783)

[Table 12: AC-17 -- Remote Access Mandatory Policy Enhancement(s)
57](#__RefHeading___Toc193514784)

[Table 13: AC-18 -- Wireless Access Restrictions Mandatory Policy
Enhancement(s) 61](#__RefHeading___Toc193514785)

[Table 14: AC-20 -- Use of External Information Systems Mandatory Policy
Enhancement(s) 64](#__RefHeading___Toc193514786)

[Table 15: Awareness and Training Controls
66](#__RefHeading___Toc193514787)

[Table 16: Audit and Accountability Controls
73](#__RefHeading___Toc193514788)

[Table 17: AU-2 -- Auditable Events Mandatory Policy Enhancement(s)
75](#__RefHeading___Toc193514789)

[Table 18: AU-3 -- Content of Audit Records Mandatory Policy
Enhancement(s) 76](#__RefHeading___Toc193514790)

[Table 19: AU-5 -- Response to Audit Processing Failures Mandatory
Policy Enhancement(s) 77](#__RefHeading___Toc193514791)

[Table 20: AU-6 -- Audit Monitoring, Analysis and Reporting Mandatory
Policy Enhancement(s) 78](#__RefHeading___Toc193514792)

[Table 21: AU-7 -- Audit Reduction and Report Generation Mandatory
Policy Enhancement(s) 78](#__RefHeading___Toc193514793)

[Table 22: AU-8 -- Time Stamps Mandatory Policy Enhancement(s)
79](#__RefHeading___Toc193514794)

[Table 23: AU-9 -- Protection of Audit Information Recommended Policy
Enhancement(s) 79](#__RefHeading___Toc193514795)

[Table 24: Certification, Accreditation, and Security Assessment
Controls 81](#__RefHeading___Toc193514796)

[Table 25: CA-4 -- Security Certification Mandatory Policy
Enhancement(s) 108](#__RefHeading___Toc193514797)

[Table 26: Configuration Management Controls
114](#__RefHeading___Toc193514798)

[Table 27: CM-2 -- Baseline Configuration Mandatory Policy
Enhancement(s) 115](#__RefHeading___Toc193514799)

[Table 28: CM-3 -- Configuration Change Control Mandatory Policy
Enhancement(s) 116](#__RefHeading___Toc193514800)

[Table 29: CM-5 -- Access Restrictions for Change Mandatory Policy
Enhancement(s) 121](#__RefHeading___Toc193514801)

[Table 30: CM-6 -- Configuration Settings Mandatory Policy
Enhancement(s) 122](#__RefHeading___Toc193514802)

[Table 31: CM-7 -- Least Functionality Mandatory Policy Enhancement(s)
123](#__RefHeading___Toc193514803)

[Table 32: CM-8 -- Information System Component Inventory Mandatory
Policy Enhancement(s) 123](#__RefHeading___Toc193514804)

[Table 33: Contingency Planning Controls
125](#__RefHeading___Toc193514805)

[Table 34: CP-2 -- Contingency Plan Mandatory Policy Enhancement(s)
126](#__RefHeading___Toc193514806)

[Table 35: CP-3 -- Contingency Training Mandatory Policy Enhancement(s)
127](#__RefHeading___Toc193514807)

[Table 36: CP-3 -- Contingency Training Recommended Policy
Enhancement(s) 127](#__RefHeading___Toc193514808)

[Table 37: CP-4 -- Contingency Plan Testing and Exercises Mandatory
Policy Enhancement(s) 128](#__RefHeading___Toc193514809)

[Table 38: CP-4 -- Contingency Plan Testing and Exercises Recommended
Policy Enhancement(s) 128](#__RefHeading___Toc193514810)

[Table 39: CP-6 -- Alternate Storage Site Mandatory Policy
Enhancement(s) 129](#__RefHeading___Toc193514811)

[Table 40: CP-7 -- Alternate Processing Site Mandatory Policy
Enhancement(s) 130](#__RefHeading___Toc193514812)

[Table 41: CP-8 -- Telecommunication Services Mandatory Policy
Enhancement(s) 131](#__RefHeading___Toc193514813)

[Table 42: CP-9 -- Information System Backup Mandatory Policy
Enhancement(s) 132](#__RefHeading___Toc193514814)

[Table 43: CP-10 -- Information System Recovery and Reconstitution
Mandatory Policy Enhancement(s) 132](#__RefHeading___Toc193514815)

[Table 44: Identification and Authentication Controls
134](#__RefHeading___Toc193514816)

[Table 45: IA-2 -- User Identification and Authentication Mandatory
Policy Enhancement(s) 135](#__RefHeading___Toc193514817)

[Table 46: Incident Response Controls 141](#__RefHeading___Toc193514818)

[Table 47: IR-2 -- Incident Response Training Mandatory Policy
Enhancement(s) 143](#__RefHeading___Toc193514819)

[Table 48: IR-2 -- Incident Response Training Recommended Policy
Enhancement(s) 143](#__RefHeading___Toc193514820)

[Table 49: IR-3 -- Incident Response Testing and Exercises Mandatory
Policy Enhancement(s) 143](#__RefHeading___Toc193514821)

[Table 50: IR-4 -- Incident Handling Mandatory Policy Enhancement(s)
144](#__RefHeading___Toc193514822)

[Table 51: IR-5 -- Incident Monitoring Mandatory Policy Enhancement(s)
144](#__RefHeading___Toc193514823)

[Table 52: IR-6 -- Incident Reporting Mandatory Policy Enhancement(s)
145](#__RefHeading___Toc193514824)

[Table 53: Federal Agency Incident Categories -- Defined by NIST Special
Publication 800-61 148](#__RefHeading___Toc193514825)

[Table 54: Effect Rating Definitions -- Defined by NIST Special
Publication 800-61 149](#__RefHeading___Toc193514826)

[Table 55: Criticality Rating Definitions -- Defined by NIST Special
Publication 800-61 149](#__RefHeading___Toc193514827)

[Table 56: Business Impact Rating 150](#__RefHeading___Toc193514828)

[Table 57: IR-7 -- Incident Response Assistance Mandatory Policy
Enhancement(s) 153](#__RefHeading___Toc193514829)

[Table 58: System Maintenance Controls
154](#__RefHeading___Toc193514830)

[Table 59: MA-2 -- Controlled Maintenance Mandatory Policy
Enhancement(s) 155](#__RefHeading___Toc193514831)

[Table 60: MA-3 -- Maintenance Tools Mandatory Policy Enhancement(s)
156](#__RefHeading___Toc193514832)

[Table 61: MA-3 -- Maintenance Tools Recommended Policy Enhancement(s)
156](#__RefHeading___Toc193514833)

[Table 62: MA-4 -- Remote Maintenance Mandatory Policy Enhancement(s)
157](#__RefHeading___Toc193514834)

[Table 63: Media Protection Controls 160](#__RefHeading___Toc193514835)

[Table 64: MP-2 -- Media Access Mandatory Policy Enhancement(s)
162](#__RefHeading___Toc193514836)

[Table 65: MP-5 -- Media Transport Mandatory Policy Enhancement(s)
165](#__RefHeading___Toc193514837)

[Table 66: MP-6 -- Media Sanitization and Disposal Mandatory Policy
Enhancement(s) 166](#__RefHeading___Toc193514838)

[Table 67: Physical and Environmental Protection Controls
168](#__RefHeading___Toc193514839)

[Table 68: PE-3 -- Physical Access Control Mandatory Policy
Enhancement(s) 170](#__RefHeading___Toc193514840)

[Table 69: PE-6 -- Monitoring Physical Access Mandatory Policy
Enhancement(s) 172](#__RefHeading___Toc193514841)

[Table 70: PE-7 -- Visitor Control Mandatory Policy Enhancement(s)
173](#__RefHeading___Toc193514842)

[Table 71: PE-8 -- Access Records Mandatory Policy Enhancement(s)
174](#__RefHeading___Toc193514843)

[Table 72: PE-9 -- Power Equipment and Power Cabling Mandatory Policy
Enhancement(s) 174](#__RefHeading___Toc193514844)

[Table 73: PE-10 -- Emergency Shutoff Mandatory Policy Enhancement(s)
174](#__RefHeading___Toc193514845)

[Table 74: PE-11 -- Emergency Power Mandatory Policy Enhancement(s)
175](#__RefHeading___Toc193514846)

[Table 75: PE-11 -- Emergency Power Recommended Policy Enhancement(s)
175](#__RefHeading___Toc193514847)

[Table 76: PE-13 Fire Protection Mandatory Policy Enhancement(s)
176](#__RefHeading___Toc193514848)

[Table 77: PE-15 -- Water Damage Protection Mandatory Policy
Enhancement(s) 177](#__RefHeading___Toc193514849)

[Table 78: PE-18 -- Location of Information System Components Mandatory
Policy Enhancement(s) 178](#__RefHeading___Toc193514850)

[Table 79: Planning Controls 179](#__RefHeading___Toc193514851)

[Table 80: Personnel Security Controls
185](#__RefHeading___Toc193514852)

[Table 81: Guidelines for Including Information Security Requirements in
Contracts 198](#__RefHeading___Toc193514853)

[Table 82: Risk Assessment Controls 199](#__RefHeading___Toc193514854)

[Table 83: RA-5 Vulnerability Scanning Mandatory Policy Enhancement(s)
208](#__RefHeading___Toc193514855)

[Table 84: RA-5 Vulnerability Scanning Recommended Policy Enhancement(s)
208](#__RefHeading___Toc193514856)

[Table 85: System and Services Acquisition Controls
210](#__RefHeading___Toc193514857)

[Table 86: Integration of Risk Management into the SDLC
213](#__RefHeading___Toc193514858)

[Table 87: SA-4 -- Acquisitions Mandatory Policy Enhancement(s)
214](#__RefHeading___Toc193514859)

[Table 88: SA-5 -- Information System Documentation Mandatory Policy
Enhancement(s) 217](#__RefHeading___Toc193514860)

[Table 89: System and Communications Protection Controls
228](#__RefHeading___Toc193514861)

[Table 90: SC-3 -- Security Function Isolation Recommended Policy
Enhancement(s) 229](#__RefHeading___Toc193514862)

[Table 91: SC-5 -- Denial of Service Protection Recommended Policy
Enhancement(s) 230](#__RefHeading___Toc193514863)

[Table 92: SC-7 -- Boundary Protection Mandatory Policy Enhancement(s)
232](#__RefHeading___Toc193514864)

[Table 93: SC-8 -- Transmission Integrity Mandatory Policy
Enhancement(s) 233](#__RefHeading___Toc193514865)

[Table 94: SC-9 -- Transmission Confidentiality Mandatory Policy
Enhancement(s) 233](#__RefHeading___Toc193514866)

[Table 95: SC-15 Collaborative Computing Recommended Policy
Enhancement(s) 235](#__RefHeading___Toc193514867)

[Table 96: SC-20 -- Secure Name/Address Resolution Service
(Authoritative Source) Recommended Policy Enhancement(s)
240](#__RefHeading___Toc193514868)

[Table 97: SC-21 -- Security Name/Address Resolution Service (Recursive
or Caching Resolver) Recommended Policy Enhancement(s)
240](#__RefHeading___Toc193514869)

[Table 98: System and Information Integrity Controls
243](#__RefHeading___Toc193514870)

[Table 99: SI-2 -- Flaw Remediation Mandatory Policy Enhancement(s)
244](#__RefHeading___Toc193514871)

[Table 100: SI-3 -- Malicious Code Protection Mandatory Policy
Enhancement(s) 245](#__RefHeading___Toc193514872)

[Table 101: SI-4 -- Information System Monitoring Tools and Techniques
Mandatory Policy Enhancement(s) 246](#__RefHeading___Toc193514873)

[Table 102: SI-4 -- Information System Monitoring Tools and Techniques
Recommended Policy Enhancement(s) 246](#__RefHeading___Toc193514874)

[Table 103: SI-5 -- Security Alerts and Advisories Mandatory Policy
Enhancement(s) 247](#__RefHeading___Toc193514875)

[Table 104: SI-6 -- Security Functionality Verification Recommended
Policy Enhancement(s) 248](#__RefHeading___Toc193514876)

[Table 105: SI-7 -- Software and Information Integrity Mandatory Policy
Enhancement(s) 249](#__RefHeading___Toc193514877)

[Table 106: SI-7 -- Software and Information Integrity Recommended
Policy Enhancement(s) 249](#__RefHeading___Toc193514878)

[Table 107: SI-8 -- Spam Protection Mandatory Policy Enhancement(s)
250](#__RefHeading___Toc193514879)

[Table 108: SI-8 -- Spam Protection 250](#__RefHeading___Toc193514880)

[Table 110 Glossary of Information Security Terms Based upon NIST IR
7298 and DOI References 315](#__RefHeading___Toc193514881)

#  {#section-2 .unnumbered}

# Executive Summary

On January 23, 2002, Congress enacted Public Law, 107-347, E- Government
Act of 2002. The Federal Information Security Management Act (FISMA) of
2002, Title III, of this law requires that each agency have effective
information security controls over Information Technology (IT) to
support federal operations and assets and provide a mechanism for
improved oversight of agency information security programs. This Act was
designed to strengthen OMB Circular A-130, Appendix III that initially
established specific requirements for all agency programs. As technology
has grown more complex and open, the need for an effective federal
information security program within DOI and for each bureau and office
is essential. In DOI, this program is referred to as the Information
Technology Security Program (ITSP).

DOI has undertaken an aggressive role in support of protecting
information assets and information systems from occurrences that could
adversely impact their confidentiality, integrity or availability. The
Cyber Security Division is working to ensure that protective controls
are in place that are commensurate with the level of sensitivity of the
information resources that are owned and managed by DOI. By formally
defining process and policy, the Cyber Security Division is assuring
consistency in the implementation of controls that will strengthen the
overall DOI security posture and support compliance with FISMA
requirements. Each bureau and office must be responsive and responsible
in supporting DOI security requirements. This policy handbook is
designed to outline the responsibilities of each bureau and staff office
Information Technology Security Program (ITSP) and to specifically
define the security roles of the Department Chief Information Officer
(CIO), Department Chief Information Security Officer (CISO), Designated
Approving/Accrediting Authorities (DAAs -- also referred to as the
*authorizing official*), System Owners, Bureau Chief Information
Officers (BCIOs), Bureau Chief Information Security Officers (BCISOs),
Bureau Information System Security Manager's (ISSMs), Bureau Information
System Security Officer's (ISSOs). These positions are vital components
in strategically securing DOI information technology systems and
information assets by providing effective management and oversight of
DOI's Information Technology Security Program.

The goal of the IT Security Policy Handbook and accompanying standards
is to provide a single summary of the minimum cyber security criteria
needed to protect DOI's business critical functions and the information
assets and technologies that support them. The document is based on
public laws, Office of Management and Budget (OMB) circulars and
memorandums, National Institute of Standards and Technology (NIST)
standards and guidelines, and DOI specific security issues, concerns,
and experiences. This document provides a framework for bureaus and
offices to expand upon for mitigating risks to DOI information assets
and technologies (resources). Its design is intended to be consistent
with DOI policies and governmental laws that regulate specific types of
information.

NIST issued the Federal Information Processing Standard Publication
(FIPS Pub) 200 and the associated NIST Special Publication (SP) 800-53
that identifies a minimum mandatory set of management, operational, and
technical information technology security controls appropriate to the
protection of information and information systems commensurate with the
potential risk impacts to them. In response, Interior has identified a
need to establish IT security policies and procedures in a manner that
aligns to each of those controls. This IT Security Policy Handbook
represents Interior's IT security policies that are consistent, and in
alignment, with the NIST standards and guidelines and other related
requirements set forth in Office of Management and Budget (OMB)
memorandums and circulars.

This policy handbook is intended to establish minimum mandatory IT
security policies and implementation standards for all of Interior's
bureau and office IT security programs and be fully applied to, and
implemented for, the protection of Interior's information and
information systems by those charged with the responsibility for
implementing various aspects of security controls as described herein.

This policy handbook is subordinate to the Departmental Manual
(375DM19), and consistent with the DM, it carries the same weight, force
and effect as the DM. The policy handbook takes precedence over any
existing OCIO directives and memorandums regarding IT security policies
and standards wherever the same types of requirements were addressed and
that may be in conflict with the policy handbook. To clarify, the policy
handbook does not yet supersede previously issued directives and
memorandums in their entirety, unless explicitly stated, but does
supersede any aspect of those that conflict with this policy handbook.

Policies, standards and procedures play an important role in the
effective implementation of enterprise-wide information security
programs within the federal government and the success of the resulting
security measures employed to protect federal information and
information systems. Thus, Interior and its bureaus and offices must
develop and promulgate formal, documented policies and procedures
governing the minimum security requirements set forth in the NIST
standards and must ensure their effective implementation. Bureaus and
offices may develop additional IT security policies to the extent that
such policies are:

-   consistent with, and complimentary to, this IT Security Policy
    Handbook;

-   more stringent, and not less stringent, than this IT Security Policy
    Handbook;

-   used to augment, and not replace or serve as an alternative to, this
    IT Security Policy Handbook; and

-   used to address bureau/office specific IT security issues and risks
    not already addressed by this IT Security Policy Handbook.

As with any weakness associated with inadequate management, operational
or technical security controls, all aspects of noncompliance with the
policies and standards contained within this IT Security Policy Handbook
or bureau/office level security policies require that those aspects of
non-compliance be formally documented within the appropriate information
system Risk Assessment report. Any documented acceptance of risk(s)
requires the relevant Designated Approving/Accrediting Authority (DAA)
to formally acknowledge and accept any associated risks, in writing, by
signing the risk acceptance statements. In considering whether or not to
accept the risks indefinitely or for some specified time, the risk
acceptance documentation must identify any conditions and constraints
under which those risks will be accepted by the cognizant DAA (e.g.,
specified acceptable duration within which the DAA will tolerate
continued acceptance of the risk, any required mitigating actions and/or
compensating controls to be implemented as interim protective measures,
etc.) Where the DAA is unwilling to accept risks indefinitely, the
weakness must be incorporated into the appropriate program- or
system-level Plan of Action and Milestones (POA&M). These are the
appropriate means, and only formal methods available, that are
consistent with FISMA, OMB, and NIST standards and guidelines by which
weaknesses are effectively understood, documented, accepted, managed,
and tracked. There are no provisions to request any other form of
exemption to policies and standards.

[]{#__RefHeading___Toc193514325 .anchor}**Introduction**

## Purpose and Applicability

This IT Security Policy Handbook and accompanying standard establishes
policy for the management of risk that results from threats and
vulnerabilities that could impact the confidentiality, integrity, and
availability of information and information systems that are owned or
managed by the United States Department of the Interior (DOI) to include
the Office of the Secretary, National Business Center (NBC), Office of
the Solicitor (SOL), Office of the Special Trustee (OST), Office of
Hearings and Appeals (OHA), Office of Historical Trust Accounting
(OHTA), Bureau of Indian Affairs (BIA), Bureau of Land Management (BLM),
Bureau of Reclamation (BOR), Minerals Management Service (MMS), National
Park Service (NPS), Office of Surface Mining and Reclamation Enforcement
(OSM), U.S. Fish and Wildlife Service (FWS), and U.S. Geological Survey
(USGS), Regional, State, and Local Field Service Offices, DOI
contractors and their partners.

## Relationship to other guidance documents

This document conforms to current government-wide policies, standards,
and procedures.

### Security Policy Replacement

#### Federal and Departmental Security Policy vs. OCIO Security Policy

Where newly-issued government-wide or higher-authority DOI policies
(e.g., the Departmental Manual (DM)) conflict with this document, those
policies will supersede the conflicting sections of this document, which
will be amended in future releases to conform to government-wide or DOI
policy.

#### OCIO Security Policy vs. Bureau Security Policy

Where bureau or office policy exists on these topics, this document
supersedes all previous bureau or office security manuals, policies, and
guidelines; unless those manuals, policies, and guidelines provide for
more stringent security of information and information systems within
the Department or unless those documents serve to implement these
policies.

The OCIO, CSD, and the Information Technology Security Team (ITST) shall
collaborate on the creation of IT security policy and resolve any
differentiation that may exist with regard to policy. This document
shall remain in effect until superseded by a signed document with
adequate authority and scope. This document shall incorporate signed
authority amendments.

## Scope

This IT Security Policy Handbook and accompanying standards is directed
to and applies to all federal employees, partners, government
contractors, volunteers, and all others responsible for managing,
administering, supporting, protecting, or accessing information
technology (IT) and information contained in IT systems for the
Department of the Interior; including large offices, field offices, and
their partners. Any individual having any of the following positions,
titles, roles, or responsibilities is required to read, understand, and
comply with the content of this IT Security Policy Handbook and
accompanying standards:

-   Department Chief Information Officer (CIO)

-   Department Chief Information Security Officer (CISO)

-   Designated Approving/Accrediting Authorities (DAAs)

-   System Owners

-   Bureau Chief Information Officers (BCIOs)

-   Bureau Chief Information Security Officers (BCISOs)

-   Bureau Information System Security Manager's (ISSMs)

-   Bureau Information System Security Officer's (ISSOs).

## Authorities

#### Executive Branch Policy

This policy is established through directives published by the Office of
Management and Budget (OMB) based on the applicable laws passed by
Congress and includes the following policy issuances:

  -----------------------------------------------------------------------
  OMB Circular               Description
  -------------------------- --------------------------------------------
  A-11, Section 53,          This directive specifies the identification
  Information Technology and of security and privacy safeguards for
  E-Government               managing sensitive information.

  A-123, Management          This directive specifies the policies and
  Accountability and         standards for establishing, assessing,
  Control, as revised        correcting, and reporting on management
  December 21, 2004          controls in federal agencies.

  A-127, Financial           This directive prescribes policies and
  Management Systems, as     standards for executive departments and
  revised by Transmittal     agencies to follow in developing, operating,
  Memorandum Number 3,       evaluating, and reporting on financial
  December 1, 2004           management systems.

  A-130, Appendix I, Federal This directive prescribes policy to agencies
  Agency Responsibilities    for the implementation of the Privacy Act
  for Maintaining Records    and reporting requirements related to the
  About Individuals          management of personally identifiable
                             information (PII).

  A-130, Appendix III,       This directive stipulates that each agency
  Security of Federal        shall implement a comprehensive automated
  Automated Information      information security program. The appendix
  Resources, as revised by   establishes basic managerial and procedural
  Transmittal Memorandum     control that shall be included in federal
  Number 4, November 28,     automated information systems.
  2000                       
  -----------------------------------------------------------------------

[]{#__RefHeading___Toc193514773 .anchor}Table 1: OMB Published
Directives

#### Applicable Laws, Guidelines, Regulations, and Guidance Directives

A number of laws, policy guidelines, regulations and guidance directives
mandate protection of federal computers, information, and related
resources. Federal managers are responsible for familiarity and
compliance with applicable legal requirements. Applicable laws passed by
congress include:

+-------------------------+--------------------------------------------+
| Authority               | Description                                |
+=========================+============================================+
| Public Law 93-502,      | This law requires that federal information |
| Freedom of Information  | be made available to the public except     |
| Act (FOIA) of 1980      | under certain specified conditions.        |
+-------------------------+--------------------------------------------+
| Public Law 99-474,      | This law provides for the punishment of    |
| Computer Fraud and      | individuals who access federal computer    |
| Abuse Act of 1986       | resources without authorization, attempt   |
|                         | to exceed access privileges, abuse         |
|                         | government resources, and/or conduct fraud |
|                         | on government computers.                   |
+-------------------------+--------------------------------------------+
| Public Law 103-62,      | This law establishes policies for managing |
| Government Performance  | agency performance of mission, including   |
| and Results Act (GPRA)  | performance of its practices.              |
| of 1993                 |                                            |
+-------------------------+--------------------------------------------+
| Public Law 104-13,      | This law provides for the administration   |
| Paperwork Reduction Act | and management of computer resources.      |
| of 1995, Revised        |                                            |
+-------------------------+--------------------------------------------+
| Public Law 104-106,     | This law improves the acquisition, use,    |
| Clinger-Cohen Act --    | and disposal of Information Technology     |
| Information Technology  | (IT) by the federal government.            |
| Management Reform Act   |                                            |
| of 1996                 |                                            |
+-------------------------+--------------------------------------------+
| Public Law 104-294,     | This law provides for the protection of    |
| National Infrastructure | computer resources.                        |
| Protection Act of 1996  |                                            |
+-------------------------+--------------------------------------------+
| Public Law 105-277,     | This law provides for federal agencies, by |
| Government Paperwork    | October 21, 2003, to give persons who are  |
| Elimination Act (GPEA)  | required to maintain, submit, or disclose  |
| of 1998                 | information, the option of doing so        |
|                         | electronically when practicable as a       |
|                         | substitute for paper and to use electronic |
|                         | authentication methods to verify the       |
|                         | identity of the sender and the integrity   |
|                         | of electronic content.                     |
+-------------------------+--------------------------------------------+
| Executive Order 10450,  | This order establishes that the interests  |
| Security Requirements   | of national security require all           |
| for Government          | government employees be trustworthy, of    |
| Employees, April 1953   | good character, and loyal to the United    |
|                         | States.                                    |
+-------------------------+--------------------------------------------+
| Executive Order 13011,  | This order establishes policy for the head |
| Federal Information     | of each agency to effectively use          |
| Technology, July 1996   | information technology to improve mission  |
|                         | performance and service to the public.     |
+-------------------------+--------------------------------------------+
| Executive Order 13103,  | This order establishes policy that each    |
| Computer Software       | executive agency shall work diligently to  |
| Piracy, October 1998    | prevent and combat software piracy in      |
|                         | order to give effect to copyrights         |
|                         | associated with computer software.         |
+-------------------------+--------------------------------------------+
| Executive Order 13231,  | This order establishes policy that ensures |
| Critical Infrastructure | protection of information systems for      |
| Protection in the       | critical infrastructure, including         |
| Information Age,        | emergency preparedness communications, and |
| October 2001            | the physical assets that support such      |
|                         | information systems.                       |
+-------------------------+--------------------------------------------+
| Presidential Decision   | This directive requires that the United    |
| Directive 63: Critical  | States take all necessary measures to      |
| Infrastructure          | swiftly eliminate any significant          |
| Protection, May 1998    | vulnerability to both physical and cyber   |
|                         | attacks on critical infrastructures,       |
|                         | including our cyber systems.               |
+-------------------------+--------------------------------------------+
| Paperwork Reduction     | This law provides for the administration   |
| Act, Revised 1995       | and management of computer resources.      |
+-------------------------+--------------------------------------------+
| Privacy Act of 1974,    | This law imposes collection, maintenance,  |
| Revised                 | use, safeguard, and disposal requirements  |
|                         | for Executive Branch offices maintaining   |
|                         | information on individuals in a "system of |
|                         | records" as defined herein (refer to       |
|                         | Public Law 93-579, Privacy Act of 1986.    |
+-------------------------+--------------------------------------------+
| E-Government Act of     | This law enhances the management and       |
| 2002                    | promotion of electronic government         |
|                         | services and processes by establishing a   |
|                         | broad framework of measures requiring      |
|                         | technology to enhance citizen access to    |
|                         | government information services.           |
+-------------------------+--------------------------------------------+
| Federal Managers        | This law mandates that federal agencies    |
| Financial Integrity Act | establish and maintain an internal control |
| (FMFIA) of 1982         | program to safeguard data processing       |
|                         | resources, assure their accuracy and       |
|                         | reliability, and protect the integrity of  |
|                         | information resident on such systems.      |
+-------------------------+--------------------------------------------+
| Federal Financial       | This law mandates federal agencies to      |
| Management Improvement  | implement and maintain financial           |
| Act (FFMIA) of 1996     | management systems that comply             |
|                         | substantially with federal systems         |
|                         | requirements, federal accounting           |
|                         | standards, and the U.S. Government         |
|                         | Standard General Ledger (SGL). FFMIA also  |
|                         | requires GAO to report annually on the     |
|                         | implementation of the act.                 |
+-------------------------+--------------------------------------------+
| Federal Information     | FISMA requires federal Agencies to         |
| Security Management Act | establish agency-wide risk-based           |
| of 2002 (FISMA), P.L.   | information security programs that include |
| 107-347, sec. 301-305.  | periodic risk assessments, use of controls |
|                         | and techniques to comply with information  |
|                         | security standards, training requirements, |
|                         | periodic testing and evaluation,           |
|                         | reporting, and plans for remedial action,  |
|                         | security incident response, and continuity |
|                         | of operations.                             |
+-------------------------+--------------------------------------------+
| Standards of Ethical    | These standards describe ethical conduct   |
| Conduct for Employees   | that is expected of each employee          |
| of the Executive        | occupying a position of public trust.      |
| Branch, by the U.S.     |                                            |
| Office of Government    |                                            |
| Ethics                  |                                            |
+-------------------------+--------------------------------------------+
| Computer Matching       | Provides procedural safeguards affecting   |
| Privacy Protection Act  | agencies' use of Privacy Act records in    |
|                         | performing certain types of computerized   |
| Public Law 100-503      | matching programs                          |
| (Revised in 1990)       |                                            |
+-------------------------+--------------------------------------------+

[]{#__RefHeading___Toc193514774 .anchor}Table 2: Applicable Laws,
Guidelines, Regulation, and Guidance Directives

#### 

#### National Institute of Standards and Technology (NIST) Special Publications

Please refer to the current NIST Special Publications website located
at:
[**http://csrc.nist.gov/publications/nistpubs/**](http://csrc.nist.gov/publications/nistpubs/)

#### DOI Policy

Please refer to the current Policy website located at:
[http://www.elips.doi.gov](http://www.elips.doi.gov/)

#  

# Organizational Responsibilities

![](media/image2.png){width="6.25625in" height="6.270833333333333in"}All
DOI bureaus and staff offices will organize, implement and maintain
Information Technology Security Program(s) that ensure efficient,
effective, uniform, and compliant security for all Interior information
technology assets. This program will be built upon essential target
component areas: Critical Infrastructure Protection, Policy and
Standards, Technical Implementation Guidance, Security Architecture
Development, System Lifecycle Development, Security Tool Analysis and
Evaluation, Incident Response and Forensics, Threat Analysis and
Awareness, Vulnerability and Penetration Assessments, Security Training
and Education, Compliance and Validation, and Certification and
Accreditation which are reflected in Figure 1 below:

[]{#__RefHeading___Toc193514769 .anchor}Figure 1: Essential Information
Technology Security Program Components

Security must be adequately addressed in all phases of the organization.
Each ITSP will include the following responsibilities within the
framework of the essential target component areas:

1.  Work with business process owners to categorize sensitivity of
    information and information systems in accordance with FIPS 199,
    NIST SP 800-60 and leveraging DOI enterprise architecture to
    identify interdependencies and interrelationships;

2.  Conduct regular risk assessments for IT systems and computing
    devices;

3.  Implement effective risk mitigation strategies using NIST 800-100;

4.  Conduct formal Certification and Accreditation (C&A) of all bureau
    and office IT systems;

5.  Implement security controls throughout the System Development Life
    Cycle in accordance with FIPS Publication 200: Minimum Security
    Requirements for Federal Information and Information Systems, DOI
    Policy and Guidance, and using NIST 800-53A, *Guide for Assessing
    the Security Controls in Federal Information Systems*, to provide a
    foundational level of assessment to support the security
    certification process;

6.  Use the Capital Planning and Investment Controls (CPIC) process to
    formulate and plan security costs for all systems;

7.  Monitor the system Configuration Management (CM) process of all
    systems to identify any potential impact to the integrity,
    availability or confidentiality of information assets or information
    systems;

8.  Prepare annual program and system specific security plans;

9.  Manage an effective Security Awareness and Training Program;

10. Manage bureau Incident Response program that includes threat
    awareness and forensic capabilities;

11. Manage bureau Incident Response program using NIST 800-61 in
    coordination with DOI Cyber Security Division;

12. Conduct annual self-assessment of the ITSP using the Information
    Security Program Assessment Questionnaire contained in Annex 11.A of
    the NIST 800-100 Information Security Handbook: A Guide for
    Managers;

13. Facilitate an annual independent assessment of the ITSP.

14. Conduct annual self assessment of the effectiveness of implemented
    controls on IT Systems using NIST 800-53A, *Guide for Assessing the
    Security Controls in Federal Information Systems*, and leveraging
    the assessment results of the current certification phase and
    continuous monitoring;

15. Monitor IT systems using audit trails, controls logs and other
    mechanisms using NIST 800-92;

16. Establish an electronic inventory of all IT systems and computing
    devices;

17. Maintain bureau IT inventory in the Departmental Enterprise
    Architecture Repository (DEAR);

18. Disseminate department policy and procedures to all personnel;

19. Develop and disseminate local policy and procedures to all
    personnel;

20. Respond to regular and ad hoc reporting requirements and audits by
    internal or external agencies; and

21. Monitor compliance to DOI, OMB, NIST and other governing bodies'
    policy for security.

Consistent with this strategy, The Department/Agency Chief Information
Officer (CIO) is responsible for the development, coordination, and
interpretation of all IT policy and guidance; and has overall
responsibility for information privacy issues throughout DOI.

The Department/Agency Chief Information Security Officer (CISO) is
responsible for the development, coordination, implementation and
oversight to ensure Department-wide compliance with IT Security policy
and program management requirements.

The Information Technology Security Team (ITST) is responsible for the
review of IT Security policy and recommends revisions of this handbook
to the DOI CISO on at least an annual basis, and as necessary, to ensure
it meets federal mandates and operational requirements.

Bureau CIOs are responsible for ensuring that all IT Security policy and
procedures are disseminated and adhered to through out their respective
organizations.

Bureau CISOs, working closely with authorizing official (AO)(s) and
their designated representatives, are responsible for ensuring
compliance with established IT Security policy throughout their
organization. Where policies are not complied with, bureau CISOs shall
ensure 1) deviations are documented and residual risk has been accepted
for their organization by the appropriate AO, 2) an approved plan for
remediation of risk is documented within system and program POA&Ms, or
3) the system is removed from production.

## Information Technology Security Program Leadership Roles

### Senior Leadership:

#### Secretary of the Interior

The Clinger-Cohen Act assigns the Secretary of the Interior
responsibility for ensuring "that the information security policies,
procedures, and practices of the executive agency are adequate." FISMA
provides the following details on agency head responsibilities for
information security:

-   Providing information security protections commensurate with the
    risk and magnitude of the harm resulting from unauthorized access,
    use, disclosure, disruption, modification, or destruction of
    information collected or maintained by or on behalf of an agency,
    and on information systems used or operated by an agency or by a
    contractor of an agency or other organization on behalf of an
    agency;

-   Ensuring that an information security program is developed,
    documented, and implemented to provide security for all systems,
    networks, and data that support the operations of the organization;

-   Ensuring that information security processes are integrated with
    strategic and operational planning processes to secure the
    organization's mission;

-   Ensuring that senior agency officials within the organization are
    given the necessary authority to secure the operations and assets
    under their control;

-   Designating a CIO and delegating authority to that individual to
    ensure compliance with applicable information security requirements;

-   Ensuring that the agency has trained personnel to support compliance
    with information security policies, processes, standards, and
    guidelines; and

-   Ensuring that the CIO, in coordination with the other senior agency
    officials, reports annually to the agency head on the effectiveness
    of the agency information security program, including the progress
    of remedial actions.

#### The Department of the Interior Chief Information Officer

FISMA assigns the agency CIO the following responsibilities:

-   Designating a senior agency Chief Information Security Officer
    (CISO);

-   Developing and maintaining an agency-wide information security
    program;

-   Developing and maintaining information security policies,
    procedures, and control techniques to address all applicable
    requirements;

-   Ensuring compliance with applicable information security
    requirements; and

-   Reporting annually, in coordination with the other senior agency
    officials, to the agency head on the effectiveness of the agency
    information security program, including progress of remedial
    actions.

#### The Department of the Interior Chief Information Security Officer (CISO)

1.  Performs information security duties as the primary duty;

2.  Heads an office with the mission and resources to assist in ensuring
    agency compliance with federal laws and mandates regarding
    information security and information system security;

3.  Periodically assesses risk and magnitude of the harm resulting from
    unauthorized access, use, disclosure, disruption, modification, or
    destruction of information and information systems that support the
    operations and assets of the agency;

4.  Develops and maintains risk-based, cost-effective information
    security policies, procedures, and control techniques to address all
    applicable requirements throughout the life cycle of each agency
    information system to ensure compliance with applicable
    requirements;

5.  Facilitates development of subordinate plans for providing adequate
    information security for networks, facilities, and systems or groups
    of information systems;

6.  Establishes and supports a departmental Security Awareness and
    Training program to ensure that agency personnel, including
    contractors, receive appropriate information security awareness
    training;

7.  Provides training and oversight to personnel with significant
    responsibilities for information security that is germane to their
    responsibilities;

8.  Periodically tests and evaluates the effectiveness of information
    security policies, procedures, and practices;

9.  Implements and maintains a process for planning, implementing,
    evaluating, and documenting remedial action to address any
    deficiencies in the information security policies, procedures, and
    practices of the agency;

10. Develops and implements procedures for detecting, reporting, and
    responding to security incidents;

11. Ensures the preparation and maintenance of plans and procedures to
    provide continuity of operations for information systems that
    support the operations and assets of the agency; and

12. Supports the agency CIO in annual reporting to the agency head on
    the effectiveness of the agency information security program,
    including progress of remedial actions.

13. Acts as the recognized Senior Agency Information Security Officer
    (SAISO) for the Department and the central point of contact for
    Cyber Security management within DOI;

14. Formulates and issues departmental Cyber Security policies and
    procedures for all DOI bureau and staff offices;

15. Promotes and monitors C&A of all DOI IT systems;

16. Provides enterprise-wide contractual vehicles and tools for security
    products and services;

17. Monitors Information Technology Security Programs to ensure that all
    security plans are current for programs and bureaus and offices IT
    systems;

18. Ensures that all bureaus comply with departmental and federal policy
    and procedures;

19. Collaborates in identification of material weaknesses and assists in
    formulating mitigation strategies, as required;

20. Coordinates the department's Computer Incident Response Center
    (CIRC) with US-CERT and other computer emergency response teams;

21. Assists bureaus in responding to computer fraud and with the
    handling of forensic evidence and investigations;

22. Ensures that agencies implement and maintain managerial, technical,
    and operational security controls;

23. Supports and promotes IT Contingency Planning efforts;

24. Monitors and evaluates physical security control effectiveness
    within IT restricted space;

25. Ensures DOI meets the Privacy Act and other government privacy laws
    and guidelines required for IT systems;

26. Reviews and make recommendations to the CIO for all IT investments,
    waiver, and risk acceptance requests; and

27. Acts as the central point for preparing regulatory reports required
    by FISMA and other legislation.

#### Bureau Chief Information Officer (CIO)

1.  Acts as the Senior Security Officer (SSO) who is responsible for
    supporting the strategic requirements of the bureau or office ITSP;

2.  Ensures that adequate funding, training, and resources are provided
    to the ITSP to support the bureau mission;

3.  Facilitates the resolution of high-level security matters by acting
    as a champion for the BCISO;

4.  Ensures that ISSM/ISSOs are designated to provide adequate security
    to business, functional or operational entities;

5.  Serves as the Certification Official (CO) for bureau security
    requirements (i.e., Annual System Security Plan (SSP)
    review/updates, FISMA and other formal reporting requirements,
    waiver requests and certification of bureau IT systems);

6.  Formally designates in writing the BCISO(s) and Deputy (ies) for
    each bureau to the OCIO CISO;

7.  Provides role-based and specialized security training to the
    BCISO(s) and Deputy BCISO(s) utilizing DOI enterprise training
    vehicles or other specialized vehicles for highly specific training;

8.  Establishes, implements, and provides adequate resources for a
    bureau ITSP that provides a comprehensive and proactive security
    process to protect bureau assets;

9.  Is knowledgeable in legal and liability issues surrounding computing
    devices, the consequences of security breaches and requirements of
    executive accountability for IT systems;

10. Ensures that all bureau systems are Certified and Accredited prior
    to operation and that they are reaccredited every three years or
    when a significant system change occurs that impacts the system's
    security posture;

11. Ensures that departmental security policy and procedures are
    disseminated;

12. Ensures that internal bureau security procedures are implemented,
    tested, and integrated into the bureau culture;

13. Ensures that the BCISO is a permanent member of all bureau system
    development initiatives, telecommunications planning, and SDLC
    processes;

14. Establishes and monitor bureau personal use policy for all computing
    devices;

15. Proactively supports the establishment of departmental uniform
    system security controls , and provides for the protection of
    Sensitive But Unclassified (SBU) information using authentication
    techniques, encryption, firewalls, access controls, and
    comprehensive departmental Incident Response procedures;

16. Supports bureau contingency planning efforts by establishing
    Disaster Recovery (DR) and other emergency plans for all IT systems;

17. Ensures that the security requirements of IT Restricted Space are
    followed in maintaining, updating or planning new space;

18. Ensures that all bureau personnel, including contractors, receive
    security awareness briefings and training based on their role in the
    organization;

19. Ensures that background screenings are conducted for all employees
    based on the level of trust and sensitivity of the position they
    occupy in the organization;

20. Supports the development of a security architecture for all bureau
    IT systems;

21. Effectively implements and provides oversight of patch management
    and scanning techniques are employed to protect, identify and
    mitigate system vulnerabilities;

22. Provides security controls for Portable Electronic Devices (PEDS)
    and other wireless technology;

23. Ensures that an overall bureau security plan is prepared for the
    program and current system specific plans are in place for all IT
    systems;

24. Conducts risk assessments of all systems and mitigates
    vulnerabilities wherever feasible;

25. Establishes Configuration Management (CM) practices to ensure that
    security controls are maintained over the life of the IT systems;

26. Ensures that all operational information systems are captured in an
    electronic bureau inventory and included in the Department's
    Enterprise Architecture Repository (DEAR);

27. Ensures that the Privacy Act and other government privacy laws and
    guidelines are met;

28. Ensures that security costs are planned and entered in to bureau
    annual budget submission for all IT investments and systems;

29. Ensures that the bureau complies with mandated internal and external
    security reporting requirements, including FISMA, NIST, OMB and
    departmental requirements;

30. Ensures that support is provided for computer investigations and
    forensics; and

31. Proactively supports departmental CSD initiatives.

### Information Technology Security Program Leadership

#### The Bureau Chief Information Security Officer (BCISO)\[formerly BITSM\] will:

1.  Serve as the POC for all bureau cyber security matters interfacing
    with the department ITSP and bureau CIO;

2.  Provide subject matter guidance to bureau senior leadership;

3.  Manage the bureau ITSP, including field activities;

4.  Manage the bureau ITSP including the activities and training from
    DOI enterprise training vehicles or other specialized vehicles for
    highly specific training of the ISSM/ISSOs;

5.  Support the strategic security program requirements to include:
    planning, budget analysis, department policy review and internal
    policy formulation, bureau FISMA, POA&M, and audit reporting
    requirements, bureau Security Architecture and bureau IT CPIC;

6.  Consolidate individual reports from all functional and operation
    units into one bureau combined report (i.e., monthly scans, patches,
    incidents) for higher level management, including CISO;

7.  Monitor the progress of the ISSM/ISSOs to ensure that they meet the
    necessary program security requirements of NIST 800-53, 800-53,Rev.
    1, 800-92, 800-100, 800-61, A-130, FFMIA, FMFIA, FISMA, OMB guidance
    and departmental policy directives;

8.  Serves as the principle consultant to the bureau CIO and DOI senior
    management, including the DOI CISO;

9.  Coordinate bureaus Incident Response with DOI-CIRC and bureau
    ISSM/ISSOs to include all associated actions necessary to mitigate
    the risk to unit systems; and

10. Oversee the implementation of bureau security policies, procedures
    and guidelines.

11. Participate in the process and monitor the program to ensure that
    all bureau systems are C&A'd prior to operation and that they are
    reaccredited every three years or when significant system change
    occurs;

12. Disseminate Departmental security policy and procedures;

13. Formulate internal bureau security policies, procedures and support
    implementation, testing, and integration into the bureau culture
    (mission and business operation) to adhere to or strengthen
    departmental policies;

14. Participate, as a permanent member, on all bureau system development
    teams, telecommunications planning, and SDLC processes;

15. Conduct internal audits of all bureau IT systems to ensure
    compliance with federal and departmental policy and procedures;

16. Participate in general and role-based security training to enhance
    knowledge and skill level from DOI enterprise training vehicles or
    other highly specific training vehicles;

17. Recommend appropriate role-based training for staff and field
    personnel from DOI enterprise training vehicles and other sources to
    CIO;

18. Proactively coordinate the establishment of uniform system security
    controls;

19. Ensure the protection of SBU or FOUO information using
    authentication techniques, encryption, firewalls, access controls,
    and comprehensive Incident Response procedures with all SA(s) and
    business owners, and develop security baselines, where applicable;

20. Coordinate with business owners to categorize information systems
    and determine sensitivity levels;

21. Collaborates with system owners to establish Disaster Recovery (DR)
    and other emergency plans for all bureau or office IT systems;

22. Ensure compliance with backup and storage procedures;

23. Monitor to ensure that the security requirements of IT restricted
    space are followed in maintaining, updating or planning new space,
    and advise the CIO if space does not meet security requirements;

24. Develop and manage a Security Awareness program including arranging
    or conducting security awareness briefings;

25. Recommend to the bureau CIO role-based security training for all
    bureau personnel, including contractors, based on their role in the
    organization;

26. Ensure that all personnel understand and formally agree with in
    signature the Security Rules of Behavior (ROB) prior to being
    granted access to bureau systems;

27. Coordinate with local Human Resources Offices to arrange for
    background screening of all IT employees based on the level of trust
    and sensitivity of the position they occupy in the organization;

28. Participate in the development of a security architecture for all
    bureau IT systems;

29. Monitor and coordinate patch management and scanning programs for
    all bureau systems;

30. Participate in identification and mitigation of all system
    vulnerabilities;

31. Coordinate the provisioning of security controls for PEDS and other
    wireless technology;

32. Formulate and prepare the overall bureau Security Plan for the
    program and coordinate with ISSOs to ensure that current system
    specific plans are in place for all IT systems and aligned with the
    bureau Security Plan;

33. Coordinate or participate in risk assessments of all systems and
    mitigate vulnerabilities;

34. Monitor CM practices to ensure that security controls are maintained
    over the life of the IT systems;

35. Develop and prepare an electronic bureau inventory for all bureau
    computing devices;

36. Monitor and participate in assessments to ensure that government
    privacy requirements are met;

37. Plan and document security costs for all IT investments and systems,
    and provide input for all exhibit 300 and exhibit 53 documents;

38. Prepare and update bureau reports to ensure that the bureau complies
    with mandated internal and external security reporting requirements,
    including FISMA and CPIC; and

39. Proactively participate in Departmental Cyber Security Division
    initiatives including, but not limited to, ITST participation,
    detailed reporting, computer investigations and forensics.

#### The Information Systems Security Manager (ISSM) will:

1.  Serve as the Point of Contact (POC) for all unit Cyber Security
    matters;

2.  Provide subject matter guidance to unit personnel;

3.  Participate in the process and monitor to ensure that all unit
    systems are Certified and Accredited prior to actual operation and
    that they are assessed annually and reaccredited every three years
    or when a significant system change occurs that impacts the system's
    security posture;

4.  Implements departmental security policy and procedures;

5.  Formulate internal unit security policy guidance and procedure to
    support implementation, testing, and integration into the unit
    culture (mission and business operation) to adhere to or strengthen
    departmental and unit policy;

6.  Participate as a permanent member of unit system development teams,
    telecommunications planning, and System Development Life Cycle
    (SDLC) processes;

7.  Conduct internal audits of all unit IT systems to ensure compliance
    with federal and departmental policy and procedures;

8.  Participate in general and role-based security training to enhance
    knowledge and skill level;

9.  Proactively coordinate the establishment of enterprise common
    security controls and system security controls to protect unit
    information using authentication techniques, encryption, firewalls,
    access controls, and comprehensive departmental Incident Response
    Procedures with all System Administrators (SA) and business process
    owners in alignment with DOI enterprise architecture, NIST SP-800-30
    Risk Management Guide for Information Technology Systems and using
    controls identified in NIST 800-53 Rev. 1 Recommended Security
    Controls for Federal Information Systems, NIST 800-35 Guide to
    Information Technology Security Services and NIST 800-27 Engineering
    Principles for Information Technology Security (A Baseline for
    Achieving Security), Revision A;

10. Coordinate with business process owners to categorize information
    systems and determine sensitivity levels and document in SSP
    leveraging DOI enterprise architecture to identify impacts to
    business processes, NIST FIPS-199 Standards for Security
    Categorization of Federal Information and Information Systems and
    SP-800-30 Risk Management Guide for Information Technology Systems;

11. Collaborate with system owners to ensure that contingency plans for
    all unit or office IT systems are established, tested and aligned
    with Site, Unit and DOI strategies and NIST 800-34 Contingency
    Planning Guide for Information Technology (IT) Systems;

12. Ensure compliance with backup, storage and media sanitization and
    disposition policies and guidance using NIST 800-88 Guidelines for
    Media Sanitization and FIPS 200, (Minimum Security Requirements for
    Federal Information and Information Systems) and DOI Media handling
    policy;

13. Monitor physical spaces to ensure that the security requirements of
    IT Restricted Space are followed in maintaining, updating or
    planning new space, and advise the CIO if space does not meet
    security requirements;

14. Develop and manage a Security Awareness Program including arranging
    or conducting security awareness briefings;

15. Recommend role-based security training to the BCISO for all unit
    personnel, including contractors, based on their role in the
    organization;

16. Ensure that all personnel are appropriately trained in the security
    Rules of Behavior (ROB) prior to being granted access to unit
    systems;

17. Arrange for background screening of unit employees based on the
    level of trust and sensitivity of the position they occupy in the
    organization;

18. Participate in the development of a security architecture for all
    unit IT systems;

19. Monitor and coordinate patch management and scanning techniques for
    all unit systems;

20. Participate in identification and mitigation of all system
    vulnerabilities,

21. Coordinate the provisioning of security controls for PEDS and other
    wireless technology;

22. Participate in the overall bureau Security Plan for the program and
    coordinate with ISSO to ensure that current system specific plans
    are in place for all IT systems;

23. Coordinate or participate in risk assessments of all unit systems
    and mitigate vulnerabilities;

24. Monitor CM practices to ensure that security controls are maintained
    over the life of the IT systems, and formulate and prepare an
    electronic unit inventory for unit computing devices;

25. Monitor and participate in assessments to ensure that privacy
    requirements are met;

26. Plan and document security costs for unit IT investments and
    systems;

27. Prepare and update reports to ensure that the unit complies with
    mandated internal and external security reporting requirements,
    including FISMA and CPIC;

28. Proactively participate in new Cyber Security initiatives including,
    but not limited to, computer investigations and forensics;

29. Prepare and coordinate unit Incident Responses with the unit BCISO
    to include all associated actions necessary to mitigate the risk to
    unit systems.

30. Ensure annual Contingency Plan (CP) and Security Control Testing for
    each system.

#### Bureau Information Systems Security Officers (ISSO) will:

1.  Be knowledgeable of federal, departmental, and bureau security
    regulations when developing functional and technical requirements;

2.  Serve as a POC for system users with security issues;

3.  Coordinate security program and system elements with the bureau IT
    Program Managers by evaluating system environments for security
    requirements and controls including: IT Security Architecture,
    hardware, software, telecommunications, security trends, and
    associated threats and vulnerabilities;

4.  Manage security controls to ensure confidentiality, integrity and
    availability of information;

5.  Build security into the system development process and define
    security specifications to support the acquisition of new systems;

6.  Review and sign off on system procurement requests to ensure that
    security has been considered and included;

7.  Assist with security controls and associated costs in the CPIC
    Process;

8.  Assist the ISSM in the C&A process, including updates to the overall
    bureau and SSP for the program;

9.  Serve as a key advisor in risk assessments of their assigned systems
    and mitigate vulnerabilities for these respective systems;

10. Adhere to CM practices to ensure that security controls are
    maintained over the life of IT systems;

11. Update the electronic inventory for all computing devices;

12. Adhere to and implement system security controls that ensure the
    protection of SBU information using authentication techniques,
    encryption, firewalls, and access controls;

13. Assist the BCISO in following departmental Incident Response
    procedures;

14. Assist the system owner and ISSM in the development, testing and
    maintenance of bureau wide and system level contingency plans,
    backup and storage procedures;

15. Document all procedures according to departmental and bureau
    standards;

16. Audit and monitor application, system and security logs for security
    threats, vulnerabilities and suspicious activities;

17. Report suspicious activities to the bureau BCISO;

18. Support and facilitate the security awareness, training and
    education program; and

19. Assist the ISSM in any other security related duties, as required.

#### The Bureau Certification and Accreditation Manager:

The Certification and Accreditation Manager (CAM) is an individual
responsible for conducting a security certification and comprehensive
assessment of the effectiveness of security controls in an information
system. CAM has the following responsibilities in relation to security
certification and accreditation and shall:

1.  Be knowledgeable of federal, departmental, and bureau security
    regulations when developing functional and technical requirements;

2.  Assess bureau system security plans to ensure that plans provide
    applicable security controls prior to initializing the certification
    process;

3.  Track corrective actions to reduce or eliminate vulnerabilities for
    information system. Develop strategies for system security plans in
    coordination with information owners, the system administrator, the
    information system security officer (ISSO), the BCISO, and
    functional \"end users\";

4.  Maintain all bureau SSPs and ensure that they are deployed and
    operated according to the agreed-upon security requirements;

5.  Inform key bureau and office officials of the need to conduct a
    security C&A of the information system;

6.  Ensure appropriate resources are available for the security C&A
    effort;

7.  Provide necessary system-related documentation to the certification
    agent;

8.  Take appropriate steps to reduce or eliminate system vulnerabilities
    identified in the security C&A process; and

9.  Assemble the security accreditation package and submit it to
    authorizing official or authorizing official's designated
    representative for adjudication.

#### Information System Owner:

The information system owner is the bureau or office official
responsible for the overall procurement, development, integration,
modification, and operation and maintenance of the information system.
The information system owner has the following responsibilities related
to system security plans and shall:

1.  Develop the system security plan in coordination with information
    owners, the system administrator, the BCISO, ISSO, the CISO, and
    functional \"end users\";

2.  Maintain the SSP and ensure that the system is deployed and operated
    according to the agreed-upon security requirements;

3.  Ensure that system users and support personnel receive the requisite
    security training (e.g., ROB) and assisting in the identification,
    implementation, and assessment of the common security controls;

4.  Ensure appropriate resources are available for the security
    Contingency Planning efforts and ensure that annual testing of the
    Contingency Plan is completed for their respective systems;

5.  Inform key agency officials of the need to conduct a security C&A of
    the information system;

6.  Ensure appropriate resources are available for the security C&A
    effort for their respective systems;

7.  Provide necessary system-related documentation to the certification
    agent;

8.  Take appropriate steps to reduce or eliminate system vulnerabilities
    identified in the C&A process by POA&M documentation; and

9.  Assemble the security accreditation package and submit it to
    authorizing official or authorizing official's designated
    representative for adjudication.

#### Information Owner:

The information owner is the agency official with statutory or
operational authority for specified information and is responsible for
establishing the controls for information generation, collection,
processing, dissemination, and disposal. The information owner has the
following responsibilities related to system security plans and shall:

1.  Establish the rules for the appropriate use and protection of the
    subject data/information (ROB) and Privacy Act systems will comply
    with restrictions on access, use and disclosure); (or have a
    separate bullet regarding it;

2.  Provide input to information system owners on the security
    requirements and security controls for the information systems where
    the information resides;

3.  Assures that only PII information absolutely necessary for the
    mission of the system and collection of SSNs are absolutely
    necessary and alternative are considered;

4.  Ensures that Preliminary Privacy Impact Assessments (PIA) are
    completed to determine if systems maintain personally identifiable
    information (PII);

5.  If systems contain PII ensures that PIAs are completed and filed
    with metadata and for the C&A package, Exhibit 300, and FISMA annual
    and quarterly reporting.

6.  Ensures that Privacy Act system of records notices are published in
    the Federal Register for systems with PII (for reports as above)

7.  Ensures the systems are compliant with Federal Records Act
    requirements (records schedules in place)

8.  Ensures that Information Collection Clearance packages are cleared
    through OMB when required

9.  Decide who has access to the information system and determine what
    types of privileges or access rights based on duties; and

10. Assist in identifying and assessing the common security controls
    where the information resides.

#### The Bureau IRM, Automation Information System Management, Operations and Programming Staff shall:

1.  Be knowledgeable of federal and bureau security regulations when
    developing functional and technical requirements;

2.  Coordinate security program and system elements with the bureau IT
    program managers and BCISO (ISSM or ISSO as appropriate) by
    evaluating system environments for security requirements and
    controls including: IT Security Architecture, hardware, software,
    telecommunications, security trends, and associated threats and
    vulnerabilities;

3.  Manage security controls to ensure confidentiality, integrity and
    availability of information;

4.  Build security into the system development process and define
    security specifications to support the acquisition of new systems;

5.  Assist with defining security controls and associated costs in the
    CPIC process;

6.  Assist the system owner and BCISO in the C&A process, including
    updates to the overall bureau SSP;

7.  Participate in risk assessments of all systems and mitigate
    vulnerabilities;

8.  Adhere to CM practices to ensure that security controls are
    maintained over the life of IT systems;

9.  Update the electronic bureau inventory for all bureau computing
    devices;

10. Adhere to and implement system security controls at the appropriate
    Common Criteria EAL for the level of sensitivity of the information
    housed on the system and ensure the protection of SBU information
    using authentication techniques, encryption, firewalls, and access
    controls;

11. Assist the BCISO in following department Incident Response
    procedures;

12. Assist the system owner and BCISO in the development, testing and
    maintenance of bureau and system Contingency Plans, backup and
    storage procedures;

13. Document all procedures related to operational roles and
    responsibilities according to departmental and bureau standards;

14. Audit and monitor application, system and security logs for security
    threats, vulnerabilities and suspicious activities;

15. Report suspicious activities to the bureau ITSP office; and assist
    the BCISO in any other security related duties, as required.

16. Each bureau/office head is responsible for designating for each
    Privacy Act system of records a responsible official to serve as
    system manager, whose title and business address are required by the
    Act to be included in the Federal Register system notice. The system
    manager is the official designated as having administrative
    responsibility for a system of records. The bureau/office is also
    responsible for designating a regular bureau employee to be the
    system manager for a system of records developed or maintained by a
    contractor, as explained in the Department's regulations, 43 CFR
    2.53.

17. Implement procedures to ensure that Privacy Act systems are
    identified by Privacy Warning Notice (specified in 383 DM 8), and
    comply with DOI Privacy Act minimum safeguard requirements.

18. Ensure that access and disclosure is consistent with the Privacy Act
    and the specific Privacy Act system of records notice for a Privacy
    Act system.

19. Only provides PII information that is absolutely necessary (not data
    dumps).

20. Ensures that information in PIAs considers the best approach to
    avoid privacy risks.

21. Ensures that the privacy maintenance requirement checklist (see OCIO
    Directive 2006-16) is applied to systems with PII.

22. Discusses Privacy Act requirements with the organization's Privacy
    Officer.

## Mandatory Access Levels for DOI IT Security Resources (Security Clearance)

The Office of the Chief Information Officer (OCIO) requires that certain
positions within Interior that be eligible for and maintain appropriate
security clearances to enable designated individuals to receive
classified cyber threat, incident and situational awareness briefings;
participate in various Federal government committees relating to the
national cyber response strategies, plans and exercises; and participate
in cross-agency working groups to develop plans and implementation
strategies at various levels across the Federal government. Briefings
are frequently provided at various security classification levels
regarding the current cyber incidents, threats, trends, attack methods,
and mitigation strategies. Interior has a need to become more aware of
the increasing threats and mitigation strategies to more effectively
protect the confidentiality, integrity, and availability of Interior's
information and information technology resources and to be able to
prioritize IT security improvements and proactively respond to the
increasing threats. These individuals are in positions of trust with
regards to critical DOI IT assets, and are responsible for promoting
communication in times of crisis, acting as a conduit to reduce
confusion, supporting the stability of the enterprise, and assisting DOI
with incident analysis, management and response capabilities.

The OCIO serves as a focal point for addressing cyber security within
the Department of the Interior. Bureau Chief Information Officers,
Deputy Chief Information Officers, Bureau Chief Information Security
Officers (BCISO), and many DOI IT personnel provide critical cyber
security services that protect the confidentiality, integrity and
availability of information and enable timely, uninterrupted and trusted
DOI services. These individuals play critical roles in protecting DOI
from cyber threats, vulnerabilities, and intrusions; providing assurance
that cost-effective cyber security controls are in place to protect
automated information systems from resource fraud, waste and abuse.

To facilitate roles and responsibilities, the following groups are
considered in a position of trust for the Department of the Interior and
require the following levels of security clearance:

The following positions are critical assets within the Department and
therefore the individuals assigned to these positions require access to
**Top Secret SCI components** (TS/SCI):

-   Department Chief Information Officer

-   Department Deputy Chief Information Officer

-   Department Chief Information Security Officer

-   Department Deputy Chief Information Security Officer

-   Designated Lead for National Communications System (NCS)

-   Personnel designated for support to Continuity of Government
    programs

The following positions are critical assets within Interior and
therefore the individuals assigned to these positions require access to
**Top Secret** information (TS only), and may require access to **Top
Secret SCI components** (TS/SCI). Security clearances at the TS/SCI
level for these positions should be considered on an as needed basis
with additional appropriate justifications submitted through the Office
of the Chief Information Officer (OCIO) for consideration by the Office
of Law Enforcement, Security & Emergency Management (OLESEM):

-   Designated Approving/Accrediting Authorities (DAAs)

-   Bureau Chief Information Officers

-   Bureau Chief Information Security Officers (BCISOs)

-   Department's Enterprise Infrastructure Division (EID) Chief

The following positions are critical assets within Interior and
therefore the individuals assigned to these positions require access to
**Top Secret** information (TS only):

-   Bureau Deputy Chief Information Officers

-   Department DOI-CIRC Government Leads

-   Department's Enterprise Infrastructure Division (EID) Deputy
    Director

-   Department's Enterprise Services Network (ESN) System Manager,
    Incident Response Lead(s), and Information System Security Officer
    (ISSO)

```{=html}
<!-- -->
```
-   Department's Enterprise Infrastructure Division (EID) Designated
    Lead Support for ESN Planning & Deployment

-   Department's Enterprise Infrastructure Division (EID) Designated
    Lead Support for Incident Response & Continuity of Operations

-   OS/Bureau personnel designated for IT support to Continuity of
    Operations programs

The following positions may require access to **Top Secret** information
(TS only) and should be considered on an as needed basis with additional
appropriate justifications submitted for consideration by the associated
Departmental, Bureau or Office Chief Information Officer:

-   OS/Bureau IT personnel responsible for the architecture, control,
    delivery, deployment, maintenance, oversight, planning, and tracking
    of **critical infrastructure components**

The following positions are critical assets within Interior and
therefore the individuals assigned to these positions require access to
**Secret** information (Secret only):

-   Designated Lead(s)for Radio & Radio classified materials

-   Designated Verizon Lead ESN Network Operations and Security Center
    (NOSC) Engineering Support for Cyber Security Monitoring,
    Deployment, and Incident Response

-   Designated ESN Deputy Security Officer and Incident Manager Support
    for Cyber Security Incident Response and Law Enforcement Liaison

The following positions may require access to **Secret** information
(Secret only) and should be considered on an as needed basis with
additional appropriate justifications submitted for consideration by the
associated Departmental, Bureau or Office Chief Information Officer:

-   OS/Bureau IT personnel responsible for the architecture, control,
    delivery, deployment, maintenance, oversight, planning, and tracking
    of **critical infrastructure components**

The following positions are critical assets within the Office of the
Chief Information Officer and therefore shall be designated as **Public
Trust** positions:

-   All ESN Contractors (unless otherwise noted)

This access will promote:

1.  Quality control in security design and IT administration within DOI.

2.  Collaboration between OCIO and Bureaus in cyber security
    investigations.

3.  Detection of the preambles to attacks against the DOI enterprise.

4.  Contributions in the formation of DOI cyber security policy.

5.  Improved diagnosis, recovery, and correction of causative factors.

6.  The reception of timely information regarding critical cyber
    threats.

7.  An understanding of advanced attack methodologies and other security
    violations that have an impact on DOI sensitive infrastructure
    components such as SCADA systems.

# Policy Controls

This IT Security Policy Handbook is structured in a manner that conforms
to the NIST Federal Information Processing Standard Publication (FIPS
Pub) 200, *Minimum Security Requirements for Federal Information and
Information Systems*, and aligns with the following seventeen (17)
families of management, operational, and technical controls identified
in the associated NIST Special Publication (SP) 800-53, *Recommended
Security Controls for Federal Information Systems*. Both FISMA and
OMB[^1] require that agencies follow NIST standards and guidelines.

The minimum security requirements cover seventeen security-related areas
with regard to protecting the confidentiality, integrity, and
availability of federal information systems and the information
processed, stored, and transmitted by those systems. The
security-related areas include: (i) access control; (ii) awareness and
training; (iii) audit and accountability; (iv) certification,
accreditation, and security assessments; (v) configuration management;
(vi) contingency planning; (vii) identification and authentication;
(viii) incident response; (ix) maintenance; (x) media protection; (xi)
physical and environmental protection; (xii) planning; (xiii) personnel
security; (xiv) risk assessment; (xv) systems and services acquisition;
(xvi) system and communications protection; and (xvii) system and
information integrity. The seventeen areas represent a broad-based,
balanced information security program that addresses the management,
operational, and technical aspects of protecting federal information and
information systems.

The policies included in this handbook are aligned with the security
controls derived from the security control catalog contained within the
NIST SP 800-53. The security controls in the security control catalog
have a well-defined organization and structure that is organized into
*classes* and *families* for ease of use in the control selection and
specification process. There are three general classes of security
controls (i.e., management, operational, and technical). Each family
contains security controls related to the security function of the
family. A two-character identifier is assigned to uniquely identify each
control family. The following table summarizes the classes and families
in the security control catalog and the associated family identifiers.

  ------------ ----------------------------------------------- -------------
  IDENTIFIER   FAMILY                                          CLASS

  AC           Access Control                                  Technical

  AT           Awareness and Training                          Operational

  AU           Audit and Accountability                        Technical

  CA           Certification, Accreditation, and Security      Management
               Assessments                                     

  CM           Configuration Management                        Operational

  CP           Contingency Planning                            Operational

  IA           Identification and Authentication               Technical

  IR           Incident Response                               Operational

  MA           Maintenance                                     Operational

  MP           Media Protection                                Operational

  PE           Physical and Environmental Protection           Operational

  PL           Planning                                        Management

  PS           Personnel Security                              Operational

  RA           Risk Assessment                                 Management

  SA           System and Services Acquisition                 Management

  SC           System and Communications Protection            Technical

  SI           System and Information Integrity                Operational
  ------------ ----------------------------------------------- -------------

[]{#__RefHeading___Toc193514775 .anchor}Table 3: Security Control
Classes, Families, and Identifiers

**Specifications for Minimum Security Requirements**

**Access Control (AC):** Organizations must limit information system
access to authorized users, processes acting on behalf of authorized
users, or devices (including other information systems) and to the types
of transactions and functions that authorized users are permitted to
exercise.

**Awareness and Training (AT):** Organizations must: (i) ensure that
managers and users of organizational information systems are made aware
of the security risks associated with their activities and of the
applicable laws, Executive Orders, directives, policies, standards,
instructions, regulations, or procedures related to the security of
organizational information systems; and (ii) ensure that organizational
personnel are adequately trained to carry out their assigned information
security-related duties and responsibilities.

**Audit and Accountability (AU):** Organizations must: (i) create,
protect, and retain information system audit records to the extent
needed to enable the monitoring, analysis, investigation, and reporting
of unlawful, unauthorized, or inappropriate information system activity;
and (ii) ensure that the actions of individual information system users
can be uniquely traced to those users so they can be held accountable
for their actions.

**Certification, Accreditation, and Security Assessments (CA):**
Organizations must: (i) periodically assess the security controls in
organizational information systems to determine if the controls are
effective in their application; (ii) develop and implement plans of
action designed to correct deficiencies and reduce or eliminate
vulnerabilities in organizational information systems; (iii) authorize
the operation of organizational information systems and any associated
information system connections; and (iv) monitor information system
security controls on an ongoing basis to ensure the continued
effectiveness of the controls.

**Configuration Management (CM):** Organizations must: (i) establish and
maintain baseline configurations and inventories of organizational
information systems (including hardware, software, firmware, and
documentation) throughout the respective system development life cycles;
and (ii) establish and enforce security configuration settings for
information technology products employed in organizational information
systems.

**Contingency Planning (CP):** Organizations must establish, maintain,
and effectively implement plans for emergency response, backup
operations, and post-disaster recovery for organizational information
systems to ensure the availability of critical information resources and
continuity of operations in emergency situations.

**Identification and Authentication (IA):** Organizations must identify
information system users, processes acting on behalf of users, or
devices and authenticate (or verify) the identities of those users,
processes, or devices, as a prerequisite to allowing access to
organizational information systems.

**Incident Response (IR):** Organizations must: (i) establish an
operational incident handling capability for organizational information
systems that includes adequate preparation, detection, analysis,
containment, recovery, and user response activities; and (ii) track,
document, and report incidents to appropriate organizational officials
and/or authorities.

**Maintenance (MA):** Organizations must: (i) perform periodic and
timely maintenance on organizational information systems; and (ii)
provide effective controls on the tools, techniques, mechanisms, and
personnel used to conduct information system maintenance.

**Media Protection (MP):** Organizations must: (i) protect information
system media, both paper and digital; (ii) limit access to information
on information system media to authorized users; and (iii) sanitize or
destroy information system media before disposal or release for reuse.

**Physical and Environmental Protection (PE):** Organizations must: (i)
limit physical access to information systems, equipment, and the
respective operating environments to authorized individuals; (ii)
protect the physical plant and support infrastructure for information
systems; (iii) provide supporting utilities for information systems;
(iv) protect information systems against environmental hazards; and (v)
provide appropriate environmental controls in facilities containing
information systems.

**Planning (PL):** Organizations must develop, document, periodically
update, and implement security plans for organizational information
systems that describe the security controls in place or planned for the
information systems and the rules of behavior for individuals accessing
the information systems.

**Personnel Security (PS):** Organizations must: (i) ensure that
individuals occupying positions of responsibility within organizations
(including third-party service providers) are trustworthy and meet
established security criteria for those positions; (ii) ensure that
organizational information and information systems are protected during
and after personnel actions such as terminations and transfers; and
(iii) employ formal sanctions for personnel failing to comply with
organizational security policies and procedures.

**Risk Assessment (RA):** Organizations must periodically assess the
risk to organizational operations (including mission, functions, image,
or reputation), organizational assets, and individuals, resulting from
the operation of organizational information systems and the associated
processing, storage, or transmission of organizational information.

**System and Services Acquisition (SA):** Organizations must: (i)
allocate sufficient resources to adequately protect organizational
information systems; (ii) employ system development life cycle processes
that incorporate information security considerations; (iii) employ
software usage and installation restrictions; and (iv) ensure that
third-party providers employ adequate security measures to protect
information, applications, and/or services outsourced from the
organization.

**System and Communications Protection (SC):** Organizations must: (i)
monitor, control, and protect organizational communications (i.e.,
information transmitted or received by organizational information
systems) at the external boundaries and key internal boundaries of the
information systems; and (ii) employ architectural designs, software
development techniques, and systems engineering principles that promote
effective information security within organizational information
systems.

**System and Information Integrity (SI):** Organizations must: (i)
identify, report, and correct information and information system flaws
in a timely manner; (ii) provide protection from malicious code at
appropriate locations within organizational information systems; and
(iii) monitor information system security alerts and advisories and take
appropriate actions in response.

**Security Control Selection Following Information System Impact Level
Determination**

The determination of information system impact levels must be
accomplished prior to the consideration of minimum security requirements
and the selection of appropriate security controls for those information
systems. NIST SP 800-60, *Guide for Mapping Types of Information and
Information Systems*, should be used to identify all of the information
types that will be stored, processed or transmitted by the system and
specifies the provisional risk impact ratings (in terms of low,
moderate, or high) based on the confidentiality, integrity, and
availability objectives for each type of information. NIST FIPS Pub 199,
*Standards for Security Categorization of Federal Information and
Information Systems*, should be utilized to validate the provisional
risk impact ratings and determine the final overall potential risk
impact rating as low-impact, moderate-impact, or high-impact for each of
the security objectives for confidentiality, integrity, and
availability. The potential risk impact values assigned to the
respective security objectives are the highest values (i.e., high water
mark) identified by the security categories that have been determined
for each type of information, identified using NIST SP 800-60, resident
on those information systems. Finally, the resulting overall system
security categorization of the information systems must be determined.
The generalized format for expressing the security categorization (SC)
of an information system is:

**SC** ~information\ system~ = {(**confidentiality**, *impact*),
(**integrity**, *impact*), (**availability**, *impact*)},

where the acceptable values for potential impact are low, moderate, or
high.

Since the potential impact values for confidentiality, integrity, and
availability may not always be the same for a particular information
system, the high water mark concept must be used to determine the
overall impact level of the information system. Thus, a *low-impact
system* is an information system in which all three of the security
objectives are low. A *moderate-impact system* is an information system
in which at least one of the security objectives is moderate and no
security objective is greater than moderate. And finally, a *high-impact
system* is an information system in which at least one security
objective is high.

A key point is to ensure that system developers and system owners
understand that the security requirements for information systems are
based on the security categorization of the information and information
system, in accordance with FIPS 199 using the NIST SP 800-60 to identify
the provisional system security category. The final categorization
determination decision should be made by the business process owner, who
is typically the AO/DAA for the relevant business area of the
organization. The decision goes beyond the system level and should be
made by an individual with a broad perspective of the overall business
process(es) that the system will support. It is vital to properly
categorize the system because this will set the basis for all of the
certification and accreditation activities and the selection and
implementation of appropriate controls.

Interior's bureaus and offices must meet the minimum security
requirements in the NIST standard by selecting the appropriate security
controls and assurance requirements as described in NIST SP 800-53 that
is based on the security categorization of the information and
information system. The process of selecting the appropriate security
controls and assurance requirements for organizational information
systems to achieve *adequate security* is a multifaceted, risk-based
activity involving management and operational personnel within the
organization. Security categorization of federal information and
information systems, as required by FIPS Publication 199, is the first
step in the risk management process. Subsequent to the security
categorization process, organizations must select an appropriate set of
security controls for their information systems that satisfy the minimum
security requirements set forth in the NIST SP 800-53 standard. The
selected set of security controls must include one of three,
appropriately tailored security control baselines from NIST SP 800-53
that are associated with the designated impact levels of the
organizational information systems as determined during the security
categorization process.

> \- For *low-impact* information systems, organizations must, as a
> minimum, employ appropriately tailored security controls from the low
> baseline of security controls defined in NIST SP 800-53 and must
> ensure that the minimum assurance requirements associated with the low
> baseline are satisfied. Note however, that OMB circular and/or
> memorandum may have increased the mandatory requirements above what
> the NIST SP 800-53 requires. This policy handbook takes these
> modifications into account. For example, NIST SP 800-53 does not
> require testing of contingency plans for information systems having a
> low risk impact rating. However, OMB M-07-19 does require all agencies
> to test contingency plans even for information systems having a
> low-impact rating.
>
> \- For *moderate-impact* information systems, organizations must, as a
> minimum, employ appropriately tailored security controls from the
> moderate baseline of security controls defined in NIST SP 800-53 and
> must ensure that the minimum assurance requirements associated with
> the moderate baseline are satisfied.
>
> \- For *high-impact* information systems, organizations must, as a
> minimum, employ appropriately tailored security controls from the high
> baseline of security controls defined in NIST SP 800-53 and must
> ensure that the minimum assurance requirements associated with the
> high baseline are satisfied.

Organizations must employ all security controls in the respective
security control baselines unless specific exceptions are allowed based
on the tailoring guidance provided in NIST SP 800-53.

To ensure a cost-effective, risk-based approach to achieving adequate
security across the organization, security control baseline tailoring
activities must be coordinated with and approved by appropriate
organizational officials (e.g., chief information officers, senior
agency information security officers, authorizing officials, or
authorizing officials designated representatives). The resulting set of
security controls must be documented in the security plan for the
information system.

**Application of this IT Security Policy Handbook Following Security
Control Selection**

Policies, standards and procedures play an important role in the
effective implementation of enterprise-wide information security
programs within the federal government and the success of the resulting
security measures employed to protect federal information and
information systems. Thus, Interior and its bureaus and offices must
develop and promulgate formal, documented policies and procedures
governing the minimum security requirements set forth in the NIST
standards and must ensure their effective implementation. Bureaus and
offices may develop additional IT security policies to the extent that
such policies are:

-   consistent with, and complimentary to, this IT Security Policy
    Handbook,

-   more stringent, and not less stringent, than this IT Security Policy
    Handbook,

-   used to augment, and not replace or serve as an alternative to, this
    IT Security Policy Handbook, and

-   used to address bureau/office specific IT security issues and risks
    not already addressed by this IT Security Policy Handbook.

Although NIST SP 800-53 identifies minimum security control requirements
based on the risk impact levels of an information system, there are a
number of areas where that standard leaves it to the discretion of each
agency to establish "organization-defined security control parameters."
Interior has determined that the most effective means of establishing
consistency in the enterprise-wide implementation of these parameters is
through the issuance of this policy handbook and supporting
implementation standards that specify mandatory organization-defined
security control parameters for all of Interior's bureaus and offices
information and information systems relative to the NIST SP 800-53
required controls. For this reason, Interior has opted to structure this
IT Security Policy Handbook following the same general security control
model as the NIST SP 800-53. The first control within each of the
seventeen families of controls within the NIST SP 800-53 essentially
require that each organization develops, disseminates, and periodically
reviews/updates: (i) a formal, documented policy regarding each family
of security controls that addresses purpose, scope, roles,
responsibilities, and compliance; and (ii) formal, documented procedures
to facilitate the implementation of the each of those policies and
associated controls. The Department will establish the minimum policy,
standards, and procedures within the framework of this policy handbook
to the extent consistency and standardization are appropriate and where
enterprise-level policies, standards and procedures are sufficiently
scoped to either address the requirements and/or needs at either the
Departmental or bureau/office level, or both. Where necessary, this
policy handbook will include additional "issue-specific" policies as
appendices where there is a need to address special risks or concerns by
the Department. The "issue-specific" policies may be necessary where the
general policies provided in this handbook, in alignment with the NIST
SP 800-53, do not address those risks/concerns either in whole or in
part.

Traditionally, individual IT security policies were developed to address
"issue-specific" risks and IT security concerns requiring constant
redundant reiteration of a large and diverse set of IT security policy
principles that are generally common towards ensuring the protection of
any type of information or information system. Since NIST established
the minimum mandatory security controls to protect information and
information systems based on the potential risk impact level, the NIST
standards now provide the framework which Interior has used to develop
this policy handbook and associated standards, that is logically
organized according to that same construct. The benefit of this
construct is that it (1) facilitates alignment with, and helps to ensure
consistent implementation of, Interior's IT security policies relative
to the NIST SP 800-53 families of controls (2) enables Interior and its
bureaus and offices to demonstrate the existence of common controls in
the areas of required management controls (policies and standards), and
in some cases operational controls (procedures) where appropriate (3)
establishes consistency and standardization of required minimum policies
and standards in support of the Certification and Accreditation (C&A) of
information systems (unless additional system-specific policies are also
needed to further augment agency policy) that necessitates alignment of
this policy handbook to the applicable control families, and (4)
supports the annual IT security self-assessments of IT Security Programs
and information systems as part of the annual Internal Control Review
(ICR) process.

Although there are various interpretations of the term policy, this IT
Security Policy Handbook is intended to establish overall policy on
information access and safeguard for the agency (Interior and its
bureaus and offices). This IT Security Policy Handbook is Interior's
senior management's directives to create a computer security program,
establish its goals, assign responsibilities, and identify a minimum set
of security policies, standards, and procedures that govern the
management, operational, and technical controls appropriate, applicable,
and relevant to the protection of, and commensurate with the potential
risk impacts to, Interior's information and information systems. The
provision described above, authorizing bureaus and offices to establish
additional IT security policies, apply to the establishment and
implementation of subordinate policies that are used to refine and
implement this broader agency policy.

This policy handbook spans the policy domains of program management
policies addressing the broad organization-wide computer security
program, issue-specific policies focusing on areas of current relevance
and concern (and sometimes controversy) to the agency, and most aspects
of management, operational, and technical controls relating to
information systems in general. It may be necessary for bureaus and
offices to develop and implement additional policies as previously
discussed both at the bureau/office IT security program and
system-specific levels as appropriate. System-specific policies are
typically more focused and address the unique requirements of that
particular system and its unique operating environment.

Consistent with the NIST security control families framework and
construct described above, this policy handbook uniquely identifies each
control using the same numeric identifier appended to the family
identifier to indicate the number of the control within the control
family. For example, CP-9 is the ninth control in the Contingency
Planning family.

Within the NIST SP 800-53, the security control structure consists of
three key components: (i) a *control* section; (ii) *supplemental
guidance* section; and (iii) a *control enhancements* section. The
control section provides a concise statement of the specific security
capability needed to protect a particular aspect of an information
system. The control statement describes specific security-related
activities or actions to be carried out by the organization or by the
information system. For some controls in the control catalog, a degree
of flexibility is provided by allowing the organizations to selectively
define input values for certain parameters associated with the controls.
This flexibility is achieved through the use of *assignment* and
*selection* operations within the main body of the control. Assignment
and selection operations provide an opportunity for an organization to
tailor the security controls to support specific mission, business, or
operational needs. For example, an organization can specify how often it
intends to conduct information system backups or how frequently it
intends to test its contingency plan. Once specified, the
organization-defined value becomes part of the control, and the
organization is assessed against the completed control statement. Some
assignment operations may specify minimum or maximum values that
constrain the values that may be input by the organization. Selection
statements also narrow the potential input values by providing a
specific list of items from which the organization must choose.
Interior's IT Security Policy Handbook specifies the values for the
assignment operations through the establishment of agency-wide policy
and associated standards to be implemented by all of Interior's bureaus
and offices. The supplemental guidance section in the NIST SP 800-53
provides additional information related to a specific security control
that organizations should consider when defining, developing, and
implementing security controls. The control enhancements section
provides statements of security capability to: (i) build in additional,
but related, functionality to a basic control; and/or (ii) increase the
strength of a basic control. In both cases, the control enhancements are
used in an information system requiring greater protection due to the
potential impact of loss or when organizations seek additions to a basic
control's functionality based on the results of a risk assessment.
Control enhancements are numbered sequentially within each control so
the enhancements can be easily identified when selected to supplement
the basic control. In the example above, if two of the three control
enhancements are selected, the control designation subsequently becomes
CP-9(1)(2).

Organizations must employ security controls to meet security
requirements defined by laws, executive orders, directives, policies, or
regulations (e.g., Federal Information Security Management Act, OMB
Circular A-130, Appendix III). The challenge for organizations is to
determine the most appropriate set of security controls, which if
implemented and determined to be effective in their application, would
comply with the stated security requirements. Selecting the appropriate
set of security controls to meet the specific, and sometimes unique,
security requirements of an organization is an important task -- a task
that demonstrates the organization's commitment to security and the due
diligence exercised in protecting the confidentiality, integrity, and
availability of their information and information systems.

To assist organization in making the appropriate selection of security
controls for their information systems, the concept of *baseline*
controls is introduced. Baseline controls are the minimum mandatory
security controls required for an information system based on the
system's security categorization in accordance with FIPS Pub 199. The
baseline controls serve as a starting point for organizations in
determining the appropriate safeguards and countermeasures necessary to
protect their information systems. Because the baselines are intended to
be broadly applicable starting points, modifications to the selected
baseline may be necessary in order to achieve adequate risk mitigation.
Such modifications are tied to the risk assessment and documented in the
security plan for the information system. Three sets of minimum
(baseline) controls have been identified corresponding to the
low-impact, moderate-impact, and high-impact levels defined in the
security categorization process. NIST SP 800-53 describes the associated
processes used in the security control selection in greater detail.
However, this policy handbook not only establishes Departmental policy
regarding the specification of agency-defined values for the previously
described assignment operations, but incorporates additional baseline
requirements resulting from either increased requirements from OMB, or
the Department that address issue-specific concerns. For example,
although NIST SP 800-53 does not require the testing of contingency
plans of information systems at the low impact level, OMB M-07-19
reiterates that consistent with previous OMB instructions, OMB does.
Such modifications are incorporated into the minimum (baseline) controls
and applicable policy within this handbook.

In relation to the NIST SP 800-53 as described above, the following is a
description of the structure of this policy handbook that consists of
the following key components:

-   Control Family,

-   Control Baselines,

-   Control Number,

-   Control Name,

-   Applicability;

-   Policy Statement(s),

-   Mandatory Policy Enhancement(s),

-   Recommended Policy Enhancement(s),

-   Policy Supplement(s),

-   Additional Policy Guidance, and

-   Policy Implementation Detail(s).

**Control Family**

There are seventeen (17) control families each having its own unique
name and corresponding two-character identifiers that are identical to
those used in the NIST SP 800-53. A two-character identifier is assigned
to uniquely identify each control family and a high-level description is
provided for each control family followed by the applicability, policy
statement, mandatory policy enhancement(s), recommended policy
enhancement(s), policy supplement(s), additional policy guidance, and
policy implementation detail, as needed.

**Control Baselines**

The control baseline immediately follows each control family description
and lists each of the security controls within the family in a tabular
format. The control baseline identifies the set of minimum mandatory
security controls, including any applicable security control
enhancements, that are required to be implemented for a system based on
the security categorization of the information and information system
(e.g., security categorization is the resulting high-water mark of the
potential risk impact rating determinations for confidentiality,
integrity, and availability as previously described).

**Control Number**

Each control family contains security controls related to the security
function of the family. Each security control, within the corresponding
control family, is identified using a numeric identifier appended to the
family identifier to indicate the number of the control within the
control family. For example, CP-9 is the ninth control in the
Contingency Planning family.

**Control Name**

Each security control within a control family also has a unique name
that briefly describes the security function of the control.

**Applicability**

The applicability statement for each security control identifies the
extent to which the security control is applicable to:

-   All Information Systems;

-   Moderate and High Impact Information Systems;

-   High Impact Information Systems;

-   Optional for all Information Systems;

-   Bureaus and Offices; or

-   Control Not Selected.

**Policy Statements**

The policy statement for each security control specifies Departmental
agency-wide policy regarding the associated security control.

**Mandatory Policy Enhancements**

The mandatory policy enhancements provide the additional policy
statements that correspond to each control enhancement identified in
NIST SP 800-53 that must be adhered to if the control enhancement is
required to be selected based on the minimum mandatory baseline set of
controls associated with the resulting security categorization of the
information system. These are more stringent policies and security
control requirements applicable to, and based on, the information
systems having varying degrees of greater potential risk impact levels.

**Recommended Policy Enhancements**

The recommended policy enhancements provide the additional policy
statements that correspond to each non-mandatory control enhancement
identified in NIST SP 800-53 that may be adopted by a bureau or office
for its information system as deemed appropriate by the Designated
Approving/Accrediting Authority (DAA) based on a risk assessment of the
information system. These are more stringent policies and security
controls that help to improve the overall security posture of an
information system and should be considered based on the risk assessment
and potential risk impact level of the system.

**Policy Supplements;**

Policy supplements correspond to the supplemental guidance sections of
each security control provided in the NIST SP 800-53 and establishes
additional specific mandatory Departmental agency-wide policy for the
related security control.

**Additional Policy Guidance**

Additional policy guidance also corresponds to the supplemental guidance
sections of each security control provided in the NIST SP 800-53.
However, in some instances the supplemental guidance provided in NIST SP
800-53 lends itself to the establishment of agency policies (as is the
case above regarding additional policy guidance which in the context of
this policy handbook constitutes mandatory agency-wide policy for
Interior when implementing the required control is applicable) while in
other instances that guidance is more informational and serves to
provide examples of things to consider when defining, developing, and
implementing security controls. To clarify, the additional policy
guidance is informational only.

**Policy Implementation Details**

Although not explicitly labeled as such, any remaining security control
specifications (e.g, AC-7 Account Lockout Policy, AC-7 Account Lockout
Application, etc.) that exist constitute mandatory Departmental
agency-wide policy for the related security control when implementing
the required control is applicable. Policies in this form provide
granularity where appropriate and are broadly applicable to the basic
requirements for the security control and must also be adhered to.

**Compliance and Non-Compliance**

Bureaus and offices shall fully implement the policies, standards, and
procedures specified in this IT Security Policy Handbook by September
30, 2008. Any bureau or office IT security program or information system
that is not in compliance with this policy handbook as of October 1,
2008 shall address all aspects of non-compliance through incorporation
of those aspects as weaknesses on the appropriate program- or
system-level Plan of Action and Milestones (POA&M).

As with any weakness associated with inadequate management, operational
or technical security controls, all aspects of noncompliance with the
policies and standards contained within this IT Security Policy Handbook
or bureau/office level security policies must be formally documented
within the appropriate information system Risk Assessment report. Any
documented acceptance of risk(s) requires the relevant Designated
Approving/Accrediting Authority (DAA) to formally acknowledge and accept
any associated risk(s), in writing, by signing the risk acceptance
statements. In considering whether or not to accept the risks
indefinitely, or for some specified time, the risk acceptance
documentation must identify any conditions and constraints under which
those risks will be accepted by the cognizant DAA (e.g., specified
acceptable duration within which the DAA will tolerate continued
acceptance of the risk, any required mitigating actions and/or
compensating controls to be implemented as interim protective measures,
etc.). Where the DAA is unwilling to accept risks indefinitely, the
weakness must be incorporated into the appropriate program- or
system-level POA&M. These are the appropriate means, and only formal
methods available, that are consistent with FISMA, OMB, and relevant
NIST standards and guidelines (associated with the Certification and
Accreditation process and risk management framework) by which weaknesses
are effectively documented, understood, acknowledged, accepted, managed,
and tracked. There are no provisions to request any other form of
exemption to policies and standards.

# Access Control (AC)

Logical access controls are the system-based mechanisms used to
designate who or what is to have access to a specific system resource
and the type of transactions and functions that are permitted. Bureaus
and offices shall comply with the NIST Special Publication 800-53,
Rev.1, Recommended Security Controls for Federal Information Systems,
identification and authentication controls listed in the following
table:

+------+-------------------------+-----------+------------+------------+
| Ac   |                         |           |            |            |
| cess |                         |           |            |            |
| Cont |                         |           |            |            |
| rols |                         |           |            |            |
+------+-------------------------+-----------+------------+------------+
|      |                         | Control   |            |            |
|      |                         | Baselines |            |            |
| Con  | Control Name            |           |            |            |
| trol |                         |           |            |            |
| Nu   |                         |           |            |            |
| mber |                         |           |            |            |
+------+-------------------------+-----------+------------+------------+
|      |                         | Low       | Moderate   | High       |
+------+-------------------------+-----------+------------+------------+
| AC-1 | Access Control Policy   | AC-1      | AC-1       | AC-1       |
|      | and Procedures          |           |            |            |
+------+-------------------------+-----------+------------+------------+
| AC-2 | Account Management      | AC-2      | AC-2 (1)   | AC-2 (1)   |
|      |                         |           | (2) (3)    | (2) (3)    |
|      |                         |           | (4)        | (4)        |
+------+-------------------------+-----------+------------+------------+
| AC-3 | Access Enforcement      | AC-3      | AC-3 (1)   | AC-3 (1)   |
+------+-------------------------+-----------+------------+------------+
| AC-4 | Information Flow        | Not       | AC-4       | AC-4       |
|      | Enforcement             | Selected  |            |            |
+------+-------------------------+-----------+------------+------------+
| AC-5 | Separation of Duties    | Not       | AC-5       | AC-5       |
|      |                         | Selected  |            |            |
+------+-------------------------+-----------+------------+------------+
| AC-6 | Least Privilege         | Not       | AC-6       | AC-6       |
|      |                         | Selected  |            |            |
+------+-------------------------+-----------+------------+------------+
| AC-7 | Unsuccessful Logon      | AC-7      | AC-7       | AC-7       |
|      | Attempts                |           |            |            |
+------+-------------------------+-----------+------------+------------+
| AC-8 | System Use Notification | AC-8      | AC-8       | AC-8       |
+------+-------------------------+-----------+------------+------------+
| AC-9 | Previous Logon          | Not       | Not        | Not        |
|      | Notification            | Selected  | Selected   | Selected   |
+------+-------------------------+-----------+------------+------------+
| A    | Concurrent Session      | Not       | Not        | AC-10      |
| C-10 | Control                 | Selected  | Selected   |            |
+------+-------------------------+-----------+------------+------------+
| A    | Session Lock            | Not       | AC-11      | AC-11      |
| C-11 |                         | Selected  |            |            |
+------+-------------------------+-----------+------------+------------+
| A    | Session Termination     | Not       | AC-12 (1)  | AC-12 (1)  |
| C-12 |                         | Selected  |            |            |
+------+-------------------------+-----------+------------+------------+
| A    | Supervision and Review  | AC-13     | AC-13 (1)  | AC-13 (1)  |
| C-13 | -- Access Control       |           |            |            |
+------+-------------------------+-----------+------------+------------+
| A    | Permitted Actions w/o   | AC-14     | AC-14 (1)  | AC-14 (1)  |
| C-14 | Identification or       |           |            |            |
|      | Authentication          |           |            |            |
+------+-------------------------+-----------+------------+------------+
| A    | Automated Marking       | Not       | Not        | AC-15      |
| C-15 |                         | Selected  | Selected   |            |
+------+-------------------------+-----------+------------+------------+
| A    | Automated Labeling      | Not       | Not        | Not        |
| C-16 |                         | Selected  | Selected   | Selected   |
+------+-------------------------+-----------+------------+------------+
| A    | Remote Access           | AC-17     | AC-17 (1)  | AC-17 (1)  |
| C-17 |                         |           | (2) (3)    | (2) (3)    |
|      |                         |           | (4)        | (4)        |
+------+-------------------------+-----------+------------+------------+
| A    | Wireless Access         | AC-18     | AC-18 (1)  | AC-18 (1)  |
| C-18 | Restrictions            |           | (2)        | (2)        |
+------+-------------------------+-----------+------------+------------+
| A    | Access Control for      | Not       | AC-19      | AC-19      |
| C-19 | Portable and Mobile     | Selected  |            |            |
|      | Systems                 |           |            |            |
+------+-------------------------+-----------+------------+------------+
| A    | Use of External         | AC-20     | AC-20 (1)  | AC-20 (1)  |
| C-20 | Information Systems     |           |            |            |
+------+-------------------------+-----------+------------+------------+

[]{#__RefHeading___Toc193514776 .anchor}Table 4: Access Controls

##  

## AC-1 -- Access Control Policy and Procedures 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update policy and procedure items regarding access control that are
bureau and office specific, and to clarify policy and procedures for all
items not defined by the agency, including:

1.  A formal, documented, access control policy that addresses purpose,
    scope, roles, responsibilities, management commitment, coordination
    among organizational entities, and compliance; and

2.  A formal, documented procedure to facilitate the implementation of
    the access control policy and associated access controls.

## AC-2 -- Account Management 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall manage all information system accounts,
including establishing, activating, modifying, reviewing, disabling, and
removing accounts. Bureaus and offices shall ensure information system
accounts are reviewed at least every 3 months.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to support the management of                           
  information system accounts.                                      

  \(2\) Bureaus and offices shall ensure information X              X
  systems automatically terminate temporary and                     
  emergency accounts after a maximum of 30 days.                    

  \(3\) Bureaus and offices shall ensure information X              X
  systems automatically disable inactive accounts                   
  after no more than 90 days.                                       

  \(4\) Bureaus and offices shall employ automated   X              X
  mechanisms to audit account creation,                             
  modification, disabling, and termination actions                  
  and notify, as required, appropriate individuals.                 
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514777 .anchor}Table 5: AC-2 -- Account
Management Mandatory Policy Enhancement(s):

#### Policy Supplement(s):

AC-2(a)

Bureaus and offices account management process shall include:

1.  the identification of account types (i.e., individual, group, and
    system),

2.  establishment of conditions for group membership, and

3.  assignment of associated authorizations.

AC-2(b)

Bureaus and offices shall identify authorized users of information
systems and specify access rights/privileges.

AC-2(c)

Bureaus and offices shall grant access to information systems based on:

1.  a valid need-to-know that is determined by assigned official duties
    and satisfying all personnel security criteria; and

2.  intended system usage.

For Privacy Act Systems: The "need to know" under Cyber Security
guidelines is different that "need to know" under the Privacy Act and
OMB PA guidelines. That is under the Privacy Act, "need to know" applies
to sharing information to those persons within the agency (not outside)
that info that is necessary for them to perform their duties and
compatible with the purpose of the creation of the Privacy Act system.

AC-2(d)

Bureaus and offices shall require proper identification for requests to
establish information system accounts and approve all such requests.

AC-2(e)

Bureaus and offices shall restrict, and approve use in writing, the use
of guest/anonymous accounts and remove, disable, or otherwise secure
unnecessary accounts.

AC-2(f)

Bureaus and offices shall ensure that account managers are notified when
information system users are terminated or transferred and associated
accounts are removed, disabled, or otherwise secured.

AC-2(g)

Account managers shall also be notified when users' information system
usage or need-to-know changes.

### AC-2 Account Management Procedures

Account management is a process whereby bureaus and offices manage and
maintain system accounts throughout their life cycle. Bureaus and
offices must ensure that account management documentation includes:

1.  Identification of account types (i.e., individual, group, and
    system) and establishment of conditions for group membership, and
    assignment of associated authorizations.

2.  Identification of authorized users of the information system and
    specified access rights/privileges.

3.  Identify access granted to the user based on:

    a.  a valid need-to-know that is determined by assigned official
        duties and satisfying all personnel security criteria; and

    b.  intended system usage.

4.  Account creation procedures, including procedures for supervisor
    account request and approval;

5.  Procedures and timeframes to notify account managers when
    information system users are terminated or transferred. Account
    managers should also be notified when users' information system
    usage or need-to-know changes.

6.  Procedures to remove, disable, or otherwise secured accounts to
    occur within 24 hours of notification of a change in user status
    such as:

    a.  Departs the agency voluntarily or involuntarily;

    b.  Transfers to another bureau or office within the agency;

    c.  Is suspended;

    d.  Goes on long term detail; or

    e.  Information system usage or need-to-know changes.

7.  Procedures for the review and auditing of accounts (federal
    employee, contractor, and "guest" accounts) to determine validity at
    least every 3 months or more frequently based on system
    categorization.

8.  Procedures to remove, disable, or otherwise secure unnecessary
    accounts.

## AC-3 -- Access Enforcement 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure all information systems enforce
assigned authorizations for controlling access to the system in
accordance with DOI policy.

#### 

#### 

#### Mandatory Policy Enhancement(s):

  ------------------------------------------------ -------------- ---------
  MANDATORY ENHANCEMENT(S)                         APPLICABLITY   

                                                   MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure that      X              X
  information systems restrict access to security                 
  functions (deployed in hardware, software, and                  
  firmware) and security-relevant information to                  
  explicitly authorized personnel (e.g., security                 
  administrators, system and network                              
  administrators, and other privileged users).                    
  ------------------------------------------------ -------------- ---------

[]{#__RefHeading___Toc193514778 .anchor}Table 6: AC-3 -- Access
Enforcement Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AC-3(a)

Bureaus and offices shall employ access control policies (e.g.,
identity-based policies, role-based policies, rule-based policies) and
associated access enforcement mechanisms (e.g., access control lists,
access control matrices, cryptography) to control access between users
(or processes acting on behalf of users) and objects (e.g., devices,
files, records, processes, programs, domains) in the information system.

AC-3(b)

In addition to controlling access at the information system level,
access enforcement mechanisms shall be employed at the application level
to provide increased information security for the organization.

AC-3(c)

If encryption of stored information is employed as an access enforcement
mechanism, the cryptography used shall be FIPS 140-2, *Security
requirements for Cryptographic Modules (*as amended) compliant.

AC-3(d)

If the federal Personal Identity Verification (PIV) credential is used
as a identification token where token-based access control is employed,
the access control system shall conform to the requirements of FIPS 201,
Personal Identity Verification (PIV) of Federal Employees and
Contractors and NIST Special Publication 800-73, Interfaces for Personal
Identity Verification, and employ either cryptographic verification or
biometric verification.

AC-3(e)

If the token-based access control employs cryptographic verification,
the access control system shall conform to the requirements of NIST
Special Publication 800-78, *Cryptographic Algorithms and Key Sizes for
Personal Identity Verification*.

AC-3(f)

If the token-based access control employs biometric verification, the
access control system shall conform to the requirements of NIST Special
Publication 800-76, *Biometric Data Specification for Personal Identity
Verification*.

## AC-4 -- Information Flow Enforcement 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems enforce assigned authorizations for controlling the
flow of information within the system and between interconnected systems
in accordance with applicable policy.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  requiring information systems to implement                        
  information flow control enforcement using                        
  explicit labels on information, source, and                       
  destination objects as a basis for flow control                   
  decisions (e.g., to control the release of certain                
  types of information).                                            

  \(2\) Bureaus and offices should consider                         X
  requiring information systems to implement                        
  information flow control enforcement using                        
  protected processing domains (e.g., domain                        
  type-enforcement) as a basis for flow control                     
  decisions.                                                        

  \(3\) Bureaus and offices should consider                         X
  requiring information systems to implement                        
  information flow control enforcement using dynamic                
  security policy mechanisms as a basis for flow                    
  control decisions.                                                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514779 .anchor}Table 7: AC-4 -- Information
Flow Enforcement Recommended Policy Enhancement(s)

#### Additional Policy Guidance:

Information flow control regulates where information is allowed to
travel within an information system and between information systems (as
opposed to who is allowed to access the information) and without
explicit regard to subsequent accesses to that information.

A few, of many, generalized examples of possible restrictions that are
better expressed as flow control than access control are:

1.  keeping export controlled information from being transmitted in the
    clear to the Internet,

2.  blocking outside traffic that claims to be from within the
    organization, and

3.  not passing any web requests to the Internet that are not from the
    internal web proxy.

4.  Information flow control policies and enforcement mechanisms are
    commonly employed to control the flow of information between
    designated sources and destinations (e.g., networks, individuals,
    devices) within information systems and between interconnected
    systems.

Flow control is based on the characteristics of the information and/or
the information path. Specific examples of flow control enforcement can
be found in boundary protection devices (e.g., firewalls and routers)
that employ rule sets or establish configuration settings that restrict
information system services or provide a packet filtering capability.

## AC-5 -- Separation of Duties 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems enforce separation of duties through assigned access
authorizations.

#### Policy Supplement(s):

AC-5(a)

Bureaus and offices shall establish appropriate divisions of
responsibility and separate duties as needed to eliminate conflicts of
interest in the responsibilities and duties of individuals.

AC-5(b)

Bureaus and offices shall ensure that there is access control software
on information systems that prevents users from having all of the
necessary authority or information access to perform fraudulent activity
without collusion.

#### Additional Policy Guidance:

Examples of separation of duties include:

1.  mission functions and distinct information system support functions
    are divided among different individuals/roles;

2.  different individuals perform information system support functions
    (e.g., system management, systems programming, quality
    assurance/testing, configuration management, and network security);
    and

3.  security personnel who administer access control functions do not
    administer audit functions.

### 

### 

### AC-5 Assignment of Security Responsibilities

Bureaus and offices shall ensure that assignment of security
responsibilities must follow the principle of "separation of duties".
The following three categories of "duty" must be kept separate or
compensating controls in place to monitor activity closely.

-   IT administration or operation (assuring systems function, to serve
    the system users);

-   IT security (assuring adequacy of system controls for availability,
    integrity, and confidentiality); and

-   IT management (allocating adequate resources for implementation of
    effective IT security programs and system controls).

Due to staffing constraints found especially in smaller bureaus and
offices, it is acceptable for example, for a system administrator to
serve as a backup for an IT System Security Officer who is on leave.
However, while serving in a dual role, compensating management controls
must be implemented to ensure changes to the security posture are
properly authorized.

### AC-5 Separation of Duties Implementation

Separation of duties provides:

1.  a system of checks and balances;

2.  distribution of security responsibilities rather than investing in
    one individual or role;

3.  the best compromise between usability and security \-- the
    separation enables each person involved to vigorously pursue his/her
    individual duties, resulting in a reasonable compromise between
    usability and security with many people working to keep the balance;
    and

4.  a compensating control over the mere appearance of impropriety by
    those in a position to bypass IT security controls.

Heads of bureaus or offices, program officials, and System Owners must
apply this principle to positions that have the ability to circumvent IT
security controls, such as those involved with auditing of systems,
network administration, application programming, computer operations,
facility security, and any other security-related function. They must
examine the duties of an individual's role, and make sure those duties
do not conflict with one another. For example:

Authorizing Official: The authorizing official, or the authorizing
official's designated representative, must authorize, in writing, the IT
System Security Plan, all infrastructure security policies and
procedures, and all significant changes to the system hardware and
software configuration.

System Owner: The System Owner is responsible for the business operation
of the system and ensuring that the system meets mission needs in a
timely and secure manner, and that the system complies with all IT
security requirements including certification and accreditation.

##### **Information System Security Officer (ISSO**): 

1.  The ISSO executes day-to-day security operations and ensures that
    the authorized policies, procedures, and configurations approved by
    the Authorizing Official are [implemented]{.underline}.

2.  The ISSO is responsible for execution and testing of plans to ensure
    system integrity and availability and for overseeing staff of system
    administrators and engineers that maintain Infrastructure hardware
    and system software, install application software, and monitor
    system performance and security events.

3.  The ISSO must elevate performance anomalies to the System Owner and
    security anomalies to the bureau or office Chief Information
    Security Officer (BCISO) and the responsible incident response
    capability for assistance in resolution.

4.  The ISSO implements a regular schedule for vulnerability testing of
    system components, to ensure security patches are current on all
    devices, and that intrusion detection sensors (IDS) or system audit
    logs are properly configured and events are monitored.

5.  The ISSO is responsible for assessing the security impact of
    configuration changes to the system, evaluating cost-effective
    security alternatives, and approving security-related solutions.

##### Bureau Chief Information Security Officer (BCISO): 

The BCISO must monitor compliance of the bureau or office program and
information systems with applicable Departmental and federal
requirements and ensure the conduct of annual system and program
self-assessments of security controls in accordance with NIST Special
Publication 800-53, Rev.1. The BCISO also monitors the timely completion
of corrective actions to resolve control weaknesses identified in
self-assessments or external reviews of controls and coordinates with
the Department Chief Information Security Officer (CISO) on security
issues and reporting on the security posture of the system.

##### System Administration Staff: 

The system and network administrators and engineering staff execute the
configuration and maintenance direction of the ISSO as authorized in
writing by the System Owner.

Developers and development environment systems shall operate on
segregated or isolated subnets or networks from the production
environment. Further, developers shall not have access to production
code or databases. The production application administrators and DBAs
shall not be developers. Developer USERIDs shall function solely in the
development environment. Developers shall have a second USERID that
works in the production environment with user privileges.

## AC-6 -- Least Privilege 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems enforce the most restrictive set of
rights/privileges or accesses needed by users (or processes acting on
behalf of users) for the performance of specified tasks.

#### 

#### Policy Supplement(s):

AC-6(a)

Bureaus and offices shall employ the concept of least privilege for
specific duties and information systems (including specific ports,
protocols, and services) in accordance with risk assessments as
necessary to adequately mitigate risk to operations, assets, and
individuals shall be granted only that PII information which is
essential for the performance of a necessary function. E.g. -- don't
share SSNs when it is not required.

## AC-7 -- Unsuccessful Login Attempts 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems enforce a
maximum limit of 5 consecutive invalid access attempts by a user during
a 15 minute time period.

Bureaus and offices shall ensure that information systems automatically
locks the account or node for no less than 15 minutes and delays the
next login prompt according to the bureau or office defined delay
algorithm when the maximum number of unsuccessful attempts is exceeded.

#### Policy Supplement(s):

AC-7(a)

Due to the potential for denial of service, automatic lockouts initiated
by information systems should be temporary and automatically release
after the specified predetermined time period.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) The information system automatically locks                  X
  the account/node until released by an                             
  administrator when the maximum number of                          
  unsuccessful attempts is exceeded.                                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514780 .anchor}Table 8: AC-7 -- Unsuccessful
Login Attempts Recommended Policy Enhancement(s)

### AC-7 Account Lockout Policy

DOI has established the minimum account lockout policy within the policy
statement of AC-7; bureaus or offices are free to enhance the minimum
but not relax them. The bureau or office Chief Information Security
Officer creates the bureau security policies and helps to educate system
users and enforce tougher standards. Thus, account policies secure the
operating unit network at the first line of defense (and the one most
often breached). Automatic account lockout makes the entire network
safer from a brute force attack.

### AC-7 Account Lockout Application

The DOI account lockout policies apply to all IT resources owned or used
by DOI with capabilities for account lockout (including those that may
require supplementary software to add this capability.)

### AC-7 Additional Account Lockout Minimum Standards

Bureaus and offices shall ensure information systems are configured to:

1.  allow a maximum of five (5) invalid logon attempts;

2.  detect and log invalid logon attempts; and

3.  lock accounts for a pre-set time period of at least 15 minutes after
    which the account can be automatically reset.

Locked accounts with privileged access (i.e., root or administrator
access) will remain locked until unlocked by the help desk, security
administration, or other authorized account management personnel. In all
cases, some reasonable and verifiable means of identification shall be
employed, to request an account be unlocked (if and whenever feasible,
users will appear in person with verifiable official identification).

## AC-8 -- System Use Notification 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems display an
approved, system use notification message before granting system access
which informs potential users:

1.  that the user is accessing a U.S. Government information system;

2.  that system usage may be monitored, recorded, and subject to audit;

3.  that unauthorized use of the system is prohibited and subject to
    criminal and civil penalties; and

4.  that use of the system indicates consent to monitoring and
    recording.

Bureaus and offices shall ensure that system use notification messages
provide the appropriate privacy and security notices (based on
associated privacy and security policies or summaries) and remain on the
screen until the user takes explicit actions to log on to the
information system.

#### Policy Supplement(s):

AC-8(a)

For publicly accessible systems, bureaus and offices shall ensure:

1.  the system use information is available as opposed to displaying the
    information before granting access;

2.  there are no references to monitoring, recording, or auditing since
    privacy accommodations for such systems generally prohibit those
    activities; and

3.  the notice given to public users of the information system includes
    a description of the authorized uses of the system.

### AC-8 Primary Warning Banners

In order to notify users of their use of a government system,
information categories, consent to monitoring and penalties for misuse
of the system, the System Owner or other responsible management must
select and configure DOI information systems to display a warning banner
screen (or close approximation) at login, and require users to
electronically acknowledge the warning (such as clicking on "OK" or "I
agree" button to proceed)

In accordance with Public Law 99-474, it is DOI\'s policy that a warning
message be displayed to users accessing our computer systems prior to,
or as part of, the logon process where applicable.

The use of appropriate wording and application of warning banners is
required to ensure that users are duly notified that they are accessing
a United States Government computer system, access is for authorized
users only, and continued use constitutes consent to being monitored by
appropriate personnel. Failure to use the appropriate wording and
application of warning banners could seriously impair DOI\'s ability to
deal effectively with unauthorized or inappropriate system use.

This handbook provides the minimum wording and proper application for a
warning banner to be considered adequate. These requirements are
applicable to all information systems supporting DOI assets, including
those used as part of contracted and outsourced services. A warning
banner must be displayed for any system access, other than that used for
public, open to all access. Anonymous system access, such as a public
web server, does not require the display of a warning banner. The
following list is not exhaustive, but is intended to provide examples of
where warning banners would and would not be required.

Examples:

-   Access to a DOI desktop computer system or a network server requires
    the display of a warning banner.

-   Access to a DOI network requires the display of a warning banner.

-   Access to a DOI remote access solution requires the display of a
    warning banner.

-   Access to a DOI network device requires the display of a warning
    banner.

-   Access to a system owned, operated, and maintained by a DOI
    contractor on behalf of DOI requires the display of a warning
    banner.

-   Access to a public access system such as www.doi.gov does not
    require the display of a warning banner.

The following warning message provides the minimum wording to be
included in a warning banner. The DOI Office of the Solicitor and the
Department of Justice (DOJ) Computer Crimes and Intellectual Properties
Section have approved the wording. It is adapted from guidance provided
by the National Institute of Standards and Technology (NIST), and meets
the minimum requirement for warning banners as required in General
Support System or Major Application system security plans.

NON -- TRUST SYSTEMS

+-----------------------------------------------------------------------+
| TITLE: WARNING TO USERS OF THIS SYSTEM                                |
+-----------------------------------------------------------------------+
| This computer system, including all related equipment, networks, and  |
| network devices (including Internet access), is provided by the       |
| Department of the Interior (DOI) in accordance with the agency policy |
| for official use and limited personal use.                            |
|                                                                       |
| All agency computer systems may be monitored for all lawful purposes, |
| including but not limited to, ensuring that use is authorized, for    |
| management of the system, to facilitate protection against            |
| unauthorized access, and to verify security procedures, survivability |
| and operational security. Any information on this computer system may |
| be examined, recorded, copied and used for authorized purposes at any |
| time.                                                                 |
|                                                                       |
| All information, including personal information, placed or sent over  |
| this system may be monitored, and users of this system are reminded   |
| that such monitoring does occur. Therefore, there should be no        |
| expectation of privacy with respect to use of this system.            |
|                                                                       |
| By logging into this agency computer system, you acknowledge and      |
| consent to the monitoring of this system. Evidence of your use,       |
| authorized or unauthorized, collected during monitoring may be used   |
| for civil, criminal, administrative, or other adverse action.         |
| Unauthorized or illegal use may subject you to prosecution.           |
+-----------------------------------------------------------------------+

[]{#__RefHeading___Toc193514770 .anchor}Figure 1: Warning Banner for
Non-Trust Systems

TRUST SYSTEMS

+-----------------------------------------------------------------------+
| TITLE: WARNING TO USERS OF THIS SYSTEM                                |
+-----------------------------------------------------------------------+
| This computer system, including all related equipment, networks, and  |
| network devices, is provided by the Department of the Interior (DOI)  |
| in accordance with the agency policy for official use and limited     |
| personal use. This system may not be connected to the Internet, in    |
| any way, unless specifically authorized by the Office of the          |
| Secretary.                                                            |
|                                                                       |
| All agency computer systems may be monitored for all lawful purposes, |
| including but not limited to, ensuring that use is authorized, for    |
| management of the system, to facilitate protection against            |
| unauthorized access, and to verify security procedures, survivability |
| and operational security. Any information on this computer system may |
| be examined, recorded, copied and used for authorized purposes at any |
| time.                                                                 |
|                                                                       |
| All information, including personal information, placed or sent over  |
| this system may be monitored, and users of this system are reminded   |
| that such monitoring does occur. Therefore, there should be no        |
| expectation of privacy with respect to use of this system.            |
|                                                                       |
| By logging into this agency computer system, you acknowledge and      |
| consent to the monitoring of this system. Evidence of your use,       |
| authorized or unauthorized, collected during monitoring may be used   |
| for civil, criminal, administrative, or other adverse action.         |
| Unauthorized or illegal use may subject you to prosecution.           |
+-----------------------------------------------------------------------+

[]{#__RefHeading___Toc193514771 .anchor}Figure 2: Warning Banner for
Trust Systems

## AC-9 -- Previous Logon Notification 

#### Applicability:

Control Not Selected

Bureaus and offices shall ensure information systems notify the user,
upon successful logon, of the date and time of the last logon, and the
number of unsuccessful logon attempts since the last successful logon
when possible for systems as required by risk assessment.

## AC-10 -- Concurrent Session Control 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that High-impact information systems
limit the number of concurrent sessions for any user to a maximum of 2
sessions.

## AC-11 -- Session Lock 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems prevent further access to the system by initiating a
session lock after 15 minutes of inactivity that remains in effect until
the user reestablishes access using appropriate identification and
authentication procedures.

#### Policy Supplement(s):

AC-11(a)

Bureaus and offices shall ensure that users can directly initiate
session lock mechanisms.

AC-11(b)

Bureaus and offices shall inform users that a session lock is not a
substitute for logging out of the information system.

## AC-12 -- Session Termination 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems automatically terminate a remote session after a
maximum of 30 minutes of inactivity.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall apply the          X              X
  automatic session termination to local and remote                 
  sessions.                                                         
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514781 .anchor}Table 9: AC-12 -- Session
Termination Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AC-12(a)

A remote session is initiated whenever information systems are accessed
by a user (or an information system) communicating through an external,
non-organization-controlled network (e.g., the Internet).

## AC-13 -- Supervision and Review -- Access Control 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall supervise and review the activities of all
users with respect to the enforcement and usage of information system
access controls.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to facilitate the review of user                       
  activities.                                                       
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514782 .anchor}Table 10: AC-13 -- Supervision
and Review -- Access Control Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AC-13(a)

Bureaus and offices shall review audit records (e.g., user activity
logs) for inappropriate activities in accordance with bureau or office
documented procedures.

AC-13(b)

Bureaus and offices shall investigate any unusual information
system-related activities and periodically review changes to access
authorizations.

AC-13(c)

Bureaus and offices shall review the activities of users with
significant information system roles and responsibilities more
frequently.

AC-13(d)

Bureaus and offices shall ensure that those with access to Privacy Act
systems of records are aware of the specific guidelines for maintaining
and disclosing information from that Privacy Act system of records.

## AC-14 -- Permitted Actions without Identification or Authentication 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall identify and document specific user actions
that can be performed on the information system without identification
or authentication.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall permit actions to  X              X
  be performed without identification and                           
  authentication only to the extent necessary to                    
  accomplish mission objectives.                                    
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514783 .anchor}Table 11: AC-14 -- Permitted
Actions without Identification or Authentication Mandatory Policy
Enhancement(s)

#### 

#### 

#### Policy Supplement(s):

AC-14(a)

Bureaus and offices shall limit user activities without identification
and authentication for public websites or other publicly available
information systems (e.g., individuals accessing a federal information
system at http://www.firstgov.gov).

## AC-15 -- Automated Marking 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that High-impact information systems
mark output using standard naming conventions to identify any special
dissemination, handling, or distribution instructions.

#### Additional Policy Guidance:

Automated marking refers to markings employed on external media (e.g.,
hardcopy documents output from the information system). The markings
used in external marking are distinguished from the labels used on
internal data structures described in the Automated Labeling control.

## AC-16 -- Automated Labeling 

#### Applicability:

Control Not Selected

#### Policy Statement:

Bureaus and offices shall ensure that information systems appropriately
label information in storage, in process, and in transmission when
applicable.

AC-16(a)

Bureaus and offices shall ensure information labeling is accomplished in
accordance with:

1.  access control requirements;

2.  special dissemination, handling, or distribution instructions; or

3.  as otherwise required to enforce information system security policy.

Automated labeling refers to labels employed on internal data structures
(e.g., records, files) within the information system.

## AC-17 -- Remote Access 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall authorize, monitor, and control all methods of
remote access (e.g., dial-up, broadband, wireless) to all information
systems. Bureaus and offices not complying with this policy will be
physically disconnected from the ESN.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to facilitate the monitoring and                       
  control of remote access methods.                                 

  \(2\) Bureaus and offices shall use encryption to  X              X
  protect the confidentiality of remote access                      
  sessions.                                                         

  \(3\) Bureaus and offices shall control all remote X              X
  accesses through a limited number of managed                      
  access control points.                                            

  \(4\) Bureaus and offices shall prohibit remote    X              X
  access for privileged functions; or shall grant                   
  access on a case by case basis only for compelling                
  operational need and document the rationale for                   
  such access in the System Security Plan for the                   
  information system.                                               
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514784 .anchor}Table 12: AC-17 -- Remote Access
Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AC-17(a)

Bureaus and offices shall use cryptography to protect the
confidentiality and integrity of remote access sessions.

AC-17(a)

Remote access constitutes any access to DOI information systems by a
user (or an information system) communicating through an external,
non-organization-controlled network (e.g., the Internet).

AC-17(b)

Remote access controls are applicable to information systems other than
public web servers or systems specifically designed for public access.

AC-17(c)

Bureaus and offices shall restrict access achieved through dial-up
connections (e.g., limiting dial-up access based upon source of
request), protect against unauthorized connections and subversion of
authorized connections (e.g., using virtual private network technology).

### AC-17 Teleworking

The DOI Telework Policy provides eligible employees with a potential
opportunity to work at an alternative worksite. Typically, the
alternative worksite is the employee\'s home or a GSA authorized
telework center which is away from the office where most of the DOI IT
resources reside. Frequently, teleworking requires external access to
internal agency resources (such as networked file storage, intranet
services, e-mail services, and other networked resources residing at a
location recognized to be under the control of the users' organization).

All Bureau or Office telework programs shall be in compliance with NIST
SP 800-46 Security for Telecommuting and Broadband Communications. By
Fiscal Year 2009 this access shall be exclusively provided through
agency approved communication channels (e.g. VPN, RAS, or I-PASS) with
government owned computers or PED/PDAs.

### AC-17 Remote Access and PII

As a mitigation to the risk associated with the potential loss of
sensitive information on remote access systems the following
compensating controls shall be implemented on any system, server,
workstation, or PED/PDAs connecting to or interfacing with protected
internal agency resources:

1.  Multi-factor authentication

2.  Whole disk encryption

3.  File and folder encryption

4.  Host-based Anti-Virus software

5.  Host-based firewall

6.  Patch management

7.  Security Technical Implementation Guides (STIGs)

8.  Virtual Private Network (VPN) / Encryption of data in transit

Additionally, access to sensitive agency data must be logged; and all
data remnants and data extracts accounted for and periodically reviewed.
If sensitive data is stored on the system or on a physical storage
device, it must be verified that each extract has been erased within 90
days or its use is still required.

Bureaus and offices are required to ensure FIPS 140-2 validated
encryption of all mobile media and devices (e.g., removable media,
portable/mobile devices, remote workstations, etc.) containing agency
data taken outside of the Agency's secured physical perimeter (e.g., to
a personal residence, on either business or personal travel -- even if
traveling to another controlled facility, etc.), unless the data is
determined to be non-sensitive, in writing, by the Deputy Secretary or
an individual designated in writing by the Deputy Secretary.

As an interim mitigation to the risks associated with the potential loss
or theft of PII or Department sensitive information, bureaus and offices
that currently do not have an encryption solution for mobile devices
(e.g., laptops and remote workstations/servers) are minimally required
to take the following actions until an Enterprise-wide encryption
solution can be procured.

All bureaus and offices shall:

-   implement the DOI approved common enterprise encryption solution(s)
    for Data-at-Rest (DAR) on all remote/portable/mobile devices, as
    appropriate;

-   implement the Encrypting File System (EFS), or equivalent, for
    Windows-based systems as an interim solution pending availability of
    the common enterprise encryption solution(s);

-   implement FileVault, or equivalent, for Macintosh-based systems; and

-   for other operating systems, bureaus and offices must identify and
    implement an appropriate solution to provide file-level encryption
    at a minimum.

A standard secondary Message Banner for deployment on all remote access
points was developed by the Encryption Working Group (EWG) and was
approved by the Solicitor's Office. Bureaus and offices shall ensure
that the following secondary Message Banner is deployed:

> "WARNING - Before you download Department of the Interior (DOI) data
> to a computer or any other device capable of storing electronic data
> you must comply with DOI standards for data encryption and system
> security. You must also understand and agree to comply with DOI
> requirements for deleting the data. Contact your Bureau Chief
> Information Security Officer for specifications regarding these
> standards and requirements. Failure to comply may result in criminal,
> civil, and/or disciplinary action."

Bureaus and offices are required to have equivalent language to the
following standard elements, or incorporate those elements into their
existing Rules of Behavior (RoB), to address the protection of PII and
sensitive data, Remote Access, and mobile computing device usage. The
Solicitor's Office has approved the following standard RoB elements
developed by the EWG after a thorough review by the Human Resources
Office and a representative subset of government worker Unions:

> Special Considerations for Remote Access --
>
> Access of agency resources from a location not under the direct
> control of the ESN or {bureau or office name} is considered "Remote
> Access". New technical solutions are being implemented to secure and
> protect agency data, especially if it is being carried outside of the
> ESN or {bureau or office name}'s physically protected areas. With
> these new requirements also come new responsibilities for user
> behavior regarding the protection of agency data. Users must secure
> and protect agency data as follows:

1.  Users must physically protect all hardware or software based tokens
    entrusted to them for authentication or encryption purposes. (A
    token is usually a physical device that an authorized user is given
    to provide additional higher level security and to verify the user
    is who they say they are when logging in to the network.)

2.  Users must encrypt all agency data stored on any equipment,
    including but not limited to computers, external hard drives, PDAs,
    and thumb/flash drives, anytime they are outside of {bureau or
    office name} protected facilities.

3.  Users must ensure that all agency data downloaded using remote
    access is erased after 90 days or when it is no longer needed.

4.  Users should refer to their Bureau Chief Information Security
    Officer for standards and approved methods for encrypting and
    deleting data.

Bureaus and offices not having implemented the requirements specified
are to develop, maintain, and revise as necessary Plans of Action and
Milestones (POA&Ms).

OMB memorandum M-06-16 requires determinations of non-sensitive data to
be in writing by the Deputy Secretary, or an individual designated in
writing by the Deputy Secretary, in order to waive the encryption
requirements on specific mobile devices. The Deputy Secretary has
delegated this authority to the Department CIO and restricted further
delegation of this authority. To enable the CIO to accurately evaluate
requests for determination of non-sensitive data in a system, the
attached "Certification and Request for Determination of Non-Sensitive
Data" request template shall be used. The signature of the Designated
Approving/Accrediting Authority (DAA) on the request shall be the senior
management official, within the requesting bureau or office, designated
as the DAA responsible for risk acceptance and accreditation of the
Certification and Accreditation (C&A) information system boundary with
which the mobile computing devices are associated

## AC-18 -- Wireless Access Restrictions 

#### Applicability:

All Information Systems

#### Policy Statement:

#### This policy supersedes:

-   OCIO Directive 2005-012, "Wireless Network Security," and

-   OCIO Directive 2004-018, "Prohibition on Use of Wireless Network
    Technology"

Bureaus and offices shall:

-   establish usage restrictions and implementation guidance for
    wireless technologies; and

-   authorize, monitor, and control wireless access to information
    systems.

#### 

#### 

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall use authentication X              X
  and encryption to protect wireless access                         
  information systems.                                              

  \(2\) Bureaus and offices shall scan for           X              X
  unauthorized wireless access points on a monthly                  
  basis and take appropriate action if such access                  
  points are discovered. Bureaus and offices should                 
  conduct thorough scans for unauthorized wireless                  
  access points in facilities containing high-impact                
  information systems. Scans should not be limited                  
  to only those areas within the facility containing                
  the high-impact information systems.                              
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514785 .anchor}Table 13: AC-18 -- Wireless
Access Restrictions Mandatory Policy Enhancement(s)

### AC-18 Wireless Access and Networking

Wireless access enables access to Department information using a
radio-wave technology that does not require physical connection of
equipment to data or phone outlets. The wireless devices and
technologies includes:

-   CDMA, GPRS, EDGE, WiMAX;

-   Bluetooth;

-   VSAT; and

-   802.11a/b/g.

Implementing wireless access necessitates addressing several security
issues. When implementing wireless access to Department systems, a key
consideration is the type of information and impact level accessed via
wireless platform (e.g., e-mail, databases, and Web sites). When
implementing wireless networking for Department resources, major
concerns include:

-   security of the wireless networking protocols;

-   confidentiality;

-   authentication; and

-   service provider agreements.

Wireless access and networking should not be implemented without the
approval of the bureau or office CIO. However, bureaus and offices are
allowed to implement wireless technologies in their environments
provided bureaus and offices:

1.  Establish a strategic plan to manage existing and emerging wireless
    technologies, including security provisions and methods for
    management controls;

2.  Establish a formal approval process for authorizing new wireless
    network pilot projects or existing wireless networks and devices
    that incorporates:

    a.  Assessing the sensitivity of data that is processed, transmitted
        and stored;

    b.  Conducting risk assessments and technical vulnerability tests
        and developing corrective actions for identified security
        weaknesses; and

    c.  Certifying and Accrediting wireless implementations as part of
        either a General Support System (GSS) or Major Application (MA),
        as appropriate, and ensure implementation of the policies,
        requirements, standards, and STIGs consistent with this policy
        handbook.

3.  Compile an accurate inventory of all wireless networks and devices
    that can be used to connect to wireless networks;

4.  Ensure all IT professionals managing wireless networks and all users
    of wireless devices receive appropriate training, including training
    on security risks and controls;

5.  Incorporate proactive tests of wireless security, including but not
    limited to, scanning for signal transmission distance, use of strong
    encryption technology, and use of annual penetration testing as a
    routine component of DOI's computer security process;

6.  Issue guidance requiring stronger physical security safeguards in
    areas where wireless is used;

7.  Ensure formal documentation of risks and acceptance of known
    residual risks by the DAA;

8.  Ensure tracking of all wireless implementations on a quarterly basis
    that:

    a.  Identifies all wireless technologies in use

    b.  Indicates utilization and scope of wireless technologies in
        bureaus and offices

    c.  Describes the location of deployed technologies

    d.  Enumerates actual statistics of user-base using deployed
        technologies

    e.  Identifies whether PII or sensitive information will be
        transmitted via wireless mechanisms, and if so, provides
        detailed information concerning the protection of that data in
        transit

9.  Ensure network access controls are implemented

In addition, bureaus or offices shall seek guidance from the Department
Chief Information Security Officer regarding any other specific
requirements for wireless security, if needed, and as appropriate.

## AC-19 -- Access Control for Portable and Mobile Devices

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Establish usage restrictions and implementation guidance for bureau
    or office-controlled portable and mobile devices; and

2.  Authorize, monitor, and control device access to Moderate and High
    impact information systems.

#### 

#### 

#### 

#### Policy Supplement(s):

AC-19(a)

Bureaus and offices shall ensure that government issued portable and
mobile devices (e.g., notebook computers, personal digital assistants,
cellular telephones, and other computing and communications devices with
network connectivity and the capability of periodically operating in
different physical locations) are only allowed access to DOI information
systems in accordance with bureau or office security policies and
procedures.

AC-19(b)

Bureaus and offices shall ensure that their security policies and
procedures include:

1.  Device identification and authentication,

2.  Implementation of mandatory protective software (e.g., malicious
    code detection, firewall),

3.  Configuration management,

4.  Scanning devices for malicious code,

5.  Updating virus protection software,

6.  Scanning for critical software updates and patches,

7.  Conducting primary operating system (and possibly other resident
    software) integrity checks, and

8.  Disabling unnecessary hardware (e.g., wireless, infrared).

9.  Restriction on usage of pin-to-pin blackberry messaging \[aspects
    regarding prohibited routine use/activity, except in specific
    significant agency, bureau- or office-level emergencies and
    disasters\].

## AC-20 -- Use of External Information Systems

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall establish terms and conditions for authorized
individuals to:

1.  Access specific information systems from an external information
    system;

2.  Process, store, and/or transmit bureau or office-controlled
    information using an external information system; and

3.  Explicitly prohibit the use of any personally-owned information
    system from accessing, processing, storing, and/or transmitting any
    Personally Identifiable Information (PII) or any other sensitive
    agency information.

#### 

#### 

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall prohibit        | X        | X      |
| authorized individuals from using external      |          |        |
| information systems to access DOI information   |          |        |
| or information systems or to process, store, or |          |        |
| transmit DOI information except in situations   |          |        |
| where bureaus and offices:                      |          |        |
|                                                 |          |        |
| \(i\) can verify the employment of required     |          |        |
| security controls on the external system as     |          |        |
| specified in DOI, bureau or office information  |          |        |
| security policies and System Security Plans; or |          |        |
| (ii) have approved information system           |          |        |
| connection or processing agreements with the    |          |        |
| entity hosting the external information system. |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514786 .anchor}Table 14: AC-20 -- Use of
External Information Systems Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AC-20(a)

External information systems constitute information systems or
components of information systems that are outside of the accreditation
boundary established by bureaus or offices and for which the bureau or
office typically has no control over the application of required
security controls or the assessment of security control effectiveness.
External information systems include, but are not limited to:

1.  personally-owned information systems (e.g., computers, cellular
    telephones, or personal digital assistants);

2.  privately owned computing and communications devices resident in
    commercial or public facilities (e.g., hotels, convention centers,
    or airports);

3.  information systems owned or controlled by nonfederal governmental
    organizations; and

4.  Federal information systems that are not owned, operated, or under
    the direct control of a bureau or office.

AC-20(b)

Authorized individuals constitute bureau and office personnel,
contractors, or any other individuals with authorized access to DOI
information systems.

AC-20(c)

This policy does not apply to the use of external information systems to
access DOI information systems and information that is intended for
public access (e.g., individuals accessing federal information through
public interfaces to organizational information systems).

AC-20(d)

Bureaus and offices shall establish terms and conditions for the use of
external information systems in accordance with security policies and
procedures.

The terms and conditions address shall address at a minimum:

1.  the types of applications that can be accessed on bureau and office
    information system from external information systems; and

2.  the maximum FIPS 199 security category of information that can be
    processed, stored, and transmitted on the external information
    system.

### AC-20 Use of DOI IT Resources

Bureau or office policies should be explicit about permissible personal
uses of government resources. Acceptable use policies shall be covered
under system-specific rules of behavior, or be addressed in an
overarching bureau or office security policy. Bureaus and offices shall
inform all personnel of the policy and personnel will acknowledge
receipt in writing of this information prior to system use. For Internet
use, bureau or office policies must be consistent with this handbook.

### AC-20 Use of Personally-Owned and Contractor-Owned Equipment

The Department prohibits the installation and use of personally-owned
equipment in DOI owned or leased buildings. The Department also
prohibits the use of any personally-owned information system from
accessing, processing, storing, and/or transmitting any Personally
Identifiable Information (PII) or any other sensitive agency
information. The Department requires all bureaus and offices to
establish a policy specifically addressing the IT security controls for
use of contractor-owned equipment.

### AC-20 Requirements for the Use of Contractor-Owned Equipment

Bureaus and offices shall establish a policy specifically addressing the
IT security controls for use of contractor-owned equipment. All
contractor-owned equipment and/or software use to connect to DOI systems
or used to develop applications for DOI must be certified and accredited
in accordance with DOI policy and standards. The System Owner must
approve, in writing, the use of contractor-owned equipment and/or
software, citing no adverse effects on DOI IT resource(s) or the
network.

The System Owner must also maintain records of all such authorizations,
and make authorizations available to the bureau or office Chief
Information Security Officer upon request for review.

#  

# Awareness and Training (AT)

IT security awareness consists of subtle reminders that focus the user's
attention on the concept of IT security in the user's daily routine.
Awareness provides a general cognizance or mindfulness of one's actions,
and the consequences of those actions.

Awareness activities provide the means to highlight when a significant
change in the IT Security Program policy or procedures occurs, when an
incident occurs, or when a weakness in a security control is found. IT
security training develops skills and knowledge so computer users can
perform their jobs more securely and build in-depth knowledge, producing
relevant and necessary security skills and competencies in those who
access or manage DOI information and resources. Bureaus and offices
shall comply with the NIST Special Publication 800-53, Rev.1,
*Recommended Security Controls for Federal Information Systems,*
awareness and training controls listed in the following table:

+------+---------------------------+----------+----------+-----------+
|  A   |                           |          |          |           |
| ware |                           |          |          |           |
| ness |                           |          |          |           |
| and  |                           |          |          |           |
| Trai |                           |          |          |           |
| ning |                           |          |          |           |
+------+---------------------------+----------+----------+-----------+
|      |                           | Control  |          |           |
|      |                           | B        |          |           |
| Con  | Control Name              | aselines |          |           |
| trol |                           |          |          |           |
| Nu   |                           |          |          |           |
| mber |                           |          |          |           |
+------+---------------------------+----------+----------+-----------+
|      |                           | Low      | Moderate | High      |
+------+---------------------------+----------+----------+-----------+
| AT-1 | Security Awareness and    | AT-1     | AT-1     | AT-1      |
|      | Training Policy and       |          |          |           |
|      | Procedures                |          |          |           |
+------+---------------------------+----------+----------+-----------+
| AT-2 | Security Awareness        | AT-2     | AT-2     | AT-2      |
+------+---------------------------+----------+----------+-----------+
| AT-3 | Security Training         | AT-3     | AT-3     | AT-3      |
+------+---------------------------+----------+----------+-----------+
| AT-4 | Security Training Records | AT-4     | AT-4     | AT-4      |
+------+---------------------------+----------+----------+-----------+
| AT-5 | Contacts with Security    | Not      | Not      | Not       |
|      | Groups and Associations   | Selected | Selected | Selected  |
+------+---------------------------+----------+----------+-----------+

[]{#__RefHeading___Toc193514787 .anchor}Table 15: Awareness and Training
Controls

## AT-1 -- Security Awareness and Training Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, security awareness and training policy that
    addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the security awareness and training policy and associated security
    awareness and training controls.

## AT-2 -- Security Awareness 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall provide basic security awareness training to
all information system users (including managers, senior executives,
contractors, and volunteers) before authorizing access to information
systems, when required by system changes, and annually thereafter.

## AT-3 -- Security Training 

All Information Systems

#### Policy Statement:

Bureaus and offices shall identify personnel that have significant
information system security roles and responsibilities during the system
development life cycle, document those roles and responsibilities, and
provide appropriate information system security training:

1.  before authorizing access to the system or performing assigned
    duties;

2.  when required by substantial system changes; and

3.  annually thereafter.

#### Policy Supplement(s):

AT-3(a)

In addition, the organization provides system managers, system and
network administrators, and other personnel having access to
system-level software, adequate technical training to perform their
assigned duties.

### AT-3 IT Security Awareness and Training Materials

The OCIO Cyber Security Office shall provide basic IT security training
and awareness for all DOI end-users. Bureaus and offices may supplement
Department provided training and awareness as needed based on bureau
specific environments and security concerns.

Departmental IT security awareness training will be presented annually
using the enterprise-wide learning management system, DOI Learn. Bureaus
and offices are encouraged to utilize the DOI Learn system to the
maximum extent possible.

### AT-3 IT Security Awareness and Training Process

Bureau and office IT Security Programs must include an IT Security
Awareness, Training, and Education component consistent with the
methodology of National Institute of Standards and Technology (NIST)
Special Publication 800-50, *Building an Information Technology Security
Awareness and Training Program*, that applies to all employees (federal
and contractor) as well as students, guest researchers, visitors and
others who will need access to a DOI information system that is not
publicly accessible (e.g., approved publicly accessible webserver).

Bureaus and offices shall participate in the DOI IT Security Awareness
and Training Program, which provides an online DOI Security Awareness
Course through the DOI eLearning system DOI Learn.

Bureaus and offices that are prohibited from internet access may take
the training course via CD-ROM or paper copy.

### AT-3 Training Requirement Exemptions

All users with access to DOI information systems system must be given IT
Security Awareness training prior to their initial access to information
systems, without exception. Exemption to the annual training requirement
may be approved by bureau and office supervisors and BCISOs based on an
employee's status. For example, employees that are on extended leave
(maternity, leave of absence etc.); serving military duty or any other
extended absence may be exempt from the annual training requirement for
the current reporting period.

Bureaus and offices shall ensure that the training records for any
employee designated as exempt are updated in the DOI Learn training
system to reflect their current status.

### AT-3 Training Non-Compliance

If a user is not exempt and refuses to engage in, or does not meet their
annual training requirements, bureaus and offices shall ensure that
access to information systems and resources is immediately suspended or
terminated, and the user's performance in an IT security role, if
significant, be re-evaluated. This may result in personnel action if
access is required for fulfillment of position responsibilities.

### AT-3 Specialized or Role-Based IT Security Training

Bureaus and offices shall provide specialized or role-based IT security
training to employees having significant IT security responsibilities.
DOI defines "significant IT security responsibility": as any employee or
contractor job role or function that includes:

1.  Elevated or advanced rights, beyond a general user, to any DOI IT
    system; or

2.  IT security program management, oversight, policy, compliance or
    implementation responsibilities.

Bureaus and offices shall ensure that specialized training programs are
implemented in accordance with the DOI Role-Based IT Security Training
Guide, and NIST Special Publication 800-16, *Information Technology
Security Training Requirements: A Role- and Performance-Based Model*.

### 

### AT-3 Roles Requiring Specialized Training

Bureaus and offices shall ensure that at a minimum the following roles
or functions listed below receive specialized or role-based IT security
training at least annually.

Bureaus and offices may require additional roles and functions not
listed based on assessed risk impact and or operational need. Any
additional bureau or office-specific training requirements should be
included in the bureau or office IT Security Program Plan or the
appropriate information System Security Plan.

An in depth analysis of the job functions within DOI bureaus and
recommendations from NIST led into the culmination high level training
group designations. Role-Based IT Security Training will revolve around
three training groups within DOI, which have been listed below.

#### Executive Personnel 

This group consists of DOI Senior Executive Level and Management
personnel whose job functions may include: IT management activities that
typically extend and apply to an entire organization or major components
of an organization. This includes strategic planning, capital planning
and investment control, workforce planning, policy and standards
development, resource management, knowledge management, architecture and
infrastructure planning and management, auditing, and information
security management.

##### IT Executives

Bureau and Office Head

Bureau and Office Division Head

Chief Information Officer (CIO)

##### IT Security Collaboration Roles

Privacy Act Officer

Records Management Official

Information Resource Manger

Contracting Officer

Contracting Officer Technical Representative (COTR)

##### IT Security Evaluator Roles

IT Security Auditor

Certification Agents or Certification Authority

#### Security Professionals

This group consists of DOI personnel whose job function may include:
Ensuring the confidentiality, integrity, and availability of systems,
networks, and data through the planning, analysis, development,
implementation, maintenance, and enhancement of information systems and
organizational security programs, policies, procedures, and tools.

##### 

##### IT Security Manager Roles

Chief Information Security Officer (CISO)

Bureau Chief Information Security Officer (BCISO)

Information Assurance Officer (IAO)

Information System Security Officers (ISSO)

Authorizing Official or Designated Approving/Accrediting Authority (DAA)

System Owner

Program Manager

Certification and Accreditation (C&A) Manager

##### IT Security Evaluator Roles

IT Security Auditor

Certification Agents or Certification Authority

##### IT Administrator Roles

Network Administrator

System/Application Administrator (e.g., internet or email system or
applications)

System Designer/Developer

Programmer Systems Analyst

Database Administrator

Systems Operations Personnel (e.g. Operations Centers administrators and
managers)

Technical Support Personnel (e.g. help desk administrators and mangers)

Telecommunications Specialist

#### Technical Personnel

This group consists of DOI personnel whose job functions may include one
or more of the following: Design, documentation, development,
modification, testing, installation, implementation, and support of new
or existing applications software. The job functions include planning,
installation, configuration, testing, implementation, and management of
the systems environment in support of the organization\'s IT
architecture and business needs.

Planning, analysis, design, development, testing, quality assurance,
configuration, installation, implementation, integration, maintenance,
and/or management of networked systems used for the transmission of
information in voice, data, and/or video formats. The job functions may
also include technical planning, design, development, testing,
implementation, and management of Internet, intranet, and extranet
activities, including systems/applications development and technical
management of Web sites. The job functions may also include planning and
coordinating the installation, testing, operation, troubleshooting, and
maintenance of hardware and software systems.

Planning and delivery of customer support services, including
installation, configuration, troubleshooting, customer assistance,
and/or training, in response to customer requirements.

-   IT Administrator Roles

-   Network Administrator

-   System/Application Administrator (e.g., internet or email system or
    applications)

-   System Designer/Developer

-   Programmer Systems Analyst

-   Database Administrator

-   Systems Operations Personnel (e.g. Operations Centers administrators
    and managers)

-   Technical Support Personnel (e.g. help desk administrators and
    mangers)

-   Telecommunications Specialist

### AT-3 Training Topics and Learning Levels

Bureaus and offices shall ensure that personnel filling the significant
IT security roles obtain role-based training as recommended in DOI
Role-Based IT Security Training Guide and NIST Special Publication
800-16, Information Technology Security Training Requirements: A Role-
and Performance-Based Model.

It is at the discretion of the bureau or office to determine the most
cost-effective sources for training and for meeting the training needs
of personnel filling supporting IT roles. To the extent practicable,
bureaus and offices shall utilize the Department's on-line centralized
solution, DOI Learn, for training personnel with significant information
system security roles and responsibilities.

### AT-3 Professional Security Certifications

Bureaus and offices shall ensure that employees assigned to the
following roles possess the designated professional certifications, in
addition to receiving annual specialized security training.

1.  Bureau Chief Information Security Officers (BCISOs) must achieve and
    maintain the "Certified Information Systems Security Professional
    (CISSP)" certification by ISC^2^.

2.  Bureau and office Certification and Accreditation (C&A) Managers
    must achieve and maintain the "Certification and Accreditation
    Professional (CAP)" certification by ISC^2^.

## AT-4 -- Security Training Records 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall document and monitor individual information
system security training activities including basic security awareness
training and specialized information system security training.

### AT-4 Tracking and Reporting Awareness and Specialized Training

Bureaus and offices shall track, maintain and report on training
compliance by maintaining employee training records that must include:

1.  Name and bureau or office of employee that receives annual and
    specialized training;

2.  Dates and timeframes employee received annual or specialized
    training;

3.  Topics or subject areas covered by specialized training; and

4.  Any training completion certifications obtained.

To the extent practicable, bureaus and offices shall utilize the
Department's on-line centralized solution, DOI Learn, to track and
report on employee compliance with training requirements. Bureaus and
offices refer to the DOI Role-Based IT Security Training Guide for
tracking and reporting formats and details.

## AT-5 -- Contacts with Security Groups and Associations

#### Applicability:

Optional for all Information Systems

Bureaus and offices should establish and maintain contacts with special
interest groups, specialized forums, professional associations, news
groups, and/or peer groups of security professionals in similar
organizations to stay up to date with the latest recommended security
practices, techniques, and technologies and to share the latest
security-related information including threats, vulnerabilities, and
incidents.[]{#Audit_Trails .anchor}

# Audit and Accountability (AU)

Audit trails maintain a record of system activity by the system or
application processes and by a user activity. In conjunction with
appropriate tools and procedures, audit trails can provide individual
accountability, a means to reconstruct events, detect intrusions, and
identify problems. System audit trails, or event logs, provide a record
of events in support of activities to monitor and enforce the IT system
security policy. National Institute of Standards and Technology (NIST)
Special Publication 800-12, An Introduction to Computer Security: The
NIST Handbook, Chapter 18, describes an event as any action that happens
on a computer system, such as logging into a system, executing a
program, and opening a file. Bureaus and offices shall comply with the
NIST Special Publication 800-53, Rev.1, Recommended Security Controls
for Federal Information Systems, audit and accountability controls
listed in the following table:

+-------+-------------------------+-----------+-----------+-----------+
|       |                         |           |           |           |
| Audit |                         |           |           |           |
| and   |                         |           |           |           |
| Acco  |                         |           |           |           |
| untab |                         |           |           |           |
| ility |                         |           |           |           |
+-------+-------------------------+-----------+-----------+-----------+
|       |                         | Control   |           |           |
|       |                         | Baselines |           |           |
| Co    | Control Name            |           |           |           |
| ntrol |                         |           |           |           |
| N     |                         |           |           |           |
| umber |                         |           |           |           |
+-------+-------------------------+-----------+-----------+-----------+
|       |                         | Low       | Moderate  | High      |
+-------+-------------------------+-----------+-----------+-----------+
| AU-1  | Audit and               | AU-1      | AU-1      | AU-1      |
|       | Accountability Policy   |           |           |           |
|       | and Procedures          |           |           |           |
+-------+-------------------------+-----------+-----------+-----------+
| AU-2  | Auditable Events        | AU-2      | AU-2 (1)  | AU-2 (1)  |
|       |                         |           | (2) (3)   | (2) (3)   |
+-------+-------------------------+-----------+-----------+-----------+
| AU-3  | Content of Audit        | AU-3      | AU-3 (1)  | AU-3 (1)  |
|       | Records                 |           | (2)       | (2)       |
+-------+-------------------------+-----------+-----------+-----------+
| AU-4  | Audit Storage Capacity  | AU-4      | AU-4      | AU-4      |
+-------+-------------------------+-----------+-----------+-----------+
| AU-5  | Response to Audit       | AU-5      | AU-5 (1)  | AU-5 (1)  |
|       | Processing Failures     |           | (2)       | (2)       |
+-------+-------------------------+-----------+-----------+-----------+
| AU-6  | Audit Monitoring,       | Not       | AU-6 (1)  | AU-6 (1)  |
|       | Analysis, and Reporting | Selected  | (2)       | (2)       |
+-------+-------------------------+-----------+-----------+-----------+
| AU-7  | Audit Reduction and     | Not       | AU-7 (1)  | AU-7 (1)  |
|       | Report Generation       | Selected  |           |           |
+-------+-------------------------+-----------+-----------+-----------+
| AU-8  | Time Stamps             | AU-8      | AU-8 (1)  | AU-8 (1)  |
+-------+-------------------------+-----------+-----------+-----------+
| AU-9  | Protection of Audit     | AU-9      | AU-9      | AU-9      |
|       | Information             |           |           |           |
+-------+-------------------------+-----------+-----------+-----------+
| AU-10 | Non-repudiation         | Not       | Not       | Not       |
|       |                         | Selected  | Selected  | Selected  |
+-------+-------------------------+-----------+-----------+-----------+
| AU-11 | Audit Record Retention  | AU-11     | AU-11     | AU-11     |
+-------+-------------------------+-----------+-----------+-----------+

[]{#__RefHeading___Toc193514788 .anchor}Table 16: Audit and
Accountability Controls

## AU-1 -- Audit and Accountability Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, audit and accountability policy that addresses
    purpose, scope, roles, responsibilities, management commitment,
    coordination among organizational entities, and compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the audit and accountability policy and associated audit and
    accountability controls.

### AU-1 Audit Trail Requirements

Bureaus and offices shall ensure that System Owners define in IT System
Security Plans the requirements to log, monitor, and investigate
possible security violations from activity involving access to and
modification of files. Audit trails maintain a record of authorized and
unauthorized system events both by system and application processes and
by user activity of systems and applications. In conjunction with other
processes and controls, such as incident response capabilities and user
identification and authentication, audit trails can assist in detecting
security violations, network performance problems, and flaws in
applications. Audit trails can provide a means to help accomplish
several security-related objectives, including individual
accountability, reconstruction of events, intrusion detection, and
problem analysis.

A system can maintain several different audit trails concurrently. There
are typically two kinds of audit records, (1) an event-oriented log and
(2) a record of every keystroke, often called keystroke monitoring.
Event-based logs usually contain records describing system events,
application events, or user events. An audit trail should include
sufficient information to establish what events occurred and who (or
what) caused them. In general, an event record should specify when the
event occurred, the user ID associated with the event, the program or
command used to initiate the event, and the result. Date and time can
help determine if the user was a masquerader or the actual person
specified.

## AU-2 -- Auditable Events 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that at a minimum, all information
systems generate audit records for the following events:

***System-Level Audit Events*** - If a system-level audit capability
exists, the audit trail should capture, at a minimum, any attempt to log
on (successful or unsuccessful), the log-on ID, date and time of each
log-on attempt, date and time of each log-off, the devices used, and the
function(s) performed once logged on (e.g., the applications that the
user tried, successfully or unsuccessfully, to invoke). System-level
logging also typically includes information that is not specifically
security-related, such as system operations, cost-accounting charges,
and network performance.

***Application-Level Audit Events*** - System-level audit trails may not
be able to track and log events within applications, or may not be able
to provide the level of detail needed by application or data owners, the
system administrator, or the computer security manager. In general,
application-level audit trails monitor and log user activities,
including data files opened and closed, specific actions, such as
reading, editing, and deleting records or fields, and printing reports.
Some applications may be sensitive enough from a data availability,
confidentiality, and/or integrity perspective that a \"before\" and
\"after\" picture of each modified record (or the data element(s)
changed within a record) should be captured by the audit trail.

***User Audit Events*** - User audit trails can usually log:

1.  all commands directly initiated by the user;

2.  all identification and authentication attempts; and files and
    resources accessed.

It is most useful if options and parameters are also recorded from
commands. It is much more useful to know that a user tried to delete a
log file (e.g., to hide unauthorized actions) than to know the user
merely issued the delete command, possibly for a personal data file.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure that        X              X
  information systems provide the capability to                     
  compile audit records from multiple components                    
  throughout the system into a system-wide (logical                 
  or physical), time-correlated audit trail.                        

  \(2\) Bureaus and offices shall ensure that        X              X
  information systems provide the capability to                     
  manage the selection of events to be audited by                   
  individual components of the system.                              

  \(3\) Bureaus and offices shall periodically       X              X
  review and update any lists of bureau or office                   
  specific auditable events.                                        
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514789 .anchor}Table 17: AU-2 -- Auditable
Events Mandatory Policy Enhancement(s)

## AU-3 -- Content of Audit Records 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that information systems produce audit
records that contain sufficient information to establish what events
occurred, the sources of the events, and the outcomes of the events.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure that        X              X
  information systems provide the capability to                     
  include additional, more detailed information in                  
  the audit records for audit events identified by                  
  type, location, and subject.                                      

  \(2\) Bureaus and offices shall ensure that        X              X
  information systems provide the capability to                     
  centrally manage the content of audit records                     
  generated by individual components throughout the                 
  system.                                                           
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514790 .anchor}Table 18: AU-3 -- Content of
Audit Records Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AU-3(a)

At a minimum, audit record content shall include:

1.  date and time of the event;

2.  the component of the information system (e.g., software component,
    hardware component) where the event occurred;

3.  type of event;

4.  user/subject identity; and

5.  outcome (success or failure) of the event.

### AU-3 PII Audit Extracts

OMB Memorandum M-06-16 requires that bureaus and offices log all
computer-readable data extracts from databases holding sensitive
information and verify each extract including sensitive data has been
erased within 90 days or its use is still required.

## AU-4 -- Audit Storage Capacity

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall allocate sufficient audit record storage
capacity and configures auditing to reduce the likelihood of such
capacity being exceeded.

#### Policy Supplement(s):

AU-4(a)

Bureaus and offices shall provide sufficient audit storage capacity,
taking into account the auditing to be performed and the online audit
processing requirements.

## 

## 

## AU-5 -- Response to Audit Processing Failures

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that information systems are configured
to alert appropriate personnel in the event of an audit processing
failure (e.g., software/hardware error, failure in the audit capturing
mechanism, or audit storage capacity being reached or exceeded), and
shuts down the information system or overwrites the oldest audit
records.

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall ensure that     | X        | X      |
| information systems provide a warning when      |          |        |
| allocated audit record storage volume reaches   |          |        |
| **no more than 75 percent** of maximum audit    |          |        |
| record storage capacity.                        |          |        |
+-------------------------------------------------+----------+--------+
| \(2\) Bureaus and offices shall ensure that     | X        | X      |
| information systems provide a real-time alert   |          |        |
| when the following audit failure events occur:  |          |        |
|                                                 |          |        |
| 1.  Any critical device failure                 |          |        |
|                                                 |          |        |
| 2.  Any administrator account failure           |          |        |
|                                                 |          |        |
| 3.  All relevant user activity that could lead  |          |        |
|     to an incident or attempted security breach |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514791 .anchor}Table 19: AU-5 -- Response to
Audit Processing Failures Mandatory Policy Enhancement(s)

## AU-6 -- Audit Monitoring, Analysis and Reporting 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that audit records for Moderate and
High-impact information systems are regularly reviewed and analyzed for
indications of inappropriate or unusual activity; any suspicious
activity or suspected violations are investigated and findings are
reports to the appropriate officials to take necessary actions.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to integrate audit monitoring,                         
  analysis, and reporting into an overall process                   
  for investigation and response to suspicious                      
  activities.                                                       

  \(2\) Bureaus and offices shall employ automated   X              X
  mechanisms to alert security personnel of                         
  inappropriate or unusual activities with security                 
  implications.                                                     
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514792 .anchor}Table 20: AU-6 -- Audit
Monitoring, Analysis and Reporting Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AU-6(a)

Bureaus and offices shall increase the level of audit monitoring and
analysis activity within information systems whenever there is an
indication of increased risk to operations, assets, or individuals based
on law enforcement information, intelligence information, or other
credible sources of information.

## AU-7 -- Audit Reduction and Report Generation 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure Moderate and High-impact information
systems provide an audit reduction and report generation capability.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure that        X              X
  information systems provide the capability to                     
  automatically process audit records for events of                 
  interest based upon selectable, event criteria.                   
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514793 .anchor}Table 21: AU-7 -- Audit
Reduction and Report Generation Mandatory Policy Enhancement(s)

#### Additional Policy Guidance:

Audit reduction, review, and reporting tools support after-the-fact
investigations of security incidents without altering original audit
records.

## AU-8 -- Time Stamps 

#### Applicability:

All Information Systems

#### 

#### 

#### Policy Statement:

Bureaus and offices shall ensure that all information systems provide
time stamps for use in audit record generation.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall synchronize        X              X
  internal information system clocks at least every                 
  90 days.                                                          
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514794 .anchor}Table 22: AU-8 -- Time Stamps
Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

AU-8(a)

Bureaus and offices shall ensure that time stamps (including date and
time) of audit records are generated using internal system clocks.

## AU-9 -- Protection of Audit Information 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems protect
audit information and audit tools from unauthorized access,
modification, and deletion.

#### Policy Supplement(s):

AU-9(a)

Audit information constitutes all information (e.g., audit records,
audit settings, and audit reports) needed to successfully audit
information system activity.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  configuring information systems to produce audit                  
  records on hardware-enforced, write-once media.                   
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514795 .anchor}Table 23: AU-9 -- Protection of
Audit Information Recommended Policy Enhancement(s)

## AU-10 -- Non-Repudiation

#### Applicability:

Optional for all Information Systems

Bureaus and offices shall ensure that information systems provide when
applicable the capability to determine whether a given individual took a
particular action (e.g., created information, sent a message, approved
information \[e.g., to indicate concurrence or sign a contract\] or
received a message).

#### Additional Policy Guidance:

Non-repudiation protects against later false claims by an individual of
not having taken a specific action. Non-repudiation also protects
individuals against later claims by an author of not having authored a
particular document, a sender of not having transmitted a message, a
receiver of not having received a message, or a signatory of not having
signed a document.

Non-repudiation services can be used to determine if information
originated from an individual, or if an individual took specific actions
(e.g., sending an email, signing a contract, approving a procurement
request) or received specific information.

Non-repudiation services are obtained by employing various techniques or
mechanisms (e.g., digital signatures, digital message receipts, time
stamps).

## AU-11 -- Audit Retention 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall retain audit records for a minimum of 30 days
online for Low systems, 60 days for Moderate systems, and 90 days for
high systems. All audit records shall be maintained off-line for all
systems as consistent with Departmental and bureau or office Records
Management retention periods, to provide support for after-the-fact
investigations of security incidents and to meet regulatory and
organizational information retention requirements.

#  

# Certification, Accreditation, and Security Assessment (CA)

Bureaus and offices shall comply with the NIST Special Publication
800-53, Rev.1, *Recommended Security Controls for Federal Information
Systems,* certification, accreditation, and security assessment controls
listed in the following table and the DOI Certification and
Accreditation Guide and Templates:

+----------+----------------------------+-----------+--------+--------+
|  Certif  |                            |           |        |        |
| ication, |                            |           |        |        |
| Accred   |                            |           |        |        |
| itation, |                            |           |        |        |
| and      |                            |           |        |        |
| Security |                            |           |        |        |
| As       |                            |           |        |        |
| sessment |                            |           |        |        |
+----------+----------------------------+-----------+--------+--------+
|          |                            | Control   |        |        |
|          |                            | Baselines |        |        |
| Control  | Control Name               |           |        |        |
| Number   |                            |           |        |        |
+----------+----------------------------+-----------+--------+--------+
|          |                            | Low       | Mo     | High   |
|          |                            |           | derate |        |
+----------+----------------------------+-----------+--------+--------+
| CA-1     | Certification,             | CA-1      | CA-1   | CA-1   |
|          | Accreditation, and         |           |        |        |
|          | Security Assessment        |           |        |        |
|          | Policies and Procedures    |           |        |        |
+----------+----------------------------+-----------+--------+--------+
| CA-2     | Security Assessments       | CA-2      | CA-2   | CA-2   |
+----------+----------------------------+-----------+--------+--------+
| CA-3     | Information System         | CA-3      | CA-3   | CA-3   |
|          | Connections                |           |        |        |
+----------+----------------------------+-----------+--------+--------+
| CA-4     | Security Certification     | CA-4      | CA-4   | CA-4   |
|          |                            |           | (1)    | (1)    |
+----------+----------------------------+-----------+--------+--------+
| CA-5     | Plan of Action and         | CA-5      | CA-5   | CA-5   |
|          | Milestones                 |           |        |        |
+----------+----------------------------+-----------+--------+--------+
| CA-6     | Security Accreditation     | CA-6      | CA-6   | CA-6   |
+----------+----------------------------+-----------+--------+--------+
| CA-7     | Continuous Monitoring      | CA-7      | CA-7   | CA-7   |
+----------+----------------------------+-----------+--------+--------+

[]{#__RefHeading___Toc193514796 .anchor}Table 24: Certification,
Accreditation, and Security Assessment Controls

## CA-1 -- Certification, Accreditation and Security Assessment Policies and Procedures

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, security assessment and certification and
    accreditation policies that address purpose, scope, roles,
    responsibilities, management commitment, coordination among
    organizational entities, and compliance with DOI policy and federal
    mandates; and

2.  Formal, documented procedures to facilitate the implementation of
    the security assessment and certification and accreditation policies
    and associated assessment, certification, and accreditation
    controls.

### 

### 

### 

### CA-1 C&A Implementation Methodology

#### Certification, Accreditation, and Security Assessment

#### Scope: 

The scope of this section applies to the C&A process, procedures and
documentation for all DOI IT systems. All Federal IT systems, whether or
not they are owned or operated by the Federal agency, must be certified
and accredited in accordance with NIST SP 800-37 and supporting
guidance. All contractor-owned or operated systems that process, store,
house, or are interconnected with Federal IT systems must also be
certified and accredited consistent with these standards.

#### Policy:

#### This policy supersedes:

-   OCIO Bulletin 2003-003, "Interim Guidance for Certification and
    Accreditation of Information Technology Systems,"

-   OCIO Bulletin 2003-016, "Interconnecting Department of the Interior
    Information Technology Systems," and

-   OCIO Directive 2004-007, "Standardized System Security
    Configuration," (beginning in FY09) and

-   OCIO Directive 2006-008, "Interim Guidance for the Certification and
    Accreditation of Information Technology Systems;"

#### Implementation Schedule

This policy is effective immediately for all new Major Applications
(MAs) or General Support Systems (GSSs) being certified and accredited
and all existing MAs or GSSs requiring re-accreditation.

Any MAs or GSSs currently operating under an existing accreditation
shall update all C&A documentation in accordance with this policy when
the MA or GSS undergoes the next required C&A re-accreditation, or
whenever individual C&A documents are revised or updated to reflect
significant changes.

#### C&A Program Management 

Each bureau and office shall designate in writing a ***C&A Manager***
responsible for ensuring adequate planning and compliance with respect
to the relevant policies, standards and guidelines issued by the Office
of Management and Budget (OMB), NIST, and Interior.

The C&A Managers shall be required to achieve and maintain the
"Certification and Accreditation Professional (CAP)" certification by
the International Information Systems Security Certification Consortium
(ISC)^2^. Bureaus and offices are also highly encouraged to have C&A
Managers achieve certification as a "Certified Information Systems
Security Professional (CISSP)" by the (ISC)^2^ as well as "Project
Management Professional (PMP) by the Project Management Institute (PMI).

Until adoption of standardized DOI templates, bureaus and offices are to
follow templates provided in the NIST guidance. Management, operational,
and technical controls shall be assessed to ensure they are implemented
correctly, operating as intended, and producing the desired outcome with
respect to meeting the security requirements for the system. Assessment
plans and results shall be included in the accreditation package.

All IT security and C&A roles and responsibilities are specified in the
Departmental manual (DM 375 Chapter 19). The C&A roles and
responsibilities are further elaborated in each of the applicable NIST
standards and guidelines referenced below.

A completed Privacy Impact Assessment (PIA) is required with the C&A
package.

To further the compliance with NIST terminology, Interior will
discontinue use of the term "enclave".

#### Security Technical Implementation Guides (STIGs) 

STIGs (sometimes referred to as security configuration standards,
security configuration checklists, benchmarks, lockdown guides, or
hardening guides) are in their simplest form a series of instructions
for configuring a product to a particular operational environment. STIGs
could also include templates or automated scripts and other procedures.
Typically, STIGs are created by IT vendors for their own products;
however STIGs are also created by other organizations such as consortia,
academia, and government agencies. The use of well-written, standardized
STIGs can markedly reduce the vulnerability exposure of IT products.
NIST, with the sponsorship from the Department of Homeland Security
(DHS), has produced NIST SP 800-70, *Security Configuration Checklists
Program for IT Products: Guidance for Checklist Users and Developers*,
to facilitate the development and dissemination of security
configuration checklists so that organizations can better secure their
IT products. The NIST SP 800-70 provides checklist users an overview of
the NIST National Checklist Program (NCP - formerly the NIST Security
Configuration Checklist Program), explains how to retrieve checklists
from the NCP repository, and provides general information about threat
discussions and baseline technical security practices for associated
operational environments.

Any specific direction issued to agencies by the Office of Management
and Budget (OMB) regarding the implementation of security configuration
standards takes precedence over any previously issued STIGs by NIST or
the Department. OMB issued memorandum M-07-11, *Implementation of
Commonly Accepted Security Configurations for Windows Operating
Systems*, and M-07-18, *Ensuring New Acquisitions Include Common
Security Configurations*, requiring agencies to adopt and implement the
Federal Desktop Core Configuration (FDCC[^2]) for Windows XP and Vista.
The Department issued OCIO Directive 2008-001, *Security Technical
Implementation Guide (STIG) for Windows XP*, for Interior's bureaus and
offices to implement the initial DOI XP Baseline STIG by February 1,
2008 that conforms to a subset of the FDCC security configuration
requirements. Bureaus and offices are expected to fully adopt, test,
implement and deploy the security configurations specified by the FDCC
standard by September 30, 2008. Bureaus and offices are encouraged to
implement security configurations that exceed those minimum
requirements, but must at a minimum demonstrate compliance against the
FDCC standard.

Through fiscal year 2008, Interior's bureaus and offices must also
continue to adhere to OCIO Directive 2004-007, *Standardized System
Security Configuration*, and demonstrate compliance with other
previously established STIGs.

Beginning in fiscal year 2009, Interior's bureaus and offices must
adhere to the requirements specified below and demonstrate compliance
with STIGs provided by NIST through the NCP.

The NCP maintains a website repository[^3] under the National
Vulnerability Database (NVD) section[^4] of the NIST Computer Security
Resource Center (CSRC) website[^5]. The Department, in consultation,
cooperation, and collaboration with Interior's bureaus and offices may
develop additional DOI-specific STIGs, or addendums to the NIST STIGs,
when necessary and as appropriate. Any DOI-specific STIGs or addendums
to the NIST STIGs will be posted on the Departments Office of the Chief
Information Officer (OCIO) Cyber Security Division (CSD) IT Security
Program Portal.

The following requirement must be adhered to in implementing this
policy:

1.  Where any requirement specified in this policy handbook is more
    stringent than the security configurations specified in a STIG and
    relates to a STIG security configuration element or parameter the
    more restrictive requirements of this policy handbook shall take
    precedence and STIGs should be revised or amended to conform to such
    requirements.

2.  Bureaus and offices may develop, maintain, and implement their own
    STIGs provided the following conditions are met to adequately
    demonstrate compliance with minimum acceptable security
    configuration standards:

    a.  Bureau/Office STIGs address at a minimum all STIG elements
        identified in applicable NIST STIGs, DOI-specific STIGs, and
        DOI-specific addendums to NIST STIGs.

    b.  Bureau/Office STIGs shall include a documented GAP analysis of
        all STIG elements against all applicable NIST STIGs,
        DOI-specific STIGs, and DOI-specific addendums to NIST STIGs
        that sufficiently demonstrate that Bureau/Office STIGs are at
        least as comprehensive as, and as stringent or more stringent
        than, those other STIGs.

3.  Bureaus and offices that have not opted to establish their own STIGs
    and/or have not satisfied the preceding requirement must adopt and
    implement all applicable NIST STIGs, DOI-specific STIGs, and
    DOI-specific addendums to NIST STIGs.

4.  To the maximum extent possible, automated tools should be used to
    ensure consistent implementation of STIGs and verified by the
    responsible system administrator. Where automated tools are not
    available, security configuration checklists should be used.
    Documented artifacts from automated tools or completed checklists
    should be maintained with the appropriate C&A package documentation
    as evidentiary artifacts that STIGs have been appropriately
    implemented.

5.  To the maximum extent possible, automated tools should be used as
    part of each Bureau and Office Continuous Monitoring program to
    ensure ongoing monitoring and maintenance of the security
    configurations. Automated compliance and configuration monitoring
    tools should, to the extent available, be compliant with the NIST
    Security Content Automation Protocol (SCAP) requirements and
    validated by the NIST Information Security Automation Program
    (ISAP[^6]) SCAP Validation program[^7].

6.  STIGs must be used as part of the overall security baseline when
    conducting Security Test and Evaluations (ST&E) for the
    Certification and Accreditation (C&A) of a system.

Any limitations in implementing required security controls or security
configuration standards due to an adverse impact to application or
system functionality (e.g., a legacy application as currently designed
might be unable to function correctly if one or more specific required
controls or security configurations were to be implemented) shall be
appropriately documented in the SSP and Risk Assessment report.

#### Implementation of NIST SP 800-37, Guide for the Security C&A of Federal Information Systems

The C&A of all DOI, outsourced, and contractor IT systems as described
above shall be performed in accordance with NIST 800-37, Guide for the
Security C&A of Federal Information Systems. This implies that the most
current versions, including those that may only be available in draft,
of all related NIST Special Publications (SPs) and Federal Information
Processing Standard Publications (FIPS Pubs) shall be followed to
include, but not limited to, the following:

-   NIST SP 800-37, Guide for the Security Certification and
    Accreditation of Federal Information Systems;

-   NIST SP 800-18, Guide for Developing Security Plans for Federal
    Information Systems;

-   NIST SP 800-30, Risk Management Guide for Information Technology
    Systems;

-   NIST SP 800-34, Contingency Planning Guide for Information
    Technology Systems;

-   NIST SP 800-47, Security Guide for Interconnecting Information
    Technology Systems;

-   NIST SP 800-53, Recommended Security Controls for Federal
    Information Systems;

-   NIST SP 800-53A, Guide for Assessing the Security Controls in
    Federal Information Systems;

-   NIST SP 800-60, Guide for Mapping Types of Information and
    Information Systems to Security Categories;

-   NIST FIPS Pub 199, Standards for Security Categorization of Federal
    Information and Information Systems; and

-   NIST FIPS Pub 200, Minimum Security Requirements for Federal
    Information and Information Systems.

Bureau and office C&A processes shall be consistent with the methodology
in National Institute of Standards and Technology (NIST) Special
Publication 800-37, *Guide for the Security Certification and
Accreditation of Federal Information Systems*.

The DOI [Certification and Accreditation Guide]{.underline} details the
mandatory process and minimum implementation requirements for the
conduct of C&A by all bureaus and offices to ensure consistency with the
NIST guidance. In addition, this Departmental C&A standard describes the
requirements for the consistent and comprehensive completion of required
certification testing and assembly of the security accreditation
package.

C&A documentation must contain an appropriate section on changes
(including changed pages, date of change, what was changed, name of
individual that made the change, and document version number).

All system security plans shall be developed in accordance with NIST SP
800-18, *Guide for Developing Security Plans for Federal Information
Systems*. Each SSP shall include a description and diagram of the IT
system accreditation boundary that identifies servers, network
resources, and network devices included within the boundary of the
accreditation. If there are multiple subsystems within the accreditation
boundary of the system, then each subsystem must be uniquely identified
and documented within the SSP.

Major applications must be separate and distinct systems from general
support systems. The MA or GSS must undergo appropriate assessment of
management, operational and technical security controls. Interconnection
Security Agreements (ISAs), Memorandums of Understanding (MOUs), and /
or Memorandums of Agreement (MOAs) must be developed and maintained
between interconnected systems in accordance with NIST SP 800-47,
*Security Guide for Interconnecting Information Technology Systems*.
These documents must be appended to the system security plan. SSPs must
adequately document the accreditation boundary for the information
system to include, but not limited to:

1.  system diagrams;

2.  description of the system environment; and

3.  comprehensive list of information systems, and, for each device that
    comprise the accreditation boundary the following information must
    be provided:

    a.  a description and nomenclature;

    b.  IP address(es) and hostnames;

    c.  operating systems and versions;

    d.  applications and versions; and

    e.  asset tag information.

System Security Plans (SSPs) must document who the designated
individuals are for the information system owner, DAA, and information
system security officer (including any other key individuals that may be
relevant).

Information types and sensitivity determinations (potential impact
ratings and security categorization) shall be made in accordance with
NIST FIPS Pub 199, *Standards for Security Categorization of Federal
Information and Information Systems*, and NIST SP 800-60, *Guide for
Mapping Types of Information and Information Systems to Security
Categories*. To the extent possible, information types shall be derived
from the NIST SP 800-60 and must be documented within the SSP for each
information system. Any unique agency, bureau, or office information
types that do not correspond to any of the available information types
provided in the NIST SP 80-60 shall also be documented within the SSP
with appropriate sensitivity determinations made consistent with NIST
FIPS Pub 199. All information types shall be identified and documented
within the System Security Plan (SSP) for each system using NIST SP
800-60 for guidance as well as any other unique agency specific
information types, which must be consistent with the Interior Enterprise
Architecture. The FIPS Pub 199 criteria shall be applied to the initial
provisional impact ratings derived from NIST SP 800-60 to determine if
those sensitivity ratings need to be adjusted. The Designated
Approving/Accrediting Authority (DAA), sometimes referred to as the
Authorizing Official (AO) may change the sensitivity rating based on
unique agency or bureau factors. The DAA\'s approved determination must
be documented in the SSP. The FIPS Pub 199 process must be documented in
the accreditation package.

The SSP shall identify if security categorizations were based on the
provisional risk impact ratings derived from NIST SP 800-60, or if they
were further modified based on FIPS Pub 199.

The SSP shall provide documented rationale/justification for any
security categorizations that were different from recommended
provisional risk impact ratings provided in NIST SP 800-60 and that were
modified in accordance with NIST FIPS Pub 199.

The SSP shall document the fact that security categorizations for each
type of information stored in or processed by the system were determined
using the criteria specified in NIST SP 800-60 and in accordance with
NIST FIPS Pub 199.

The SSP shall be the authoritative document where information types and
security categorizations are documented.

Risk assessment and contingency plans shall be developed in accordance
with NIST SP 800-30, *Risk Management Guide for Information Technology
Systems*, and NIST SP 800-34, *Contingency Planning Guide for
Information Technology Systems*, respectively, and attached to the
system security plan as appendices. This requires coordination between
the IT and business community to complete the business impact
assessment. Review and revise the Risk Assessment report, the
Departmental Enterprise Architecture Repository (DEAR), system Plans of
Action and Milestones, and Internal Control Review (ICR)
self-assessments for each information system to ensure consistent:

-   naming of accreditation boundaries;

-   security categorizations for information types; and

-   overall security categorization for each information system.

Evidentiary artifacts demonstrating Contingency Plan testing must be
appended to Contingency Plans each year as those tests are performed,
including identifying those individuals that participated, their
respective roles relevant to the information system, identification of
relevant contingency scenarios that were tested, whether or not the
testing consisted of a table-top exercise or actual technical testing of
the restoration capability for an information system, lessons learned,
and completion of remedial actions necessary to address a deficiency
identified as a result of the testing based on documented lessons
learned.

Security controls shall be identified, selected, implemented, and
integrated into each system by mapping the security categorization of
each system to the applicable minimum mandatory baseline set of controls
specified in NIST SP 800-53, *Recommended Security Controls for Federal
Information Systems*, and in accordance with NIST FIPS Pub 200, *Minimum
Security Requirements for Federal Information and Information Systems*.
The modification or adjustment of control baselines is permitted when
certain conditions exist that require flexibility as long as they are
consistent with DOI policy and tailored in a manner that is consistent
with the NIST SP 800-53 guidance. These additional controls and
modifications shall be addressed in the system security plan.
Implementation of SP 800-53 and FIPS Pub 200 does not eliminate the
requirement for applicable Security Technical Implementation Guides
(STIGs) to be implemented on information systems.

In addition to the security controls identified by NIST SP 800-53 and
FIPS Pub 200, and in accordance with the *Security Technical
Implementation Guides (STIGs)* section above, SSPs must document all
applicable and relevant Bureau/Office STIGs, or, DOI-specific STIGs and
the STIGs provided by NIST (including any applicable DOI-specific
addendums available for those STIGs), applicable for each system either
by reference or by including them in their entirety in the SSP. The SSP
for each information system shall document which STIGs are relevant to
the information systems and the degree to which the STIGs have been
implemented. The SSP for each information system shall identify and
document, for each applicable STIG, which specific STIG was implemented
and identify each STIG by title, version and date of the STIG and either
include a copy of each STIG as an attachment to the SSP or provide a
reference identifying the source/location where a copy may be obtained.

The SSP for each information system shall document the implementation
status of each STIG and specify whether or not each element:

1.  has been fully implemented and the date the security configuration
    item was implemented, operating as intended, and verified to be
    effective;

2.  is expected to be implemented in the future with a scheduled
    commitment date corresponding to the date entered on the system
    POA&M; and

3.  has been determined to not be able to be implemented due to inherent
    adverse operational impact to the information system or associated
    application, and whereby the Designated Approving/Accrediting
    Authority (DAA) is accepting the risk indefinitely.

Bureaus and offices shall document within the relevant system Plan of
Action and Milestones (POA&M) security configuration items associated
with a required STIG that remain to be implemented for an information
system where the DAA has not indefinitely accepted the associated
residual risk and for which there is a planned corrective action.

The Department will review STIG verification and validation processes
within Interior's bureaus and offices for reliability, repeatability,
integrity, and consistency each fiscal year. Bureaus and offices must
maintain supporting artifacts derived from technical solutions that
verify and validate STIG implementation as part of an effective
continuous monitoring program.

Security Test and Evaluation are required for each information system.
ST&E Plans must be developed that identify the information system and
related devices included in the accreditation boundary to be tested and
relevant test cases for each. ST&E Reports must be developed that fully
document the results of each test case for all devices included within
the scope of the ST&E Plan.

Bureaus and offices shall ensure that Risk Assessment reports fully
document all known residual risks. The Risk Assessment report for each
information system shall document the risk associated with each security
configuration item that has not been implemented, or partially
implemented, that the DAA is indefinitely accepting the risk for,
including:

1.  a description of the risks to the information or information system
    associated with not implementing the security configuration item;

2.  a description of any mitigating/compensating controls (and specify
    whether or not the mitigation either eliminates or partially
    mitigates the risk);

3.  the resulting residual risk level after mitigating actions have been
    implemented (e.g., in terms of High, Moderate, or Low); and

4.  the documented rationale/justification as to both why the security
    configuration item can not be fully implemented and how any
    mitigating actions effectively serve as compensating controls
    contributing to the determination of the resulting residual risk
    level.

The SSPs and Risk Assessment Reports must document any non-compliance
with policy or required security controls. This documentation must
include the justification for non-compliance, and the associated risk
level resulting from the system's inability to implement the required
security control baselines or security configuration standards.

The action items identified below reflect the appropriate sequencing of
foundational C&A documentation elements that contribute to the effective
and adequate completion of other C&A elements that are dependant on
foundational tasks being completed correctly first.

-   Review and revise the System Security Plan (SSP) for each
    information system to ensure accreditation boundaries are fully
    documented.

-   Review and revise the System Security Plan (SSP) for each
    information system to ensure information types are fully documented.

-   Review and revise the System Security Plan (SSP) for each
    information system to ensure the security categorization for each
    information type is fully documented.

-   Review and revise the System Security Plan (SSP) for each
    information system to ensure the overall security categorization
    determination is fully documented based on each of the security
    categorizations of the information types documented for the
    information system.

-   Review and revise the System Security Plan (SSP) for each
    information system to ensure required security controls, and their
    implementation status, corresponding to the overall security
    categorization of the information system are fully documented.

In brief, bureaus and offices shall follow a four-phase C&A process as
outlined below, and as detailed in NIST Special Publication 800-37.

#### Initiation Phase

The Initiation Phase consists of three tasks:

1.  preparation;

2.  notification and resource identification; and

3.  system security plan analysis, update, and acceptance.

The purpose of this phase is to ensure that the authorizing official and
senior agency information security officer are in agreement with the
contents of the system security plan, including the system's documented
security requirements, before the certification agent begins the
assessment of the security controls in the information system. The early
involvement of the authorizing official and senior agency information
security officer, with key participants such as the information system
owner, information owner, information system security officer,
certification agent, and user representatives, is paramount to the
success of the security certification and accreditation effort.

A significant portion of the information needed for the Initiation Phase
should have been previously generated by the information system owner
during:

1.  the initial risk assessment;

2.  the development of the system security plan; and

3.  the conduct of previous assessments (e.g., security testing and
    evaluation, independent verification and validation, independent
    audits).

For new information systems or systems undergoing major upgrades, this
information is typically produced during the initiation phase of the
system development life cycle when system requirements are established.
For legacy systems currently in the operations and maintenance phase of
the system development life cycle, this information is obtained from the
most recent system security plans and risk assessments. In most cases,
risk assessments and system security plans have been previously reviewed
and approved by agency officials. Thus, the subtasks in Task 1
(preparation task) should not require any additional work on the part of
the information system owner above and beyond what has already been
accomplished as part of the system development life cycle. Rather, the
Initiation Phase of the security certification and accreditation process
serves as a checkpoint to confirm that the system security plan and risk
assessment have been completed. If an information system owner has not
completed a risk assessment and a system security plan, those activities
should be completed prior to proceeding with the security certification
and accreditation process.

#### Security Certification Phase

The Security Certification Phase consists of two tasks:

1.  security control assessment; and

2.  security certification documentation.

The purpose of this phase is to determine the extent to which the
security controls in the information system are implemented correctly,
operating as intended, and producing the desired outcome with respect to
meeting the security requirements for the system. This phase also
addresses specific actions taken or planned to correct deficiencies in
the security controls and to reduce or eliminate known vulnerabilities
in the information system. Upon successful completion of this phase, the
authorizing official will have the information needed from the security
certification to determine the risk to agency operations, agency assets,
or individuals---and thus will be able to render an appropriate security
accreditation decision for the information system.

#### Security Accreditation Phase

The Security Accreditation Phase consists of two tasks:

1.  security accreditation decision; and

2.  security accreditation documentation.

The purpose of this phase is to determine if the remaining known
vulnerabilities in the information system (after the implementation of
an agreed-upon set of security controls) pose an acceptable level of
risk to agency operations, agency assets, or individuals. Upon
successful completion of this phase, the information system owner will
have:

-   authorization to operate the information system;

-   an interim authorization to operate the information system under
    specific terms and conditions; or

-   denial of authorization to operate the information system.

#### Continuous Monitoring Phase

The Continuous Monitoring Phase consists of three tasks:

1.  configuration management and control;

2.  security control monitoring; and

3.  status reporting and documentation.

The purpose of this phase is to provide oversight and monitoring of the
security controls in the information system on an ongoing basis and to
inform the authorizing official when changes occur that may impact on
the security of the system. The activities in this phase are performed
continuously throughout the life cycle of the information system.
Re-accreditation may be required because of specific changes to the
information system or because federal or agency policies require
periodic re-accreditation of the information system.

#### Department's OCIO C&A Documentation Repository 

As an ongoing process to maintain the Department's C&A documentation
repository bureaus and offices are required to ensure that the latest
final complete and accurate versions of C&A documents and related
supporting artifacts, including signed certification statements and
accreditation letters, are delivered to the Department's OCIO Cyber
Security Division (CSD). C&A documentation must also contain an
appropriate section on changes (including changed pages, date of change,
what was changed, name of individual that made the change, and document
version number). C&A documentation dates and version numbers must also
be updated. Bureaus and offices are encouraged to meet frequently with
the Department's OCIO CSD C&A Lead to review the contents of the
repository.

The C&A document dates and version numbers must be revised as well and a
copy of all updated C&A documents, including signed certification
statements and accreditation letters, must be provided to the OCIO CSD
whenever any changes are made.

### CA-1 Certification and Accreditation Requirement

Bureaus and offices shall ensure that all DOI IT systems have been
identified as a Major Application (MA) or General Support System (GSS),
and are certified and accredited.

### CA-1 Certification and Accreditation Frequency

Bureaus and offices shall ensure that certification and accreditation
has been completed:

1.  prior to the operation of information systems within a DOI computing
    environment; or

2.  upon a significant change to the system; or

3.  at least every three years.

### CA-1 IT System Accreditation Boundary

The process of uniquely assigning information resources to an
information system defines the security accreditation boundary for that
system. Bureaus and offices shall include the following factors when
establishing Major Application or General Support System Accreditation
Boundaries:

1.  Information resources that have been identified as an information
    system and are under the same direct management control, which
    includes budgetary, programmatic, or operational authority.

2.  Information resources that have been identified as an information
    system have the same function or mission objective and the same
    operating characteristics and security needs, in accordance with
    FIPS Pub 199 and NIST SP 800-60.

3.  Information resources that reside in the same general operating
    environment (or in the case of a distributed information system,
    reside in various locations with similar operating environments).

For the purpose of accreditation, information resources must be uniquely
assigned to an information system, which defines the security
accreditation boundary for that system. The accreditation boundary will
normally be the same as the boundary defined for the system being
accredited, which must be explicitly documented in the System Security
Plan. The boundary for accreditation purposes must be defined using the
following criteria:

1.  Identification, detailed description and diagram that lists servers,
    network resources and network devices included.

2.  Boundaries will be separate and distinct Major Applications or
    General Support Systems.

3.  Unique identification and description of any subsystems within the
    accreditation boundary.

#### Changing or merging established accreditation boundaries 

Bureaus and offices shall adhere to the following process when changing
or merging previously established MA or GSS accreditation boundaries:

1.  Separate and distinct information systems (MAs and GSSs) shall not
    be merged into one accreditation boundary unless; bureaus and
    offices can document, illustrate and certify the following:

    a.  Previously identified Major Applications are subsystems (major
        subdivision or components of an information system consisting of
        information, information technology, and personnel that performs
        one or more specific functions) of the new information system.

    b.  Named subsystems fall under the same higher management
        authority.

Any changes to the scope of a system boundary need to be identified by
the Bureau CIO to the DOI CISO in the form of a C&A boundary change
certification memo, signed by the Authorizing Official (AO), for review
and approval. The memo cites the scope of the C&A boundary change, the
reason for the change and proposed modifications to the enterprise
architecture repository.

The change certification memo must include:

1.  identification of all previously identified accreditation
    boundaries;

2.  identification of the new accreditation boundary;

3.  justification for change or merged accreditation boundaries; and

4.  an architectural diagram depicting the new accreditation boundary.

If a system is to be taken out of production and the C&A boundary is to
be decommissioned it needs to be identified by the bureau or office CIO
to the DOI CISO in the form of a decommissioning certification memo,
signed by the Authorizing Official (AO), that cites the scope of the C&A
boundary, the reason for decommissioning the C&A boundary and proposed
modifications to the Departmental Enterprise Architecture Repository
(DEAR). A decommissioning plan should be included that identifies the
appropriate handling of the DOI information assets associated with the
system and the sanitization of the system media in accordance with DOI
media sanitization policy.

Once a request is approved by the DOI CISO, bureaus and offices shall
ensure the following activities are completed:

1.  If a previously accredited system is being incorporated into another
    accreditation boundary the new or gaining information system C&A
    boundary must be documented and obtain an Authorization to Operate
    (ATO) in accordance with the certification and accreditation
    requirements within DOI policy. The C&A documentation must adhere to
    all requirements included in DOI policy.

2.  The Departmental Enterprise Architecture Repository (DEAR) must be
    updated immediately to reflect the new or gaining system C&A
    boundary;

3.  New POA&M items should be created within the POA&M for the new or
    gaining system's C&A boundary to carry over all existing weaknesses
    that have not yet been remediated and the related POA&M for the
    original system being incorporated into another accreditation
    boundary must be properly closed and indicate that the closeout
    action for remaining open weaknesses were migrated to the new or
    gaining system's POA&M.

4.  A validation must be performed to ensure that all POA&M items that
    are addressed in the original system's POA&M are being tracked in
    the new or gaining systems C&A boundary POA&M.

5.  Items addressed in the original system's POA&M shall be closed out
    with a status indicating that they were transferred into the new or
    gaining system's C&A boundary POA&M.

6.  The original system C&A boundary shall be marked in DEAR as being
    out of production.

7.  The original system C&A boundary shall be moved to the archive area
    of DEAR.

8.  The updated C&A security documentation and new C&A boundary ATO
    package must be submitted to the OCIO Cyber Security Division.

### CA-1 Certification and Accreditation Key Roles

The *Information Technology Security Policy Handbook and Minimum
Implementation Standards* describes roles with significant IT security
responsibilities, including those of the Chief Information Officer
(CIO), the Bureau Chief Information Security Officer, bureau or office
CIOs, and Information System Owners. In addition, roles described in the
following sections perform key functions in the certification and
accreditation (C&A) of a DOI IT system. All C&A roles and
responsibilities are documented in the DOI Certification and
Accreditation Guide and Templates.

#### Authorizing Official or Designated Approving/Accrediting Authority (DAA)

The authorizing official (AO), or designated approving/accrediting
authority (DAA) as referred to by some agencies, shall be a senior
management official or executive with the authority to formally assume
responsibility for operating an information system at an acceptable
level of risk to agency operations, agency assets, or individuals.
Through security accreditation, the authorizing official assumes
responsibility and is accountable for the risks associated with
operating an information system. The authorizing official shall have the
authority to oversee the budget and business operations of the
information systems within their bureaus or offices. In addition to
authorizing operation of information systems, the authorizing official
can also:

-   issue an interim authorization to operate for information systems
    under specific terms and conditions; or

-   deny authorization to operate for information systems (or if the
    system is already operational, halt operations) if unacceptable
    security risks exist.

Authorizing Officials for the bureaus and offices have been designated
by the Department CIO as listed below. The authorities listed below may
delegate, in writing, Authorizing Official appointments for their
information systems to the appropriate Deputy Assistant Secretaries
and/or heads of bureaus/offices. Deputy Assistant Secretaries or heads
of bureaus/offices may not further delegate their AO appointments and
associated authorities. Current copies of all AO delegation memoranda
must be provided to the OCIO Cyber Security Office.

DOI assigned Authorizing Officials are as follows:

1.  The Assistant Secretary for Fish and Wildlife and Parks is assigned
    the AO for information systems within:

    a.  National Park Service (NPS)

    b.  U.S. Fish and Wildlife Service (USFWS)

2.  The Assistant Secretary for Indian Affairs is assigned the AO for
    information systems within:

    a.  All Bureau of Indian Affairs to include ASIA

3.  The Special Trustee for American Indians is assigned the AO for
    information systems within:

    a.  Office of Historical Trust and Accounting (OHTA)

    b.  Office of the Special Trustee (OST) for American Indians

4.  The Assistant Secretary for Land and Minerals Management is assigned
    the AO for information systems within:

    a.  Bureau of Land Management (BLM)

    b.  Minerals Management Service (MMS)

    c.  Office of Surface Mining Reclamation and Enforcement (OSM)

5.  The Assistant Secretary for Water and Science is assigned the AO for
    information systems within:

    a.  US Geological Survey (USGS)

    b.  Bureau of Reclamation (BOR)

6.  The Inspector General is assigned the AO for information systems
    within:

    a.  Office of Inspector General (OIG)

7.  The Solicitor is assigned the AO for information systems within:

    a.  Office of the Solicitor

8.  The Assistant Secretary for Policy, Management and Budget is
    assigned the AO for information systems within:

    a.  Office of the Secretary (OS)

    b.  National Business Center (NBC)

    c.  All other systems not covered by any of the authorities above.

#### Authorizing Official's Designated Representative

An optional role, the authorizing official's designated representative
is a DOI management employee acting on the authorizing official's behalf
in coordinating and carrying out accreditation-related activities
required during the security accreditation of an information system. The
designated representative interacts with the System Owner, System
Security Officer, certification agent, and other interested parties, and
may be empowered by the authorizing official to make decisions with
regard to the planning of the C&A activities, including identification
of resources necessary to carry out the C&A activities.

The representative may also oversee preparation of the System Security
Plan, including and the initial determination of risk to bureau or
office operations, assets, and individuals, and to ensure that the risk
assessment that is part of the System Security Plan is updated as
appropriate following the results of the certification agent's
assessment. Such a representative must ensure that the Authorizing
Official has sufficient information to make a fully informed decision
relative to accrediting the system for operation, taking into account
the residual risk as set out by the certification agent. The designated
representative must ensure that the C&A documentation package is
complete, including documentation that the Authorizing Official
personally reviewed all key parts of the Security Accreditation Package
and received any necessary briefings to support this decision.

The only activity that cannot be delegated by the authorizing official
is the security accreditation decision and the signing of the associated
accreditation decision letter (i.e., the acceptability of risk to the
agency). If a designated representative is not selected, the authorizing
official is responsible for carrying out the activities described above.

#### Information System Owner

A System Owner is a project manager with day-to-day management and
operational control over the system and direct oversight of the
system/network administrators and operations staff. Although the federal
government has ultimate ownership of all department data and its
systems, "owner" is the term commonly used by the National Institute of
Standards and Technology to refer to individuals with specific system
oversight responsibilities. System Owners (e.g., office chiefs and
branch chiefs) have many responsibilities in addition to the day-to-day
operation and maintenance of systems under their responsibility. The
information System Owner is the manager responsible for the overall
procurement, development, integration, modification, or operation and
maintenance of the information system, and may rely on the assistance
and advice of the BCISO and other IT staff in the implementation of the
following security responsibilities. The System Owner shall ensure:

1.  Development of the System Security Plans and address PII risks by
    evaluating information from Privacy Impact Assessments and Privacy
    Act notices, including the initial risk assessments;

2.  Information system are operated according to the agreed upon
    security requirements;

3.  Appropriate information system access (appropriate rights and
    privileges);

4.  Users and support personnel receive the requisite security training;

5.  Security Certification and Accreditation on information systems is
    conducted;

6.  Necessary system-related documentation is provided to the
    certification agent;

7.  Appropriate steps are taken to update the risk assessments and to
    reduce or eliminate vulnerabilities after receiving the security
    assessment results from the certification agent; and

8.  Security Accreditation Packages are assembled and submitted to the
    authorizing official or their designated representative.

***The System Owner*** is responsible for the safekeeping of the
original of the Security Accreditation Package that has been used for
the accreditation decision. The System Owner is responsible for updating
this package and ensuring re-accreditation as the system undergoes a
significant change or at least every three years. In this respect, the
System Owner must:

1.  Include security considerations in the procurement of system
    software, hardware, and support services, including system
    development, implementation, operation and maintenance, and disposal
    activities (i.e., life cycle management);

2.  Ensure certification and accreditation of all systems under their
    responsibility including

    a.  Ensuring the security of data and application software residing
        on their system(s);

    b.  Determining and implementing an appropriate level of security
        commensurate with the system impact level;

    c.  Developing and maintaining the Security Accreditation Package,
        including IT System Security Plans and contingency plans for all
        systems under their responsibility, which document the business
        associations and dependencies of their system (examine linked IT
        resources and flow of information); and

    d.  Performing risk assessments to periodically re-evaluate
        sensitivity of the system, risks, and mitigation strategies.

    e.  Conducting annual self-assessments of system safeguards and
        program elements;

    f.  Establishing system-level plans of action and milestones
        (POA&Ms) and implement corrective actions in accordance with the
        DOI POA&M Standard.

3.  Grant individuals the fewest possible privileges necessary for job
    performance (any privileges not specifically granted are denied
    access) so that privileges are based on a legitimate need to have
    system access, and re-evaluate the access privileges annually,
    revoking access in a timely manner upon personnel transfer or
    termination;

4.  Establish appropriate rules of behavior for all systems that apply
    to all personnel managing, administering, or having access to the
    DOI IT system;

5.  Notify the responsible System Security Officer and/or BCISO of any
    suspected incidents in a timely manner, and assist in the
    investigation of incidents if necessary;

6.  Ensure system users have proper and relevant IT security training
    (relevant to the system);

7.  Ensure IT system IT service contracts include provisions for
    necessary security; and

8.  Ensure systems' personnel are properly designated, monitored, and
    trained, to include appointing, in writing, an individual to serve
    as the Information System Security Officer (ISSO).

#### The Bureau or Office Certification and Accreditation (C&A) Manager

The bureau or office Certification and Accreditation Manager shall be
appointed in writing by bureau or office CIO. The C&A manager shall be
responsible for ensuring adequate planning and compliance with respect
to the certification and accreditation and IT security requirements,
standards and guidelines issued by the Office of Management and Budget
(OMB), NIST, and DOI.

#### Certification Agent

The certification agent is an individual, group, or organization
responsible for conducting a security certification, or comprehensive
assessment of the management, operational, and technical security
controls in an information system to determine the extent to which the
controls are implemented correctly, operating as intended, and producing
the desired outcome with respect to meeting the security requirements
for the system. The certification agent also provides recommended
corrective actions to reduce or eliminate vulnerabilities in the
information system, and recommendation to the Authorizing Official on
accreditation of information systems.

To preserve the impartial and unbiased nature of the security
certification, specifically for Moderate and High impact information
systems, the certification agent must be in a position that is
independent from the persons directly responsible for development,
operation, and management chain of command associated with the
information system.

The certification agent should also be independent of those individuals
responsible for correcting security deficiencies identified during the
security certification. The independence of the certification agent is
an important factor in assessing the credibility of the security
assessment results and ensuring the authorizing official receives the
most objective information possible in order to make an informed,
risk-based, accreditation decision.

Bureau and office Chief Information Officers have been designated
Certification Agents for information systems within their bureaus or
offices. If the CIO is the information system owner the CA
responsibility shall be delegated to the Authorizing Official's
Designated Representative, Senior Information Security Officer, or other
suitable individual.

#### User Representative

User representatives are individuals that represent the operational
interests of the user organization and serve as liaisons for that
organization throughout the system development life cycle of the
information system. The user representative assists in the C&A process,
when needed, to ensure mission requirements are satisfied while meeting
the security requirements and employing the security controls defined in
the System Security Plan.

## CA-2 -- Security Assessments

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall conduct IT Internal Control Review (ICR)
security assessments of all operational information systems listed in
the C&A boundary definitions within DEAR and for all IT security
programs at least annually, and shall adhere to OCIO annual ICR guidance
for implementation. The purpose of the ICR is to determine to what
extent the program and controls have been implemented correctly, are
operating as intended, and are producing the desired outcome for the
purpose of meeting security requirements of each system and the bureau
or office IT security program.

#### Policy Supplement(s):

CA-2(a)

In accordance with OMB policy and FISMA, bureaus and offices must assess
all IT systems annually to determine their level of security control
implementation. However, only a subset of those security controls within
information systems should be selected for testing each year. Each
system owner in coordination with the ISSO shall select a representative
sample of each system's controls to test based on:

1.  the FIPS 199 security categorization of the information system;

2.  POA&Ms remaining open, closed, or compensating controls employed to
    protect the information system;

3.  controls identified by the information owner (business process
    owner) as key controls related to financial reporting in order to
    combine testing requirements with that of OMB Circular A-123; and

4.  the level of assurance (or confidence) that the bureau or office
    must have in determining the effectiveness of the security controls
    in the information system.

CA-2(b)

In order to efficiently conduct ICRs while minimizing redundant efforts,
annual self- assessments shall be combined with the following efforts
because these activities also require in-depth assessments of security
control implementation levels. Efforts include but are not limited to:

1.  security certifications conducted as part of an information system
    accreditation or reaccreditation process;

2.  continuous monitoring activities; and

3.  routine testing and evaluation of the information system as part of
    the ongoing system development life cycle process (provided that the
    testing and evaluation results are current and relevant to the
    determination of security control effectiveness).

### CA-2 Bureau or Office Program and System Self-Assessments

DOI bureaus and offices must satisfy the FISMA and OMB Circular A-123
annual self-assessment requirements by combining (where possible) IT
security control assessments and the testing of security controls for
financial system reporting, according to DOI's annual ICR guidance.
Bureau and office ICR leads responsible for the execution of annual self
assessments shall ensure the following requirements are met to
facilitate proper coordination and collaboration:

1.  ensuring that key controls for financial reporting are identified in
    coordination with the system owner, information owner (business
    process owner), and bureau or office financial reporting ICR lead in
    order to identify common testing requirements and to avoid redundant
    testing;

2.  devising and developing an overall bureau or office plan for the
    annual assessment and testing of IT security controls and
    coordination of testing financial controls to ensure all
    departmentally established goals and deadlines are coordinated and
    met;

3.  establishing a schedule of testing that ensures both financial and
    IT representatives are fully aware of their role, the milestone
    expectations, and the reporting format of results; and

4.  ensuring the IT and financial self-assessment leads attend all A-123
    status meetings, on-site departmental assistance visits, and
    internal bureau or office status meetings to facilitate cooperation
    and understanding of both processes.

#### Assurance Statements

The DOI CIO makes recommendations to the Secretary of the Interior
through the use of assurance statements stating compliance status of the
bureau or office information systems with FFMIA, FMFIA, and FISMA. Each
bureau or office CIO supports their Director's assurance statements by
collecting information regarding compliance, and attesting to the
current state of implementation, according to each act listed above, in
their own assurance statements. The specific procedures bureaus and
offices shall follow in the creation, coordination, and submission of
assurance statements are outlined in the DOI annual IT Internal Control
Review (ICR) guidance.

#### Material Weakness

Management declares a material weakness based on the findings of any
method of discovery used to review security controls implementation such
as annual assessments, financial audits, OIG audits, reaccredidation,
continuous monitoring, ICRs, etc.

Material weaknesses significantly impair the Department's ability to
protect its data and IT systems. In accordance with the most current OMB
policy and the DOI Office of Financial Management (PFM) instructions,
bureaus and offices shall identify, correct, and report material
weaknesses as part of the annual ICR process.

Outlined in OMB policy and the PFM Internal Control and Audit Follow-up
(ICAF) handbook are the following procedures that must be followed
regarding material weaknesses:

1.  identification and reporting a significant deficiency as:

    a.  a material weakness under FMFIA, or

    b.  an instance of a lack of substantial compliance under FFMIA, if
        related to financial management systems.

2.  linking correction of weaknesses/deficiencies to budget submissions

3.  correcting material weaknesses/deficiencies

4.  monitoring corrective actions

5.  reporting progress in Corrective Action Plans (CAP)

6.  verifying and certifying corrective actions

All security weaknesses (including those identified as a significant
deficiency or material weakness) must be included in and tracked within
bureau or office POA&Ms or the departmental POA&M if the weakness is
systemic throughout DOI. Bureaus and offices shall use the annual
Internal Control Review guide's specific instructions as published by
the Cyber Security Division for the most up to date and relevant
guidance.

#### Software Licensing Audits

#### This policy supersedes:

-   OCIO Directive 2006-006, "Software Piracy"

Bureaus and offices shall develop procedures to ensure that System
Owners and end users are aware of the consequences for violating
software copyrights. The BCISO shall report any infringements identified
during the normal course of control monitoring and self-assessment to
the violator's supervisor, notify the Office of the Inspector General,
and notify the CSD compliance lead. The following provides minimum
guidance for preventing organizational software piracy. Software and
associated documentation shall be used in accordance with contract
agreements and copyright laws. Specifically, all DOI IT system users,
including employees, contractors, partners, cooperators, grantees and
volunteers shall:

1.  follow all provisions of the licensing agreements issued with the
    software and register organizational (governmental) ownership;

2.  use a recordkeeping system to ensure that software is properly
    inventoried, noting the authorized number of users and/or site
    locations;

3.  not make any illegal copies of copyrighted software. The software
    license may allow a single copy to be made for archival purposes. If
    the license is for multiple users, do not exceed the authorized
    number of copies;

4.  store licenses, software manuals, original software, and procurement
    documentation in a secure location (e.g., closed file cabinet,
    etc.);

5.  dispose of or store old versions of software in accordance with the
    licensing agreement when upgrades to software are purchased, to
    avoid a potential violation. Upgraded software is considered a
    continuation of the original license, not an additional license;

6.  notify the system owner and/or the system support staff immediately
    if a copy of any software is detected that may not have been copied
    or used consistent with the license associated with that software,
    so appropriate action can be taken; and only use resources protected
    by copyright or patent in a manner consistent with such copyright or
    patent.

### CA-2 DOI Compliance Reviews

#### Compliance Review Overview

Compliance reviews evaluate the method of implementation and
effectiveness of the bureau and office IT Security Programs within DOI.
Compliance reviews are performed on-site by CSD staff, separate from
self-assessments completed on the part of bureaus and offices. Whereas
the self-assessments provide a check of IT security controls, compliance
reviews provide the balance to validate data, report overall program
status, and provide senior management a cumulative perspective over the
bureau- and office-level program implementations, as part of meeting the
DOI IT Security Program objectives.

CSD performs annual compliance reviews of all bureau and office IT
Security Programs and selected system security controls to assess the
effectiveness of the bureau or office's implementation of IT security
requirements using a variety of established and customized review
methodologies. The review methodology follows federal mandate and
guidelines such as FISMA, NIST SP 800-53, Rev.1 and 53A, OMB Circular
A-123, and Departmental guides and standards. The DOI CSD compliance
lead shall explain the methodology for the review each year prior to the
start of the review. The CSD uses a risk management approach to identify
program- and issue-specific areas and to select samples for review.

#### Compliance Review Process

Compliance reviews shall be conducted on-site as well as through the
review of C&A documentation provided to the CSD prior to the beginning
the review process within each bureau or office. The CSD compliance
review lead shall gain approval from the Departmental CISO regarding the
methodology, timeline for execution, and criteria to of elements to
evaluate during the reviews. A scheduled visit for each review shall be
culminated into a Departmental schedule and coordinated with each BCISO
for planning purposes. The annual schedule of compliance review visits
will be published at least 30 days in advance of the start of the
reviews for planning purposes. Bureaus and offices shall make
accommodations to provide proper expertise to the CSD staff for the
purpose of interviews, production of documentation to be examined, and
to system administrators to provide access to information system
controls to be reviewed. At no time shall CSD staff perform actions
directly on any bureau or office information system. Bureaus and offices
are responsible to ensure the CSD C&A repository contains the most
up-to-date documentation for all systems within their organization. The
following is an outline of the review process:

1.  select C&A documentation shall be reviewed during the week prior to
    on-site visits;

2.  on-site reviews shall comprise three to five days of program and
    system review;

3.  compliance with FISMA and Departmental guidance shall be comprised
    of interviews with system administrators, system owners, BCISOs,
    ISSOs, and other IT staff as available;

4.  documentation to be reviewed shall consist of various bureau-level
    promulgated policies that direct the implementation of and/or
    enhance to Departmental directives and policies;

5.  review of CSD selected information system SDLC, CPIC and Exhibit
    300/300-lite documentation to ensure IT security funding is properly
    planned for within each system's budgetary process;

6.  review of CSD selected POA&M documentation to ensure evidence for
    corrective actions and funding is allocated for corrective actions
    and documented;

7.  collection of evidentiary documents to support the implementation of
    security within various facets of the bureau or office IT
    organizations as outlined in the annual CSD methodologies for
    program reviews;

8.  within seven business days of an on-site review, the CSD compliance
    lead will provide a preliminary report of results to the bureau or
    office BCISO; and

9.  within 30 calendar days of an on-site review, the CSD compliance
    lead will provide a final report of results to the bureau or office
    BCISO (minus on-going graded bureau-level efforts such as awareness
    training, ICRs, etc.).

#### Compliance Review Purpose

OMB Circular A-130, Appendix III, requires agencies to develop,
implement, and review a comprehensive, agency-wide security program.
This program includes periodic assessments of security risks to
information systems and data. Within DOI, each review provides the
Department CIO and bureau or office CIOs with an assessment of the
bureau or office's security program implementation. The reviews also
provide support for formulating the Departmental CIO's assurance
statement to the Secretary, attesting to the overall status of DOI's IT
Security Program effectiveness and aids in the determination of
existence of any material weaknesses within the Department-wide IT
Security Program. The reviews not only enable identification of IT
security weaknesses requiring correction, but also the strengths and
best practices across the Department. The review process improves the
Department's overall security posture by monitoring compliance with
departmental and higher authority policies.

### CA-2 DOI Security Documentation Compliance Reviews

As a part of the OCIO responsibility of oversight of departmental
information assets, the OCIO Cyber Security office shall perform
compliance review of all bureau and office information system security
accreditation packages. Bureaus and offices shall submit new or updated
IT security documentation on an ongoing basis to the OCIO Cyber security
office in support this requirement.

Bureau IT security documentation will be maintained centrally and
primarily used for critical infrastructure protection identification,
internal reviews, audit/assessment support, enterprise architecture and
capital planning initiatives, and reporting requirements levied by the
Office of Management and Budget, the Congress, and others.

Bureaus and offices shall submit:

1.  The most current certification and accreditation (C&A) documentation
    as required by this policy, and any other relevant supporting
    documentation.

2.  If a DOI system has been granted an IATO bureaus will provide all
    documents as listed in this policy, and the following:

3.  IATO Request Letter, signed and dated

4.  IATO Approval Letter, signed and dated

5.  In cases where they differ from departmental standards, bureaus and
    offices will provide the most current policies, directives,
    procedures, and training/awareness materials that support IT
    security at the program and system level.

#### Submission of Information Technology Security Documentation

Updates to C&A documentation that warrant a submission to the OCIO Cyber
Security Division include:

-   New or updated documentation to comply with new or revised DOI or
    federal policies, standards or guidance.

-   Updated documentation to record any significant change in the IT
    system C&A boundary, security posture, security categorization,
    security controls, residual risk, or operating environment.

-   Creation of any new security documentation or finalization of any
    draft documentation.

Bureaus and offices shall save the IT security documentation on an
appropriately labeled compact disk (CD). The CD label must contain at a
minimum:

1.  Bureau

2.  Date of CD creation for submission

3.  Sensitivity Markings

Bureaus and offices shall ensure that the IT security documentation
files follow a standard naming convention to facilitate the ease of
uploading and tracking. Naming convention characteristics shall follow
the following format:

1.  System Acronym

2.  Document Acronym or Title

3.  Document Date -- This date should reflect the date of the latest
    version of the documentation, not the CD creation date. The date
    format is: MMDDYY

4.  Version Number

5.  Example: (ESN_SSP_100506_v2.0.doc)

In accordance with departmental policy for protection of sensitive
information, bureaus and offices shall encrypt the documentation
contained on the CD using the latest version of the Pretty Good Privacy
(PGP) encryption software. Bureaus and offices shall ensure that IT
security personnel's PGP public keys are sent electronically to the
Cyber Security Division.

Bureaus and offices shall ensure a transmittal memorandum is submitted
with CD. The transmittal memorandum shall include:

1.  List the Contents of the CD

2.  Certify the information being submitted is up to date and accurate

3.  Contain the signature of the bureau Chief Information Officer (CIO)
    or Bureau Chief Information Security Officer (BCISO) or Bureau or
    Office C&A Manager.

Bureaus and offices shall submit, to the OCIO Cyber Security Division, a
complete security accreditation package as referenced in Section CA-4.

For any IT systems that have been decommissioned, bureaus and offices
shall submit decommission certification memorandums signed and dated by
the System Owner, Authorizing Official and bureau or office CIO.

IT security documentation CDs can be hand delivered or mailed via secure
messenger to the OCIO Cyber Security Office, Mail Stop 5312 at 1849 C
Street, N.W.; Washington D.C., 20240.

### CA-2 Security Test and Evaluation (ST&E)

ST&E is the process used to examine the effectiveness of IT system
controls with the objective of determining the true risk, or exposure,
of the system to certain threats. NIST Special Publication 800-30, *Risk
Management Guide for Information Technology Systems* and NIST Special
Publication 800-37, *Guide for the Security Certification and
Accreditation of Federal Information Systems*, identify ST&E as a method
to identify system vulnerabilities. In addition, NIST Special
Publication 800-37 identifies ST&E as a means to document the basis for
residual risk in the certification and accreditation process. The NIST
SP 800-53A, *Guide for Assessing the Security Controls in Federal
Information Systems*, provides the methodology for identifying the
effectiveness of the implemented controls*.*

By conducting security control tests security personnel are able to
identify vulnerabilities that result from improper use of controls,
missing controls, inherent system vulnerabilities, or mismanagement.
ST&E analyzes the current state of the system by reviewing the system
objects, and searching for anomalies that might indicate vulnerabilities
that could permit an attack. ST&E results in development of a plan of
actions and milestones to track corrective actions necessary to mitigate
vulnerabilities and reduce risk.

#### ST&E Frequency

Bureaus and offices shall include security test and evaluation
throughout a system's implementation and operational life cycle phases,
and at least annually for a subset of security controls. The following
are three key milestones that involve security test and evaluation:

-   Initiation phase, vulnerability identification task

-   Security certification phase, security assessment task

-   Continuous monitoring phase, selected security control assessment.

#### ST&E Execution -- Security Assessment

During the certification and accreditation process, the certification
agent or risk assessment team conducts and documents testing of the
system controls. The certification agent must document a Security Test
Plan that describes the test methods, tools to be used, and test
procedures to be performed. The certification agent or team also
documents the security test results in the Security Test and Evaluation
Report. In addition, the System Owner must build upon the certification
agent's Security Test Plan to develop an ongoing vulnerability testing
plan for periodic testing during the operational life of the system, and
include the plan as part of the IT System Security Plan documentation to
describe reviews of security controls methodology and procedures. The
System Owner must conduct (or hire a contractor to conduct) testing on a
regular basis and at critical milestones, such as significant changes to
the system, or at least annually.

#### ST&E Testing Scope

For Moderate and High impact information systems undergoing
certification or re-certification, the certification agent -- an
individual independent of daily system operations -- shall select, or
develop, manual and automated procedures to assess the security controls
in the information systems. For low-impact systems, the information
System Owner may employ the services of the Information System Security
Officer or other designated individuals (including contractors) to
select or develop when needed, the appropriate methods and procedures
necessary to conduct a self-assessment of the information system
security control baseline as prescribed by this policy.

The certification agent independent of daily system operations is
required to prepare and document the Security Test and Evaluation Plan,
Security Test and Evaluation Report and Risk Assessment Report. Security
Test plans and reports must identify all devices included in the
accreditation boundary to be tested, and the test results must be
identified for each device.

The rigor of testing must be commensurate with the system's security
categorization and the test plan and procedures must describe the steps
and tools that will be followed for testing all of the applicable
baseline controls in the following control families:

-   evaluation of the effectiveness of management controls;

-   evaluation of the effectiveness of operational controls; and

-   evaluation of the effectiveness of technical controls to include
    Security Technical Implementation Guide (STIG) compliance.

Upon completion of testing, the certification agent reviews the Security
Test and Evaluation Report with the System Owner and the Authorizing
Official (or their designated representative). The System Owner then
prepares a POA&M to track corrective actions necessary to mitigate
vulnerabilities and reduce risk to a level acceptable to the Authorizing
Official.

#### ST&E Methods

Individual tests must evaluate system conformance with the control
requirements, mission, environment, and architecture as defined in the
IT System Security Plan. Documented test plans and procedures must
address all the security controls and relevant test cases and provide
evidence of the amount of residual risk sufficient to support a fully
informed risk decision. The test results must validate the proper
integration and operation of all security features, and the
certification agent's evaluation of the results must be documented as
part of the Security Accreditation Package. Methods to test controls
include:

1.  Collection and review of all documents and supporting materials
    included or referenced in the IT System Security Plan;

2.  security reviews audits;

3.  security certifications;

4.  self-assessments;

5.  prior security test and evaluation reports;

6.  privacy impact assessments;

7.  training records; and

8.  STIG validations.

#### This review of documentation will assist in:

##### System Management Analysis -- 

The system management infrastructure must be examined to determine
whether it adequately supports the maintenance of the environment,
mission, and architecture described in the security plan. Infrastructure
components include the security policies, system and security management
organizations, security training and awareness, rules of behavior,
incident response plan and procedures, virus detection procedures, and
the configuration management organization and processes. These
components may provide insight into security of operations at the site.

##### Contingency Plan Evaluation -- 

The contingency plan evaluation task analyzes the contingency, back-up,
restoration, and continuity of service plans to ensure the plans are
consistent with the requirements identified in the security plan. The
plans should consider a range of service interruptions from minor to
major disasters caused by events such as power outages, system failure,
natural disasters, enemy actions, or malicious code. Annual testing of
contingency plans is required this policy, and the contingency plan must
document the test procedures and results of the last test.

##### Site Evaluation -- 

Physical observations of the system site (e.g., facility, data center,
server room, and end user work areas) validates that the controls at the
site are as documented in the security plan, and that controls are in
place and functioning. The site evaluation analyzes the personnel
security, physical security and environmental controls to determine if
they pose any unacceptable risks to the information system. Where the
system is not confined to a fixed site (mobile systems and systems
embedded in ships or aircraft), the system may be examined at
representative sites or environments.

##### Technical Vulnerability Assessment -- 

The vulnerability assessments shall include manual testing, automated
scans and technical validation of NIST SP 800-53 technical controls and
the implementation of security technical implementation guides (STIGs)
for applications and operating systems to determine if the risk to
confidentiality, integrity, availability, and accountability from
internal and external threat sources from known vulnerabilities is being
maintained at an acceptable level and that secure configuration policies
are maintained.

Annual penetration testing is required for all High and Moderate impact
information systems. Only authorized personnel are permitted to perform
penetration testing. Any requirement for penetration testing will be
forwarded to the Bureau's IT Security Operations Team for approval.
Penetration testing assesses the system's ability to withstand
intentional attempts to circumvent system security features by
exploiting technical security vulnerabilities. Penetration testing may
include insider and outsider penetration attempts, both physical and
logical, based on common vulnerabilities for the technology being used
and the facility in which it is housed. Penetration testing activities
shall be performed in accordance with the NIST SP 800-42, *Guideline on
Network Security Testing*.

## CA-3 -- Information System Connections

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall authorize and document all connections from
DOI information systems to other information systems outside of the
accreditation boundary through the use of system connection agreements
and monitor and control the system connections on an ongoing basis in
accordance with NIST Special Publication 800-47, *Security Guide for
Interconnecting Information Technology Systems*.

#### Additional Policy Guidance:

Interconnection Security Agreements (ISAs), Memoranda of Understanding
(MOUs), and / or Memoranda of Agreements (MOAs) must be developed, as
appropriate and maintained within information Systems Security Plans.

## CA-4 -- Security Certification

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall conduct assessments of the security controls
in all information systems to determine the extent to which the controls
are implemented correctly, operating as intended, and producing the
desired outcome with respect to meeting the security requirements for
the system.

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall employ an       | X        | X      |
| independent certification agent or              |          |        |
| certification team to conduct an assessment of  |          |        |
| the security controls in the information        |          |        |
| system.                                         |          |        |
|                                                 |          |        |
| An independent certification agent or           |          |        |
| certification team is any individual or group   |          |        |
| capable of conducting an impartial assessment   |          |        |
| of bureau or office information systems.        |          |        |
| Impartiality implies that the assessors are     |          |        |
| free from any perceived or actual conflicts of  |          |        |
| interest with respect to the developmental,     |          |        |
| operational, and/or management chain of command |          |        |
| associated with the information systems or to   |          |        |
| the determination of security control           |          |        |
| effectiveness.                                  |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514797 .anchor}Table 25: CA-4 -- Security
Certification Mandatory Policy Enhancement(s)

### CA-4 IT Security Accreditation Package Documents

The IT security accreditation package for a DOI system documents the
results of the security certification and provides the Authorizing
Official with the essential information needed to make a credible,
risk-based decision on whether to authorize operation of the information
system. The security accreditation package shall contain at a minimum
the following documents. The DOI Certification and Accreditation Guide
contains a complete listing of all documentation and references that
should be included in an accreditation package. If there are no
departmental standardized templates available, bureaus and offices shall
follow the templates provided in NIST guidance.

**System Security Plan (SSP)** -- that has been prepared by the System
Owner and approved by the Authorizing Official (or their designated
representative)\]. The System Security Plan shall include (either as
supporting appendices or as references) key security-related documents
for the system including, but not limited to:

1.  Listing of Information System Data Types and Security
    Categorizations in accordance with FIPS 199 and NIST Special
    Publication 800-60

2.  Privacy Impact Assessment

3.  Business Impact Assessment

4.  Risk Assessment

5.  C&A Boundary Hardware/Software Inventory

6.  Interconnection Security Agreements / System Interconnection
    Agreements / Memoranda of Understanding(s), reference NIST SP
    800-47, *Security Guide for Interconnecting Information Technology
    Systems*

7.  Contingency Plan

8.  Configuration Management Plan / Change Management Plan

In addition, the System Owner or other IT personnel *may* maintain
supporting system development documentation, which *may* include:

-   vendor-supplied documentation of purchased software,

-   vendor-supplied documentation of purchased hardware,

-   application documentation for in-house applications,

-   detailed documentation on operation of networks, routers, and
    switches,

-   software and hardware acceptance testing procedures and results, and

-   user operations manuals.

**Security Test and Evaluation Plan (ST&E) Plan** -- The Security Test
Plan documents the scope and procedures for testing of the system's
control baseline. At a minimum, DOI requires the Security Plan to
contain:

1.  A list of all management, operational, and technical controls
    required by the IT System Security Plan to be tested;

2.  descriptions of the test methods (e.g., document review, interview,
    observation, technical scan, etc.) to be used;

3.  relevant test cases for all devices included within the documented
    accreditation boundary; and

4.  identification of system boundary devices to be tested.

**Security Test and Evaluation Report (ST&E) Report** -- that has been
prepared by the certification agent referencing the complete
certification documentation package. The report includes:

1.  the results (manual and automated) of security testing and
    evaluation for each devise included within the documented
    accreditation boundary;

2.  recommendations for correcting any identified deficiencies in the
    security controls and reducing or eliminating identified
    vulnerabilities; and

3.  raw data collected from the application security scanning tools
    identified in the Security Test and Evaluation Plan.

**Risk Assessment Report** -- The Risk Assessment Report shall document
the risk associated with each security configuration item that has not
been implemented, or that has been partially implemented, that the
Authorizing Official is accepting the risk for including:

1.  a description of the risks to the information or information system
    associated with not implementing the security configuration item;

2.  a description of any mitigating/compensating controls (to include
    whether or not the mitigation either eliminates or partially
    mitigates the risk);

3.  the resulting residual risk level after mitigating actions have been
    implement (e.g., in terms of High, Moderate, or Low);

4.  the documented rationale/justification as to both why the security
    configuration item can not be fully implemented and how any
    mitigating actions effectively serve as compensating control
    contributing to the determination of the resulting residual risk
    level.

The Risk Assessment Report may also include the bureau or office Annual
Self-Assessment in accordance with NIST Special Publication 800-53A.

**Plan of Action and Milestones (POA&M)** -- prepared by the System
Owner during the certification effort or after reviewing the Security
Test and Evaluation Report, that describes the measures that are planned
and scheduled (1) to correct any deficiencies noted during the
assessment of the security controls, and (2) to reduce or eliminate
known vulnerabilities in the system. The authorizing official may, after
review of the Security Test and Evaluation Report, direct the System
Owner in the accreditation decision letter to address additional
corrective actions that the System Owner must add to the POA&M.

**Certification Transmittal Memorandum** -- prepared, signed and dated
by the Certifying Agent that provides a summary of the security
assessment and a recommendation for an approval to operate to the
Authorizing Official.

**Accreditation Decision Letter** -- prepared signed and dated by the
Authorizing Official that provide authorizes an information system to
operate.

## CA-5 -- Plan of Action and Milestones

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop and ensure the continuous update of a
plan of action and milestones (POA&M) for all information systems that
fully documents their organization's planned, implemented, and evaluated
remedial actions to correct deficiencies noted during the assessment of
the security controls and to reduce or eliminate known vulnerabilities
in the system in accordance with the DOI POA&M Process Standard.

### CA-5 Plan of Actions and Milestones (POA&M) Contents

#### The DOI POA&M Process Standard 

The standard details the process and minimum mandatory implementation
requirements for completion of POA&Ms by all DOI bureaus and offices in
accordance with guidance issued by the OMB. In addition, the DOI POA&M
Process Standard describes DOI-specific requirements that are necessary
for the consistent and comprehensive completion of required updates to
all IT security POA&Ms and establishes reporting formats for POA&Ms.
Updates to POA&M status should be reported and reconciled monthly as
outlined in bureau or office internal policy. Updates to POA&M status
and metrics are required to be sent to OMB on a quarterly basis. As the
schedule for required reporting of POA&M updates and metrics status to
OMB changes frequently, updates to DOI required reporting dates shall be
promulgated annually by the CSD.

### CA-5 Plan of Actions and Milestones (POA&M) Management

BCISOs are responsible for assigning an individual to manage and track
POA&Ms for all information systems within their bureau or office. The
System Owner responsible for the system with cited deficiencies must
develop system-level POA&Ms for each system, and must implement the
corrective actions for each system. The Information System Security
Officer must submit the POA&Ms to the bureau or office POA&M coordinator
as they are updated with current information in accordance with the
reporting format defined in DOI POA&M Process Standard.

### CA-5 Reporting Findings from Audits, Compliance Reviews or Self-Assessments

BCISOs must ensure the development and management of an internal process
to track corrective actions for weaknesses in critical elements of their
IT Security Program and system security controls that is compliant with
the DOI POA&M Process Standard. At a minimum, bureaus and offices, and
the CSD in the case of Department-level deficiencies, must document all
IT security control deficiencies warranting corrective action in a POA&M
that were identified by those activities listed within the DOI POA&M
Process Standard.

## CA-6 -- Security Accreditation

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall authorize (i.e., accredit) all information
systems for processing before operations and update the authorization at
least every three (3) years or when there is a significant change to the
system. An appointed Authorizing Offices shall sign and approve all
security accreditations. A Privacy Act notice must be in place before a
Privacy Act system of records is operational or the penalties will
apply.

### CA-6 Accreditation Decisions

An Authorizing Official may render one of three types of accreditation
decisions:

**Authorization to Operate (ATO)**: If, after assessing the results of
the security certification, the risk to bureau or office operations,
assets, or individuals is deemed fully acceptable to the Authorizing
Official, a full authorization to operate (ATO) is issued for the
information system. Although not affecting the security accreditation
decision, Authorizing Officials may recommend specific actions be taken
by the System Owner to reduce or eliminate identified vulnerabilities,
where it is cost effective to do so.

**Interim Authorization to Operate (IATO)**: In accordance with OMB
policy, an information system is **[not]{.underline}** accredited with
an issuance of an interim authorization to operate. If an IATO is issued
the program will be reported to OMB and placed on a watch list for
high-risk programs. The high-risk programs will be scrutinized by the
DOI and OMB for their program management practices and project funding
may be impacted.

If, after assessing the results of the security certification, the
Authorizing Official deems that the risk to bureau or office operations,
assets, or individuals is unacceptable, but there is an overarching
mission necessity to place the information system into operation or
continue its operation, an interim authorization to operate (IATO) may
be issued. An interim authorization to operate is rendered when the
identified security vulnerabilities in the information system resulting
from deficiencies in the planned or implemented security controls are
significant but can be addressed in a timely manner. An interim
authorization provides authorization to operate an information system
under specific terms and conditions and acknowledges greater risk to the
bureau or office for a specified period of time. The terms and
conditions, established by the Authorizing Official in the IATO decision
letter, must convey the limitations on information system operations.

The plan of action and milestones submitted by the information system
owner is used by the authorizing official to monitor the progress in
correcting deficiencies noted during the security certification. In
addition to executing the plan of action and milestones, information
system owners should also establish a disciplined and structured process
to monitor the effectiveness of the security controls in the information
system during the period of limited authorization to operate. Monitoring
activities should focus on the specific vulnerabilities in the
information system identified during the security certification.
Significant changes in the security state of the information system that
occur during the period of limited authorization to operate should be
reported immediately to the authorizing official.

The duration established for an interim authorization to operate should
be commensurate with the risk to agency operations, agency assets, or
individuals associated with the operation of the information system.

Use of an interim authorization to operate should be discouraged and
approved by Authorizing Officials only under the most extreme or
extenuating of circumstances.

**Denial of authorization to operate**: If, after assessing the results
of the security certification, the risk to bureau or office operations,
assets, or individuals is deemed unacceptable to the Authorizing
Official, the authorization to operate the system can be denied. Failure
to receive authorization to operate or an interim authorization to
operate usually indicates that there are major deficiencies in the
security controls in the system and the System Owner must revise the
plan of action and milestones to ensure that proactive measure are taken
to correct the deficiencies. In addition, an Authorizing Official may,
at their discretion, remove a system from operation if the system fails
re-accreditation.

The authorizing official may direct the System Owner to remove a system
from operation if the required corrective actions have not been
completed as documented in the plan of actions and milestones. The
Authorizing Official shall monitor the plan of action and milestones
submitted by the information System Owner to ascertain progress in
correcting deficiencies noted during the security certification.

When the security-related deficiencies have been adequately addressed,
the System Owner must request that the Authorizing Official lift the
denial to operate and grant the information system full authorization to
operate. Security re-accreditation occurs when significant changes have
taken place in the information system or when a specified time period
has elapsed in accordance with policy.

### CA-6 Security Accreditation Decision Letter

The security accreditation decision letter transmits the Authorizing
Official's accreditation decision. The Authorizing Official attaches the
letter to the accreditation package and returns the package to the
information System Owner.

The security accreditation decision letter shall include the following
information:

Accreditation decision:

1.  Supporting rationale for the decision, including a statement of
    acceptance of the residual risk;

2.  Terms and conditions for the authorization; and

3.  Length of time for the authorization to operate.

The time period for re-accreditation is calculated from the date the
information system receives its authorization to operate. Upon receipt
of the security accreditation decision letter the System Owner keeps the
original decision letter and security accreditation package on file and
updates the documents as necessary and as required by policy. The System
Owner also provides a copy of the accreditation package and signed
accreditation decision letter to the BCISO and the OCIO Cyber Security
Division.

## CA-7 -- Continuous Monitoring

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall monitor the security controls in all
information systems on an ongoing basis.

#### Policy Supplement(s):

CA-7(a)

Bureaus and offices shall ensure that continuous monitoring activities
include configuration management and control of information system
components, security impact analyses of changes to the system, ongoing
assessment of security controls, and status reporting.

CA-7(b)

Bureaus and offices shall establish the selection criteria and
subsequently select a subset of the security controls employed within
information systems for assessment.

#  

# Configuration Management (CM)

Bureaus and offices shall comply with the NIST Special Publication
800-53, Rev.1, *Recommended Security Controls for Federal Information
Systems,* configuration management controls listed in the following
table:

+-------+----------------------------+-----------+----------+----------+
|  Con  |                            |           |          |          |
| figur |                            |           |          |          |
| ation |                            |           |          |          |
| Manag |                            |           |          |          |
| ement |                            |           |          |          |
+-------+----------------------------+-----------+----------+----------+
|       |                            | Control   |          |          |
|       |                            | Baselines |          |          |
| Co    | Control Name               |           |          |          |
| ntrol |                            |           |          |          |
| N     |                            |           |          |          |
| umber |                            |           |          |          |
+-------+----------------------------+-----------+----------+----------+
|       |                            | Low       | Moderate | High     |
+-------+----------------------------+-----------+----------+----------+
| CM-1  | Configuration Management   | CM-1      | CM-1     | CM-1     |
|       | Policy and Procedures      |           |          |          |
+-------+----------------------------+-----------+----------+----------+
| CM-2  | Baseline Configuration     | CM-2      | CM-2 (1) | CM-2 (1) |
|       |                            |           | (2)      | (2)      |
+-------+----------------------------+-----------+----------+----------+
| CM-3  | Configuration Change       | Not       | CM-3     | CM-3 (1) |
|       | Control                    | Selected  |          |          |
+-------+----------------------------+-----------+----------+----------+
| CM-4  | Monitoring Configuration   | Not       | CM-4     | CM-4     |
|       | Changes                    | Selected  |          |          |
+-------+----------------------------+-----------+----------+----------+
| CM-5  | Access Restrictions for    | Not       | CM-5     | CM-5 (1) |
|       | Change                     | Selected  |          |          |
+-------+----------------------------+-----------+----------+----------+
| CM-6  | Configuration Settings     | CM-6      | CM-6 (1) | CM-6 (1) |
+-------+----------------------------+-----------+----------+----------+
| CM-7  | Least Functionality        | Not       | CM-7 (1) | CM-7 (1) |
|       |                            | Selected  |          |          |
+-------+----------------------------+-----------+----------+----------+
| CM-8  | Information System         | CM-8      | CM-8 (1) | CM-8 (1) |
|       | Component Inventory        |           |          | (2)      |
+-------+----------------------------+-----------+----------+----------+

[]{#__RefHeading___Toc193514798 .anchor}Table 26: Configuration
Management Controls

## CM-1 -- Configuration Management Policy and Procedures

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, configuration management policy that addresses
    purpose, scope, roles, responsibilities, management commitment,
    coordination among organizational entities, and compliance; and

2.  Formal, documented procedure to facilitate the implementation of the
    configuration management policy and associated configuration
    management controls.

## CM-2 -- Baseline Configuration

#### Applicability:

All Information Systems

#### 

#### Policy Statement:

Bureaus and offices shall:

1.  Document and maintain a current baseline configuration of all
    information systems, an inventory of all system's constituent
    components, and relevant ownership information; and

2.  Comply with the requirements specified under CA-1, *C&A
    Implementation Methodology*, regarding implementation of baseline
    security configurations based on the NIST SP 800-53 controls,
    applicable Security Technical Implementation Guides (STIGs), and
    associated requirements specified within this policy handbook for
    all major operating systems, database systems, web-based systems,
    applications, and other types of configurable network devices and IT
    resources.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall update the         X              X
  baseline configuration of information systems as                  
  an integral part of information system component                  
  installations.                                                    

  \(2\) Bureaus and offices shall employ automated   X              X
  mechanisms to maintain an up-to-date, complete,                   
  accurate, and readily available baseline                          
  configuration of the information system.                          
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514799 .anchor}Table 27: CM-2 -- Baseline
Configuration Mandatory Policy Enhancement(s)

### CM-2 C&A Boundary Inventory Management

All bureaus and offices must track all IT system components and security
status by maintaining a comprehensive inventory in the DOI Enterprise
Architecture Repository (DEAR).

Maintaining the security status includes updating C&A documentation
dates, operational status and annual security activity dates. In
addition, bureaus and offices should provide interim updates when
systems are added to or removed from the inventory, and at least monthly
(by the 15^th^ of the month) when undergoing significant changes to
inventory data that affects the security profile or posture for the C&A
boundary.

## CM-3 -- Configuration Change Control 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall authorize, document, and control changes to
Moderate and High-impact information systems.

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall employ          |          | X      |
| automated mechanisms to:                        |          |        |
|                                                 |          |        |
| > \(i\) document proposed changes to the        |          |        |
| > information system;                           |          |        |
| >                                               |          |        |
| > \(ii\) notify appropriate approval            |          |        |
| > authorities;                                  |          |        |
| >                                               |          |        |
| > \(iii\) highlight approvals that have not     |          |        |
| > been received in a                            |          |        |
| >                                               |          |        |
| > timely manner;                                |          |        |
| >                                               |          |        |
| > \(iv\) inhibit change until necessary         |          |        |
| > approvals are received;                       |          |        |
| >                                               |          |        |
| > and                                           |          |        |
| >                                               |          |        |
| > \(v\) document completed changes to the       |          |        |
| > information system.                           |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514800 .anchor}Table 28: CM-3 -- Configuration
Change Control Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CM-3(a)

Bureaus and offices shall include emergency changes in the configuration
change control process, including changes resulting from the remediation
of flaws.

CM-3(b)

Bureaus and offices shall ensure that approvals to implement a change to
information systems include successful results from the security
analysis of the change.

CM-3(c)

Bureaus and offices shall audit activities associated with configuration
changes to the information system.

#### Additional Policy Guidance:

Configuration change control involves the systematic proposal,
justification, implementation, test/evaluation, review, and disposition
of changes to the information system, including upgrades and
modifications. Configuration change control also includes changes to the
configuration settings for information technology products (e.g.,
operating systems, firewalls, routers).

### CM-3 Security Patch Management Program

Bureaus and offices shall have a process in place to identify, track,
and report on security patch management that is consistent with the
methodology described in National Institute of Standards and Technology
Special Publication 800-40, *Procedures for Handling Security Patches*.
The process must address the following requirements for a patch
management program:

1.  Establish a mechanism for ensuring bureau or office accountability
    for patch management. Resources committed to this activity should be
    appropriate to the size and scope of the organization's mission.

2.  Each bureau or office should centralize and coordinate patch
    management leadership within their respective environment, to assure
    that suitable attention is given in a timely way to patches for all
    systems, and to minimize duplication of patch management functions
    across the operating unit.

3.  Document operating unit procedures to identify, track, test (as
    appropriate), and disseminate security-related information
    concerning patches.

4.  Ensure compliance with these procedures to guide patch management
    throughout the operating unit.

Additionally, all DOI Bureaus and staff offices will implement a uniform
system of patch management for all IT systems, devices and appliances,
regardless of operating system or platform for their environment. This
approach will consist of clearly assigned specific responsibilities for
the SA(s) or other authorized personnel. All authorized personnel must
be trained in system administration to include patch management
techniques. Patch management will be used in conjunction with the normal
Departmental and Bureau vulnerability scanning efforts. DOI bureaus and
offices will use the Technical Reference Model (TRM) for approved
automated patch management software. Bureaus and offices will certify
that system patches have been applied and this certification will be
completed monthly by each BCISO and reported to CSD.

Patches will be tested on non-production systems prior to installation
on all production systems. In addition, each Bureau will create and
maintain an organizational hardware and software inventory and an
electronic database of information on patches required and deployed on
the systems or applications for the purposes of proper internal controls
and reporting to external entities (DHS, GAO, OMB, etc) within
constrained timeframes. OCIO reserves the right to review for compliance
in patch management and vulnerability correction.

#### PROCEDURES

Each Bureau is required to establish a patch management program in the
most efficient and effective way possible given their need. It is
recommended that each Bureau designate a Patch Management Officer.
However, the following duties and responsibilities may be delegated to
the SA(s) or other authorized personnel:

##### Create and Maintain an Organizational Hardware and Software Inventory to include a Patch Management Database.

The SA or other authorized personnel will create/maintain a database
containing:

1.  The hardware equipment and software packages;

2.  Version numbers of those packages within the organization;

3.  Patches that apply to this equipment and patch status.

Most automated patch management programs provide this capability and are
preferred over manual patch solutions.

This database should be directly linked to the baseline
hardware/software inventory that is utilized in the Bureau Configuration
Management (CM) Plan. This database will enable the SA or other
authorized personnel to monitor for information about vulnerabilities
and patches that correspond to the hardware and software within the
inventory.

Specific attention should be given to those software packages that are
used on important servers or that are used by a large number of systems.
This includes any government connected resources and any external
resources that are used for official DOI business.

Once the organizational database has been created, it will be necessary
to maintain this tool in a timely manner when a system is installed or
upgraded. Post-patch distribution updates to the database/Configuration
Management Plan will be executed immediately following any patching
exercise.

##### Identify Newly Discovered Vulnerabilities and Security Patches. 

The SA or other authorized personnel are responsible for proactively
monitoring security sources for vulnerabilities and patches that
correspond to the software within the organizational hardware and
software inventory. A variety of sources should be monitored to ensure
that they are aware of all the newly discovered vulnerabilities
including security alerts, notices and advisories from DOI-CIRC,
US-CERT[^8] (including monitoring information provided through the
G-FIRST Portal[^9]), and the NIST Computer Security Resource Center
(CSRC) NIST National Vulnerability Database (NVD[^10]) website.

When a vulnerability has no satisfactory patch, the SA will present
alternative risk mitigation approaches to IT management and support the
management decision by testing, documenting, and coordination
implementation with the appropriate system or network administrators.\
\
Most automated solutions will perform the bulk of this requirement; any
devices not covered by the automated system will be recorded manually in
the database or Configuration Management Plan.

##### Prioritize Patch Application 

The SA or other authorized personnel should be aware of the resource
constraints of local administrators and should attempt to avoid
overwhelming them (when possible) with a large number of patches. The SA
or other authorized personnel must prioritize the set of known patches
and provide advice to local administrators on the criticality of each
patch.\
\
The criticality of a patch is a risk-based decision utilizing standard
elements such as Probability and Consequence. In today's environment
consideration of consequences usually extends beyond a system's logical
boundaries and will require a broader approach in weighing this factor.\
\
Operating System (OS) Patches deemed critical by the software vendor
will always be considered critical by DOI. A distinction must be made
between servers and end-user systems when making patching
recommendations because often it is more important to patch servers
before end-user systems.\
\
Care should be taken to ensure that the automatic patch distribution
solution targets the correct machines.

1.  **[Patches deemed Critical will be tested and installed on
    applicable systems within 3 calendar days of general release from
    the vendor.]{.underline}**

2.  **[Patches deemed High will be tested and installed on applicable
    systems within 7 calendar days of general release from the
    vendor.]{.underline}**

3.  **[Patches deemed Moderate will be tested and installed on
    applicable systems within 14 calendar days of general release from
    the vendor.]{.underline}**

4.  **[Patches deemed Low will be tested and installed on applicable
    systems within 28 calendar days of general release from the vendor.\
    ]{.underline}**\
    Engineering patches (patches not in general release) should be
    avoided unless the criticality is deemed extremely high by the
    Bureau or Department CISO and the general availability release date
    poses a significant risk to the target systems.

##### Conduct Testing of Patches based on priority

If an organization uses standardized host configurations, the SA or
other authorized personnel will be able to test patches on
non-production servers with those configurations. This will avoid the
need for redundant testing by each local administrator. The SA or other
authorized personnel should also work closely with local administrators
to test patches on important servers systems.

##### Distribute Patch and Vulnerability Information to Local Administrators

The SA or other authorized personnel are responsible for informing local
administrators about patches that correspond to software packages
included on the organizational software inventory. Email lists should
provide an effective method for distributing patch information. However,
to decrease the chance of a spoofed email containing a Trojan Horse
patch, actual patches should be distributed from an internal secured
server instead of from the emails themselves. Several email lists may be
maintained that include administrators that are responsible for various
types of systems (e.g., Unix versus Windows administrators).

##### Verify Patch Installation through Network and Host Vulnerability Scanning

The SA or other authorized personnel will probably not have the
resources to verify that every patch has been installed on every machine
unless a commercial Patch Management solution is implemented. Most
automated patch software provides reports on patch installation and how
they were applied to the target system. However, the SA or other
authorized personnel should perform monthly network and host
vulnerability scanning to identify systems that have not been patched as
required.\
\
Many commercial patching packages provide a linkage or seamless
integration with existing vulnerability scanners. Whenever possible,
patch management vulnerability scanning and configuration management
should be tightly integrated. Immediate Scans are required for critical
system patches.\
\
Scanning results will provide the SA or other authorized personnel with
another data source for new vulnerabilities and patches. However,
agencies should be aware that network and host vulnerability scanners do
not check for every known vulnerability and thus cannot be relied on as
a sole source of vulnerability information. The SA or other authorized
personnel should inform local administrators that they are performing
such monthly or immediate scanning because it will make the
administrators more accountable to install each patch. NIST Special
Publication 800-42, Guidelines on Network Security Testing, offers
advice on techniques for vulnerability scanning.

##### Identify Patches and Vulnerabilities Associated with Software On Local Systems.

As previously mentioned, the organizational software inventory and patch
database may not contain all software used by a local Bureau. Patches
and vulnerabilities that cannot be updated using the automated patch
management solution should be documented on the appropriate system-level
POA&M with reasonable aggressive milestone plans and schedules to
resolve the weakness.\
\
Most automated patch packages will permit agencies to build a custom
package to deploy packages for in-house software applications and have
the capability to provide a post-implementation snapshot for reporting
patching levels throughout the target infrastructure.\
\
These snapshots should be an important part of the system's
configuration management plan and be easily incorporated into any
consolidated reporting to the department or other stakeholders. All
patches applied or vulnerabilities identified will require correction
and testing in accordance with the procedures outlined above.

## CM-4 -- Monitoring Configuration Changes

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall monitor changes to Moderate and High-impact
information systems conducting security impact analyses to determine the
effects of the changes.

#### Policy Supplement(s):

CM-4(a)

Prior to change implementation, and as part of the change approval
process, bureaus and offices shall analyze changes to information
systems for potential security impacts.

CM-4(b)

After the information system is changed (including upgrades and
modifications), bureaus and offices shall check the security features to
verify that the features are still functioning properly.

CM-4(c)

Bureaus and offices shall audit activities associated with configuration
changes to information systems.

## CM-5 -- Access Restrictions for Change 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Approve individual access privileges and enforce physical and
    logical access restrictions associated with changes to Moderate and
    High-impact information systems; and

2.  Generate, retain, and review records reflecting all such changes.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated                  X
  mechanisms to enforce access restrictions and                     
  support auditing of the enforcement actions.                      
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514801 .anchor}Table 29: CM-5 -- Access
Restrictions for Change Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CM-5(a)

Bureaus and offices shall ensure that only qualified and authorized
individuals obtain access to information system components for purposes
of initiating changes, including upgrades, and modifications.

## CM-6 -- Configuration Settings

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Establish mandatory configuration settings for information
    technology products employed within all information systems;

2.  Configure the security settings of information technology products
    to the most restrictive mode consistent with operational
    requirements;

3.  Document the configuration settings; and

4.  Enforce the configuration settings in all components of information
    systems.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to centrally manage, apply, and verify                 
  configuration settings.                                           
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514802 .anchor}Table 30: CM-6 -- Configuration
Settings Mandatory Policy Enhancement(s)

### CM-6 Secure System Configurations

Bureaus and offices shall:

1.  Ensure that System Owners document the selected configuration
    baseline as part of the IT system Configuration Management
    Plan/Change Management Plan; and

2.  Implement as a minimum security configuration standard the
    requirements specified under CA-1, *C&A Implementation Methodology*,
    regarding implementation of baseline security configurations based
    on the NIST SP 800-53 controls, applicable Security Technical
    Implementation Guides (STIGs), and associated requirements specified
    within this policy handbook for all major operating systems,
    database systems, web-based systems, applications, and other types
    of configurable network devices and IT resources.

## CM-7 -- Least Functionality

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall configure Moderate and High-impact information
systems to provide only essential capabilities and specifically prohibit
and/or restrict the use of the following functions, ports, protocols,
and/or services:

-   All Unencrypted Network Transactions used for authentication or for
    any sensitive agency information

-   Telnet

-   FTP (Unless Approved by OCIO)

#### 

#### 

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall review information X              X
  systems to identify and eliminate unnecessary                     
  functions, ports, protocols, and/or services on a                 
  monthly basis, in conjunction with monthly                        
  vulnerability scanning.                                           
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514803 .anchor}Table 31: CM-7 -- Least
Functionality Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CM-7(a)

Bureaus and offices shall carefully review the functions and services
provided by information systems, or individual components of information
systems to determine which functions and services are candidates for
elimination (e.g., Voice Over Internet Protocol, Instant Messaging, File
Transfer Protocol, Hyper Text Transfer Protocol, file sharing).

## CM-8 -- Information System Component Inventory

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop, document, and maintain a current
inventory of the components of all information systems and relevant
ownership information.

#### Mandatory Policy Enhancement(s):

  ---------------------------------------------------------------------------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   
  -------------------------------------------------- -------------- ---------
                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall update the         X              X
  inventory of information system components as an                  
  integral part of component installations.                         

  \(2\) Bureaus and offices shall employ automated                  X
  mechanisms to maintain an up-to-date, complete,                   
  accurate, and readily available inventory of                      
  information system components.                                    
  ---------------------------------------------------------------------------

[]{#__RefHeading___Toc193514804 .anchor}Table 32: CM-8 -- Information
System Component Inventory Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CM-8(a)

The inventory of information system components shall include any
information determined to be necessary by the bureau or office to
achieve effective property accountability (e.g., manufacturer, model
number, serial number, software license information, system/component
owner).

CM-8(b)

Bureaus and offices shall ensure that the component inventory is
consistent with the accreditation boundary of the information system.

#  

# Contingency Planning (CP)

Contingency Planning details the necessary procedures required to
protect the continuing performance of core business functions and
services, including IT services, during an outage. Bureaus and offices
shall comply with the NIST Special Publication 800-53, Rev.1,
*Recommended Security Controls for Federal Information Systems,*
contingency planning controls listed in the following table:

  ------------- -------------------- ------------- --------------- --------------
  Contingency                                                      
  Planning                                                         

  Control       Control Name         Control                       
  Number                             Baselines                     

                                     Low           Moderate        High

  CP-1          Contingency Planning CP-1          CP-1            CP-1
                Policy and                                         
                Procedures                                         

  CP-2          Contingency Plan     CP-2          CP-2 (1)        CP-2 (1) (2)

  CP-3          Contingency Training CP-3          CP-3            CP-3 (1)

  CP-4          Contingency Plan     CP-4          CP-4 (1)        CP-4 (1) (2)
                Testing and                                        
                Exercises                                          

  CP-5          Contingency Plan     CP-5          CP-5            CP-5
                Update                                             

  CP-6          Alternate Storage    Not Selected  CP-6 (1) (3)    CP-6 (1) (2)
                Site                                               (3)

  CP-7          Alternate Processing Not Selected  CP-7 (1) (2)    CP-7 (1) (2)
                Site                               (3)             (3) (4)

  CP-8          Telecommunications   Not Selected  CP-8 (1) (2)    CP-8 (1) (2)
                Services                                           (3) (4)

  CP-9          Information System   CP-9          CP-9 (1) (4)    CP-9 (1) (2)
                Backup                                             (3) (4)

  CP-10         Information System   CP-10         CP-10           CP-10 (1)
                Recovery and                                       
                Reconstitution                                     
  ------------- -------------------- ------------- --------------- --------------

[]{#__RefHeading___Toc193514805 .anchor}Table 33: Contingency Planning
Controls

## CP-1 -- Contingency Planning Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, contingency planning policy that addresses
    purpose, scope, roles, responsibilities, management commitment,
    coordination among organizational entities, and compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the contingency planning policy and associated contingency planning
    controls.

### CP-1 Minimum Contingency Planning Procedures

Bureaus and offices shall follow the methodology and format for
contingency planning as described in NIST Special Publication 800-34,
*Contingency Planning Guide for Information Technology Systems*. This
process requires that System Owners identify the most critical and
sensitive operations and their supporting computer resources and develop
a documented comprehensive contingency plan for all systems, and test
the plan at least annually.

## CP-2 -- Contingency Plan 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop and implement contingency plans for
all information systems that address contingency roles,
responsibilities, assigned individuals with contact information, and
activities associated with restoring the system after a disruption or
failure. Designated officials within the organization \[System Owners
and Designated Approving/Accrediting Authorities\] shall review and
approve contingency plans and distribute copies of the plan to key
contingency personnel.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall coordinate         X              X
  contingency plan development with organizational                  
  elements responsible for related plans (e.g.,                     
  Business Continuity Plan, Disaster Recovery Plan,                 
  Continuity of Operations Plan, Business Recovery                  
  Plan, Incident Response Plan).                                    

  \(2\) Bureaus and offices shall conduct capacity                  X
  planning so that necessary capacity for                           
  information processing, telecommunications, and                   
  environmental support exists during crisis                        
  situations.                                                       
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514806 .anchor}Table 34: CP-2 -- Contingency
Plan Mandatory Policy Enhancement(s)

## CP-3 -- Contingency Training 

#### Applicability:

All Information Systems

#### 

#### 

#### Policy Statement:

Bureaus and offices shall train personnel in their contingency roles and
responsibilities with respect to all information systems and provide
refresher training at least annually.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall incorporate                       X
  simulated events into contingency training to                     
  facilitate effective response by personnel in                     
  crisis situations.                                                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514807 .anchor}Table 35: CP-3 -- Contingency
Training Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(2\) Bureaus and offices should consider                         X
  employing automated mechanisms to provide a more                  
  thorough and realistic training environment.                      
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514808 .anchor}Table 36: CP-3 -- Contingency
Training Recommended Policy Enhancement(s)

## CP-4 -- Contingency Plan Testing and Exercises

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Tests and/or exercises the contingency plan for information systems
    at least annually using bureau or office developed tests and
    exercises to determine the plan's effectiveness and the
    organization's readiness to execute the plan; and

2.  Review the contingency plan test/exercise results and initiate
    corrective actions.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall coordinate         X              X
  contingency plan testing and/or exercises with                    
  organizational elements responsible for related                   
  plans (e.g., Business Continuity Plan, Disaster                   
  Recovery Plan, Continuity of Operations Plan,                     
  Business Recovery Plan, Incident Response Plan).                  

  \(2\) Bureaus and offices shall test/exercise                     X
  contingency plans at the alternate processing site                
  to familiarize contingency personnel with the                     
  facility and available resources and to evaluate                  
  the site's capabilities to support contingency                    
  operations.                                                       
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514809 .anchor}Table 37: CP-4 -- Contingency
Plan Testing and Exercises Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(3\) Bureaus and offices should consider                         X
  employing automated mechanisms to more thoroughly                 
  and effectively test/exercise the contingency plan                
  by providing more complete coverage of contingency                
  issues, selecting more realistic test/exercise                    
  scenarios and environments, and more effectively                  
  stressing the information system and supported                    
  missions.                                                         
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514810 .anchor}Table 38: CP-4 -- Contingency
Plan Testing and Exercises Recommended Policy Enhancement(s)

#### Policy Supplement(s):

CP-4(a)

Bureaus and offices shall ensure that contingency plan testing and/or
exercises also include a determination of the effects on operations and
assets (e.g., reduction in mission capability) and individuals arising
due to contingency operations in accordance with the plan.

## CP-5 -- Contingency Plan Update 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall review contingency plans for all information
system at least annually and revise plans to address
system/organizational changes or problems encountered during plan
implementation, execution, or testing.

#### Policy Supplement(s):

CP-5(a)

Organizational changes may include changes in mission, functions, or
business processes supported by the information system.

CP-5(b)

Bureaus and offices shall communicate changes to appropriate
organizational elements responsible for related plans (e.g., Business
Continuity Plan, Disaster Recovery Plan, Continuity of Operations Plan,
Business Recovery Plan, and Incident Response Plan).

## CP-6 -- Alternate Storage Site 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall identify alternate storage sites and initiate
necessary agreements to permit the storage of backup information for
Moderate and High-impact information systems.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall identify alternate X              X
  storage sites that are geographically separated                   
  from the primary storage site so as not to be                     
  susceptible to the same hazards.                                  

  \(2\) Bureaus and offices shall ensure that                       X
  alternate storage sites are configured to                         
  facilitate timely and effective recovery                          
  operations.                                                       

  \(3\) Bureaus and offices shall identify potential X              X
  accessibility problems to alternate storage sites                 
  in the event of an area-wide disruption or                        
  disaster and outline explicit mitigation actions.                 
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514811 .anchor}Table 39: CP-6 -- Alternate
Storage Site Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CP-6(a)

Bureaus and offices shall ensure that the frequency of information
system backups and the transfer rate of backup information to the
alternate storage site (if so designated) are consistent with the bureau
or office recovery time objectives and recovery point objectives.

## CP-7 -- Alternate Processing Site

#### Applicability:

Moderate and High Impact Information Systems

#### 

#### 

#### Policy Statement:

Bureaus and offices shall identify alternate processing sites and
initiate necessary agreements to permit the resumption of Moderate and
High-impact information systems operations for critical mission/business
functions within timeframes compliant with the Business Impact Analysis
for the system, but no later than 90 days, when the primary processing
capabilities are unavailable.

#### Mandatory Policy Enhancement(s):

  ---------------------------------------------------------------------------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   
  -------------------------------------------------- -------------- ---------
                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall identify alternate X              X
  processing sites that are geographically separated                
  from the primary processing site so as not to be                  
  susceptible to the same hazards.                                  

  \(2\) Bureaus and offices shall identify potential X              X
  accessibility problems to alternate processing                    
  sites in the event of an area-wide disruption or                  
  disaster and outline explicit mitigation actions.                 

  \(3\) Bureaus and offices shall develop alternate  X              X
  processing site agreements that contain                           
  priority-of-service provisions in accordance with                 
  the bureau or office availability requirements.                   

  \(4\) Bureaus and offices shall ensure that                       X
  alternate processing sites are fully configured so                
  that it is ready to be used as the operational                    
  site supporting a minimum required operational                    
  capability.                                                       
  ---------------------------------------------------------------------------

[]{#__RefHeading___Toc193514812 .anchor}Table 40: CP-7 -- Alternate
Processing Site Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CP-7(a)

Bureaus and offices shall ensure that equipment and supplies required to
resume critical operations within the specified time period are either
available at the alternate sites or contracts are in place to support
delivery to the sites.

CP-7(b)

Bureaus and offices shall ensure that timeframes to resume information
system operations are consistent with bureau or office established
recovery time objectives.

## CP-8 -- Telecommunication Services 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall identify primary and alternate
telecommunications services to support Moderate and High-impact
information systems and initiate necessary agreements to permit the
resumption of system operations for critical mission/business functions
within 90 days when the primary telecommunications capabilities are
unavailable.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall develop primary    X              X
  and alternate telecommunications service                          
  agreements that contain priority-of-service                       
  provisions in accordance with the bureau or office                
  specified availability requirements.                              

  \(2\) Bureaus and offices shall obtain alternate   X              X
  telecommunications services that do not share a                   
  single point of failure with primary                              
  telecommunications services.                                      

  \(3\) Bureaus and offices shall obtain alternate                  X
  telecommunications service providers that are                     
  sufficiently separated from primary service                       
  providers so as not to be susceptible to the same                 
  hazards.                                                          

  \(4\) Bureaus and offices shall require primary                   X
  and alternate telecommunications service providers                
  to have adequate contingency plans.                               
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514813 .anchor}Table 41: CP-8 --
Telecommunication Services Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CP-8(a)

In the event that the primary and/or alternate telecommunications
services are provided by a common carrier, the bureaus and offices shall
request Telecommunications Service Priority (TSP) for all
telecommunications services used for national security emergency
preparedness.

## CP-9 -- Information System Backup

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall conduct backups of user-level and system-level
information (including system state information) contained in all
information systems at least weekly and protect backup information at
the storage location.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall test backup        X              X
  information at least annually to verify media                     
  reliability and information integrity.                            

  \(2\) Bureaus and offices shall selectively use                   X
  backup information in the restoration of                          
  information system functions as part of                           
  contingency plan testing.                                         

  \(3\) Bureaus and offices shall store backup                      X
  copies of the operating system and other critical                 
  information system software at a separate facility                
  or in a fire-rated container that is not                          
  collocated with the operational software.                         

  \(4\) Bureaus and offices shall protect system     X              X
  backup information from unauthorized modification.                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514814 .anchor}Table 42: CP-9 -- Information
System Backup Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

CP-9(a)

The bureau or office established frequency of information system backups
and the transfer rate of backup information to alternate storage sites
(if so designated) shall be consistent with the specified recovery time
objectives and recovery point objectives.

CP-9(b)

Bureaus and offices shall employ appropriate mechanisms (e.g., digital
signatures, cryptographic hashes) to protect the integrity of
information system backups.

## CP-10 -- Information System Recovery and Reconstitution

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall employ mechanisms with supporting procedures
to allow all information systems to be recovered and reconstituted to a
known secure state after a disruption or failure.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall include a full                    X
  recovery and reconstitution of information systems                
  as part of contingency plan testing.                              
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514815 .anchor}Table 43: CP-10 -- Information
System Recovery and Reconstitution Mandatory Policy Enhancement(s)

#### Additional Policy Guidance:

Information system recovery and reconstitution to a known secure state
means that all system parameters (either by default or
organization-established):

1.  are set to secure values;

2.  security-critical patches are reinstalled;

3.  security-related configuration settings are reestablished;

4.  system documentation and operating procedures are available;

5.  application and system software is reinstalled and configured with
    secure settings;

6.  information from the most recent, known secure backups is loaded;
    and

7.  the system is fully tested.

# Identification and Authentication (IA)

Identification and authentication is a technical measure that prevents
unauthorized people (or unauthorized processes) from entering an IT
system. Access control usually requires that the system be able to
identify and differentiate among users. All DOI information systems must
have a means to enforce user accountability in order for system activity
(both authorized and unauthorized) to be traced to a specific user. To
facilitate user accountability, DOI requires that all bureau and office
information systems implement a method of user identification and
authentication. The user identification tells the system who the user
is. The authentication mechanism provides an added level of assurance
that the user really is who they say they are. Authentication consists
of something a user knows (such as a password), something the user has
(such as a token or smart card), or something the user is (such as a
fingerprint). User identification and authentication also can enforce
separation of duties. Bureaus and offices shall comply with the NIST
Special Publication 800-53, Rev.1, *Recommended Security Controls for
Federal Information Systems,* identification and authentication controls
listed in the following table:

+------+-----------------------------+-----------+--------+----------+
|  Id  |                             |           |        |          |
| enti |                             |           |        |          |
| fica |                             |           |        |          |
| tion |                             |           |        |          |
| and  |                             |           |        |          |
| Au   |                             |           |        |          |
| then |                             |           |        |          |
| tica |                             |           |        |          |
| tion |                             |           |        |          |
+------+-----------------------------+-----------+--------+----------+
|      |                             | Control   |        |          |
|      |                             | Baselines |        |          |
| Con  | Control Name                |           |        |          |
| trol |                             |           |        |          |
| Nu   |                             |           |        |          |
| mber |                             |           |        |          |
+------+-----------------------------+-----------+--------+----------+
|      |                             | Low       | Mo     | High     |
|      |                             |           | derate |          |
+------+-----------------------------+-----------+--------+----------+
| IA-1 | Identification and          | IA-1      | IA-1   | IA-1     |
|      | Authentication Policy and   |           |        |          |
|      | Procedures                  |           |        |          |
+------+-----------------------------+-----------+--------+----------+
| IA-2 | User Identification and     | IA-2      | IA-2   | IA-2 (2) |
|      | Authentication              |           | (1)    | (3)      |
+------+-----------------------------+-----------+--------+----------+
| IA-3 | Device Identification and   | Not       | IA-3   | IA-3     |
|      | Authentication              | Selected  |        |          |
+------+-----------------------------+-----------+--------+----------+
| IA-4 | Identifier Management       | IA-4      | IA-4   | IA-4     |
+------+-----------------------------+-----------+--------+----------+
| IA-5 | Authenticator Management    | IA-5      | IA-5   | IA-5     |
+------+-----------------------------+-----------+--------+----------+
| IA-6 | Authenticator Feedback      | IA-6      | IA-6   | IA-6     |
+------+-----------------------------+-----------+--------+----------+
| IA-7 | Cryptographic Module        | IA-7      | IA-7   | IA-7     |
|      | Authentication              |           |        |          |
+------+-----------------------------+-----------+--------+----------+

[]{#__RefHeading___Toc193514816 .anchor}Table 44: Identification and
Authentication Controls

## IA-1 -- Identification and Authentication Policy and Procedures 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, identification and authentication policy that
    addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the identification and authentication policy and associated
    identification and authentication controls.

## IA-2 -- User Identification and Authentication 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems uniquely
identify and authenticate users (or processes acting on behalf of
users). Any DOI system that processes, stores, or transmits sensitive
information and/or PII shall use multi-factor authentication (minimally
two-factor authentication; e.g. a hard token and complex password -- NOT
A {USER ID AND PASSWORD}, OR A {PASSWORD AND ANOTHER PASSWORD}).

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure that        X              
  information systems employ multifactor                            
  authentication for remote system access that is                   
  NIST Special Publication 800-63, level 3 using a                  
  hardware authentication device or level 4                         
  compliant.                                                        

  \(2\) Bureaus and offices shall ensure information                X
  systems employ multifactor authentication for                     
  local system access that is NIST Special                          
  Publication 800-63 level 3 or level 4 compliant.                  

  \(3\) The information system employs multifactor                  X
  authentication for remote system access that is                   
  NIST Special Publication 800-63 level 4 compliant.                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514817 .anchor}Table 45: IA-2 -- User
Identification and Authentication Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

IA-2(a)

Bureaus and offices shall ensure that users are uniquely identified and
authenticated for all accesses other than those accesses explicitly
identified and documented in accordance with policy statement AC-14,
*Permitted Actions without Identification or Authentication*.

IA-2(b)

Authentication of user identities shall be accomplished through the use
of multi-factor authentication via the combination of passwords, tokens,
and biometrics.

IA-2(c)

In addition to identifying and authenticating users at the information
system level (i.e., at system logon), bureaus and offices shall ensure
that identification and authentication mechanisms are employed at the
application level to provide increased information security for the
organization.

### IA-2 Use of PIV Cards

Homeland Security Presidential Directive 12 (HSPD-12), *Policy for a
Common Identification Standard for Federal Employees and Contractors*,
mandates the use of standard identification for use by employees and
contractors. Following this mandate, DOI will be issuing Personal
Identity Verification (PIV) cards to all employees and contractors. PIV
cards contain a PKI certificate that is compliant with FIPS 201-1 and
NIST 800-63 standards. For DOI information systems that require a hard
cryptographic token, or require multi-factor authentication, PIV cards
should be considered before any other hard cryptographic token
mechanism. Use of an alternative hard cryptographic token mechanism
requires approval from the DOI CIO.

### IA-2 User Authentication for E-Government Transactions

All publicly facing, web-based applications that require end user
authentication in order to access DOI services via the Internet must
employ TLS and perform an e-authentication risk assessment (as described
in OMB memorandum M-04-04) in order to determine the level of
authentication assurance required. The web application must employ an
authentication technique this is compliant with the resulting assurance
level (1-4) as defined in NIST Special Publication 800-63. The
e-authentication risk assessment must be included in the Certification &
Accreditation (C&A) package for the application and be updated whenever
the C&A package is updated.

## IA-3 -- Device Identification and Authentication 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems identify and authenticate specific devices before
establishing a connection.

#### Additional Policy Guidance:

Information systems typically use either shared known information (e.g.,
Media Access Control (MAC) or Transmission Control Protocol/Internet
Protocol (TCP/IP) addresses) or an organizational authentication
solution (e.g., IEEE 802.1x and Extensible Authentication Protocol (EAP)
or a Radius server with EAP-Transport Layer Security (TLS)
authentication) to identify and authenticate devices on local and/or
wide area networks.

## 

## IA-4 -- Identifier Management 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall manage user identifiers by performing the
following activities:

1.  Uniquely identifying each user

2.  Verifying the identity of each user;

3.  Receiving authorization to issue a user identifier from an
    appropriate organization official \[direct supervisor or System
    Manager/Owner\]

4.  Issuing the user identifier to the intended party

5.  Disabling the user identifier after no more than ninety (90) days of
    inactivity; and

6.  Archiving audit logs of user identifiers

### IA-4 Identifier Management

Personalized logins are required to be assigned for all employees and
contractors, and each account shall be exclusively assigned to a single
unique individual.

Personalized logins requires that:

1.  All DOI users have at least one regular/normal non-privileged user
    account that shall be used to perform routine non-privileged
    functions.

2.  To the extent practicable, administrator and other privileged
    accounts shall also be personalized, and exclusively assigned to a
    single unique individual.

##### Privileged Accounts

Bureaus and offices must identify and document individuals (include
username or account name) that require privileged accounts, the level of
privileges each account conveys, and if the individual has been assigned
an account for their sole use where the account password is known only
to the assigned individual and no others.

Rationale must be provided if the levels(s) of privilege are beyond
those of a normal/regular user as well as any privileged local
workstation or **AD** group of which the account is a member (e.g., the
specific privileges above those granted to an account that would be a
member of a workstation local ***Users*** group and/or the Active
Directory ***Domain Users*** group)

If account credentials (username and password) are known/accessible by
more than one individual within a bureau or office, the total number of
individuals must be identified that have knowledge/access to those
credentials.

Privileged accounts should be limited and tightly controlled within
bureaus and offices, and only approved where there is a compelling
requirement that outweighs and associated risks.

Privileged accounts should include the least privileges necessary to
perform the assigned individual's responsibilities.

Accounts should be used explicitly for the assigned duties, roles, and
responsibilities for which the account was intended. Individuals
assigned administrator or other privileged accounts should not use those
accounts for performing actions which can be completed using their
assigned normal/regular user account,

Identify and document within System Security Plans all required
privileged account identifiers that are not uniquely assigned to an
individual for their exclusive use that are necessary to configure and
operate a system (e.g., shared accounts, service accounts, enterprise
administrator accounts, and all other privileged accounts, etc.). Do Not
include the account password within the System Security Plan
documentation.

##### Service Accounts

To the extent practicable, assign all service accounts to an
individuals(s) made responsible, via position description or performance
measures, for the management, use, and protection of the authentication
credentials associated with a particular service account.

All service accounts should be assigned to an individual and those
individuals made responsible, via position description or performance
measures, for the management, use, and protection of the authentication
credentials associated with a particular service account.

## IA-5 -- Authenticator Management 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall manage information system authenticators
(e.g., tokens, PKI certificates, biometrics, passwords, key cards) by
performing the following activities:

1.  Defining initial authenticator content

2.  Establishing administrative procedures for initial authenticator
    distribution, for lost/compromised, or damaged authenticators, and
    for revoking authenticators; and

3.  Changing default authenticators upon information system installation

#### 

#### 

#### 

#### Policy Supplement(s):

IA-5(a)

Bureaus and offices shall ensure that DOI users take reasonable measures
to safeguard authenticators including maintaining possession of their
individual authenticators, not loaning or sharing authenticators with
others, and reporting lost or compromised authenticators immediately.

IA-5(b)

For password-based authentication, bureaus and offices shall ensure that
all information systems enforce the use of strong passwords that:

1.  contain eight or more characters

2.  contain a mix of at least three characters from the following
    categories: uppercase, lowercase, numeric and special
    (non-alphanumeric)

3.  are not the same as the user identifier

4.  are not names or words

5.  are not generic (e.g. "admin" or "system")

6.  are not embedded or "hard-coded" into information systems

7.  protect passwords from unauthorized disclosure and modification by
    ensuring that passwords:

    a.  are one-way encrypted for storage and that SNMP passwords use a
        keyed hash where available (e.g. SNMPv2)

    b.  are transmitted over the network in a secure manner

    c.  are not displayed by computer systems when entered

    d.  enforce the following password minimum and maximum lifetime
        restrictions:

        i.  maximum password age is 60 days

    e.  minimum password age is 1 day

    f.  prohibit password reuse for a specified number of generations
        by:

    g.  maintaining a password history of at least 24 passwords

    h.  disallowing scripts that cycle passwords in order to circumvent
        the intent of password life requirements.

IA-5(c)

For PKI-based authentication, bureaus and offices shall ensure that
information systems:

1.  validate certificates by constructing a certification path to an
    accepted trust anchor that is cross-certified with the Federal PKI
    bridge;

2.  establish user control of the corresponding private key; and

3.  map the authenticated identity to the user account.

##  

## IA-6 -- Authentication Feedback 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that information systems obscure
feedback of authentication information during the authentication process
to protect the information from possible exploitation/use by
unauthorized individuals.

#### Policy Supplement(s):

IA-6(a)

Bureaus and offices shall ensure that feedback from all information
systems does not provide information that would allow an unauthorized
user to compromise the authentication mechanism. Displaying asterisks
when a user types in a password, is an example of obscuring feedback of
authentication information.

## IA-7 -- Cryptographic Module Authentication 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure information systems employ
authentication methods that meet the requirements of FIPS 140-2,
Security requirements for Cryptographic Modules (as amended) for
authentication to a cryptographic module.

# Incident Response (IR)

An incident response capability is a mechanism through which an agency's
System Owners and Bureau Chief Information Security Officers are kept
informed of system vulnerability advisories from the US-Computer
Emergency Readiness Team (US-CERT) and from software vendors and other
sources. The capability also ensures tracking and implementation of
corrective actions (e.g., developing filter rules and patching), and
coordinates with responsible incident response capabilities regarding
the handling and reporting of incidents involving systems under the
operating unit's responsibility. An incident response capability may
consist of one or more persons (such as the IT Security Officer or CIO),
who ensure that vulnerability advisories are communicated to System
Owners. Bureaus and offices shall comply with the NIST Special
Publication 800-53, Rev. 1, *Recommended Security Controls for Federal
Information Systems,* incident response controls listed in the following
table:

+------+----------------------------+-----------+-------+------------+
|      |                            |           |       |            |
| Inci |                            |           |       |            |
| dent |                            |           |       |            |
| Resp |                            |           |       |            |
| onse |                            |           |       |            |
+------+----------------------------+-----------+-------+------------+
|      |                            | Control   |       |            |
|      |                            | Baselines |       |            |
| Con  | Control Name               |           |       |            |
| trol |                            |           |       |            |
| Nu   |                            |           |       |            |
| mber |                            |           |       |            |
+------+----------------------------+-----------+-------+------------+
|      |                            | Low       | Mod   | High       |
|      |                            |           | erate |            |
+------+----------------------------+-----------+-------+------------+
| IR-1 | Incident Response Policy   | IR-1      | IR-1  | IR-1       |
|      | and Procedures             |           |       |            |
+------+----------------------------+-----------+-------+------------+
| IR-2 | Incident Response Training | Not       | IR-2  | IR-2 (1)   |
|      |                            | Selected  |       |            |
+------+----------------------------+-----------+-------+------------+
| IR-3 | Incident Response Testing  | Not       | IR-3  | IR-3 (1)   |
|      | and Exercises              | Selected  |       |            |
+------+----------------------------+-----------+-------+------------+
| IR-4 | Incident Handling          | IR-4      | IR-4  | IR-4 (1)   |
|      |                            |           | (1)   |            |
+------+----------------------------+-----------+-------+------------+
| IR-5 | Incident Monitoring        | Not       | IR-5  | IR-5 (1)   |
|      |                            | Selected  |       |            |
+------+----------------------------+-----------+-------+------------+
| IR-6 | Incident Reporting         | IR-6      | IR-6  | IR-6 (1)   |
|      |                            |           | (1)   |            |
+------+----------------------------+-----------+-------+------------+
| IR-7 | Incident Response          | IR-7      | IR-7  | IR-7 (1)   |
|      | Assistance                 |           | (1)   |            |
+------+----------------------------+-----------+-------+------------+

[]{#__RefHeading___Toc193514818 .anchor}Table 46: Incident Response
Controls

## IR-1 -- Incident Response Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, incident response policy that addresses purpose,
    scope, roles, responsibilities, management commitment, coordination
    among organizational entities, and compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the incident response policy and associated incident response
    controls.

### 

### 

### IR-1 Incident Response Capability

All bureau and office ITSP programs regardless of size shall have an
***Incident Response Capability***, All Incident Response programs must
be constructed according to NIST 800-61 guidance, with direct reporting
to the BCISO. Bureaus and offices shall ensure that all DOI IT systems
are covered by an incident response capability. Also, each bureau or
office that is supported by another entity (another bureau, office or
outside service) must have a written agreement that specifies the
requirement for monitoring, responding, reporting, and preventing
incidents within the bureau or office support boundary.

Bureaus and offices shall ensure the establishment of formal incident
response teams, formally documented procedures and the reporting of
incidents to appropriate authorities in a timely and consistent manner.
Bureaus and offices shall ensure that the formally documented procedures
are effectively communicated to all employees and contractors, including
who to contact in the event of an incident. The incident response
capability *may* adopt one of several models described in National
Institute of Standards and Technology (NIST) Special Publication 800-61,
*Computer Security Incident Handling Guide*. The capability's success
depends on the communication to, as well as participation and
cooperation of, all individuals throughout the agency to be watchful for
adverse events that may indicate attempted or successful system
compromise.

Each of the DOI incident response capabilities must report incidents
directly to the DOI-CIRC and/or US-CERT. Possible losses of agency
sensitive or PII data must be reported to DOI-CIRC within 1 hour of
discovery of potential loss; DOI-CIRC has the agency obligation to
report such incidences to US-CERT within one hour of disclosure.

For incidents pertaining to national security systems, responsible
incident response personnel must follow the methodology defined by the
National Security Telecommunications and Information System Policy
(NSTISSP) No. 5, *National Policy for Incident Response and
Vulnerability Reporting for National Security Systems*, and Directive
(NSTISSD) No. 503, *Incident Response and Vulnerability Reporting for
National Security Systems.*

## IR-2 -- Incident Response Training

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall train personnel in their incident response
roles and responsibilities with respect to all information systems and
provide refresher training, at least annually.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall incorporate                       X
  simulated events into incident response training                  
  to facilitate effective response by personnel in                  
  crisis situations.                                                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514819 .anchor}Table 47: IR-2 -- Incident
Response Training Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(2\) Bureaus and offices should consider                         X
  employing automated mechanisms to provide a more                  
  thorough and realistic training environment.                      
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514820 .anchor}Table 48: IR-2 -- Incident
Response Training Recommended Policy Enhancement(s)

## IR-3 -- Incident Response Testing and Exercises

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall test and/or exercise the incident response
capability for all information systems at least annually using tests and
exercises defined in their procedures to determine the incident response
effectiveness and document the results.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated                  X
  mechanisms to more thoroughly and effectively                     
  test/exercise the incident response capability by                 
  providing more complete coverage of incident                      
  response issues, selecting more realistic                         
  test/exercise scenarios and environments, and more                
  effectively stressing the response capability.                    
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514821 .anchor}Table 49: IR-3 -- Incident
Response Testing and Exercises Mandatory Policy Enhancement(s)

## IR-4 -- Incident Handling 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall implement an incident handling capability for
security incidents that includes preparation, detection and analysis,
containment, eradication, and recovery.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to support the incident handling                       
  process.                                                          
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514822 .anchor}Table 50: IR-4 -- Incident
Handling Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

IR-4(a)

Bureaus and offices shall incorporate the lessons learned from ongoing
incident handling activities into the incident response procedures and
implement the procedures accordingly.

## IR-5 -- Incident Monitoring 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus shall track and document Moderate and High-impact information
system security incidents on an ongoing basis.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) The organization employs automated                          X
  mechanisms to assist in the tracking of security                  
  incidents and in the collection and analysis of                   
  incident information.                                             
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514823 .anchor}Table 51: IR-5 -- Incident
Monitoring Mandatory Policy Enhancement(s)

### IR-5 Monitoring and Detecting Incidents

Bureaus and offices shall ensure that System Owners:

1.  Enable normal logging processes on all host and server systems. In
    addition, they should enable alarm and alert functions on
    HIGH-impact systems, as well as logging of any firewalls and other
    network perimeter security devices and intrusion detection systems;

2.  Have additional monitoring tools or install appropriate software
    wrappers on all HIGH-impact system servers as a supplement to the
    activity logging process provided by the operating system; and

3.  Perform system integrity checks of the firewalls and other network
    access control systems on a routine basis.

4.  SA(s), or responsible incident response capability must, on a
    routine basis and as warranted by the impact level of the system:

5.  Review audit logs from the perimeter security intrusion detection
    systems;

6.  Review audit logs for servers and hosts on the internal, protected
    network;

7.  Review all trouble reports received by system administration
    personnel for symptoms that might indicate intrusive activity;
    suspicious symptoms should be reported to Network or IT security
    personnel; and

8.  Check host-based intrusion detection tools.

## IR-6 -- Incident Reporting 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure prompt reporting of all incidents and
related information to DOI-CIRC.

Bureaus and offices shall ensure prompt reporting of all incidents and
related information to the Office of Inspector General's Computer Crimes
Unit in accordance with the requirements set forth below.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated   X              X
  mechanisms to assist in the reporting of security                 
  incidents.                                                        
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514824 .anchor}Table 52: IR-6 -- Incident
Reporting Mandatory Policy Enhancement(s)

### IR-6 Reporting Incidents to Law Enforcement

One reason that many security-related incidents do not result in
convictions is that organizations do not properly contact law
enforcement. Within Interior, the Office of Inspector General (OIG) is
responsible for evaluating reported IT security incidents for
determination of investigative merit and follow-up action. Normally,
these types of IT security incidents involve waste, fraud, abuse, and/or
all serious computer hacker and virus incidents that significantly
impact on Departmental and/or bureaus and offices information systems.

Although several levels of law enforcement are available to investigate
incidents: Federal investigatory agencies (e.g., the Federal Bureau of
Investigation (FBI) and the U.S. Secret Service), district attorney
offices, state law enforcement, and local (e.g., county) law
enforcement, the OIG's Computer Crimes Unit must be contacted first by
all bureaus and offices when appropriate. In addition to contacting the
OIG by phone, bureaus and offices should select the "Law Enforcement
Assistance Needed" box in the DOI-CIRC incident reporting portal on the
incident report. This will result in an automated email notification
being generated and transmitted to the appropriate staff within the
OIG's Computer Crimes Unit. Bureau and office incident response teams
should become acquainted with the OIG's Computer Crimes Unit law
enforcement representatives before an incident occurs to further discuss
conditions under which incidents should be reported to them, how the
reporting should be performed, what evidence should be collected, and
how it should be collected.

The OIG's Computer Crimes Unit should be contacted through designated
individuals within each bureau and office in a manner consistent with
the requirements of the law and the organization's procedures. Many
organizations prefer to appoint one incident response team member as the
primary POC with law enforcement. This person should be familiar with
the reporting procedures for all relevant law enforcement agencies and
well prepared to recommend which agency, if any, should be contacted
after first consulting with the OIG's Computer Crimes Unit. Note that
the organization typically should not contact multiple agencies because
doing so might result in jurisdictional conflicts. The incident response
team should understand what the potential jurisdictional issues are
(e.g., physical location---an organization based in one state has a
server located in a second state attacked from a system in a third
state, being used remotely by an attacker in a fourth state).

### IR-6 Adverse Event or Reportable Incident

NIST Special Publication 800-61 defines a *reportable* *computer
incident* within the federal government as a violation or imminent
threat of violation of computer security policies, acceptable use
policies, or standard computer security practices. In order to clearly
communicate incidents throughout the federal government and supported
organizations it is necessary for the responsible incident response
capability to adopt a common set of terms and relationships between
those terms.

An *event* is any observable occurrence in a system or network. Events
include a user connecting to a file share, a server receiving a request
for a Web page, a user sending electronic mail (e-mail), and a firewall
blocking a connection attempt.

*Adverse events* are events with a negative consequence, such as system
crashes, network packet floods, unauthorized use of system privileges,
defacement of a Web page, and execution of malicious code that destroys
data. This section of policy addresses only adverse events that
constitute reportable incidents that are computer security-related and
excludes adverse events caused by sources such as natural disasters and
power failure, which are addressed in the Contingency Planning section
of this policy.

### IR-6 Incident Reporting Event Categories 

A computer incident within the federal government as defined by NIST
Special Publication 800-61 is a violation or imminent threat of
violation of computer security policies, acceptable use policies, or
standard computer security practices. In order to clearly communicate
incidents and events (any observable occurrence in a network or system)
throughout the Federal Government and supported organizations it is
necessary for the government incident response teams to adopt a common
set of terms and relationships between those terms. US-CERT requires
that all elements of the federal government are to utilize a common
taxonomy for naming and categorizing incidents. The taxonomy does not
replace discipline (technical, operational, intelligence) that needs to
occur to defend federal agency computers/networks, but provides a common
platform to support US-CERT in the execution of their assigned mission.
In certain instances incident categories will contain sub-categories to
enable further granularity in reporting. For example, Category 3;
malicious code will further break into sub-groups to identify and
include viruses, worms, botnets and spyware. Further, Category 5; Scans,
Probes, and Attempted Access will include the ability to specify network
scans, phishing attempts, and pharming attempts. Bureaus and offices are
to utilize the following incident and event categories and reporting
timeframe criteria as the federal agency reporting taxonomy.

Reportable incidents fall into seven (7) categories designated by the
US-CERT and must be reported by bureaus and offices to DOI-CIRC, and
subsequently by DOI-CIRC to US-CERT, in accordance with the following
table:

+-----------+------------------+---------------------+-----------------+
| CATEGORY  | NAME             | DESCRIPTION         | REPORTING       |
|           |                  |                     | TIMEFRAME       |
+===========+==================+=====================+=================+
| CAT 0     | Exercise/Network | This category is    | Not Applicable; |
|           | Defense Testing  | used during state,  | this category   |
|           |                  | federal, national,  | is for each     |
|           |                  | international       | agency's        |
|           |                  | exercises and       | internal use    |
|           |                  | approved activity   | during          |
|           |                  | testing of          | exercises.      |
|           |                  | internal/external   |                 |
|           |                  | network defenses or |                 |
|           |                  | responses.          |                 |
+-----------+------------------+---------------------+-----------------+
| CAT 1     | \*Unauthorized   | In this category an | Within one (1)  |
|           | Access           | individual gains    | hour of         |
|           |                  | logical or physical | disco           |
|           |                  | access without      | very/detection. |
|           |                  | permission to a     |                 |
|           |                  | federal agency      |                 |
|           |                  | network, system,    |                 |
|           |                  | application, data,  |                 |
|           |                  | or other resource   |                 |
+-----------+------------------+---------------------+-----------------+
| CAT 2     | \*Denial of      | An attack that      | Within two (2)  |
|           | Service (DoS)    | *successfully*      | hours of        |
|           |                  | prevents or impairs | disc            |
|           |                  | the normal          | overy/detection |
|           |                  | authorized          | if the          |
|           |                  | functionality of    | successful      |
|           |                  | networks, systems   | attack is still |
|           |                  | or applications by  | ongoing and the |
|           |                  | exhausting          | agency is       |
|           |                  | resources. This     | unable to       |
|           |                  | activity includes   | successfully    |
|           |                  | being the victim or | mitigate        |
|           |                  | participating in    | activity.       |
|           |                  | the DoS.            |                 |
+-----------+------------------+---------------------+-----------------+
| CAT 3     | \*Malicious Code | *Successful*        | Daily           |
|           |                  | installation of     |                 |
|           |                  | malicious software  | Note: Within    |
|           |                  | (i.e. virus, worm,  | one (1) hour of |
|           |                  | spyware, bots,      | disc            |
|           |                  | Trojan horse, or    | overy/detection |
|           |                  | other code-based    | *if* widespread |
|           |                  | malicious entity    | across agency.  |
|           |                  | that affects an     |                 |
|           |                  | operating system or |                 |
|           |                  | application.        |                 |
|           |                  | Agencies are NOT    |                 |
|           |                  | required to report  |                 |
|           |                  | malicious logic     |                 |
|           |                  | that has been       |                 |
|           |                  | *successfully       |                 |
|           |                  | quarantined* by     |                 |
|           |                  | antivirus (AV)      |                 |
|           |                  | software.           |                 |
+-----------+------------------+---------------------+-----------------+
| CAT 4     | \*Improper       | A person violates   | Weekly          |
|           | (Inappropriate)  | acceptable          |                 |
|           | Usage            | computing use       |                 |
|           |                  | policies            |                 |
+-----------+------------------+---------------------+-----------------+
| CAT 5     | Scans/           | This category       | Monthly         |
|           | Probes/Attempted | includes an         |                 |
|           | Access           | activity that seeks | Note: If system |
|           |                  | to access or        | is classified,  |
|           |                  | identify a federal  | report within   |
|           |                  | agency computer,    | one (1) hour of |
|           |                  | open ports,         | discovery.      |
|           |                  | protocols, service, |                 |
|           |                  | or any combination  |                 |
|           |                  | for later exploit.  |                 |
|           |                  | This activity does  |                 |
|           |                  | not directly result |                 |
|           |                  | in a compromise or  |                 |
|           |                  | denial of service.  |                 |
+-----------+------------------+---------------------+-----------------+
| CAT 6     | Investigation    | *Unconfirmed*       | Not Applicable; |
|           |                  | incidents that are  | this category   |
|           |                  | potentially         | is for each     |
|           |                  | malicious or        | agency's use to |
|           |                  | anomalous activity  | categorize a    |
|           |                  | deemed by the       | potential       |
|           |                  | reporting entity to | incident that   |
|           |                  | warrant further     | is currently    |
|           |                  | review.             | being           |
|           |                  |                     | investigated.   |
+-----------+------------------+---------------------+-----------------+

[]{#__RefHeading___Toc193514825 .anchor}Table 53: Federal Agency
Incident Categories -- Defined by NIST Special Publication 800-61

**\* Any incident, whether suspected or confirmed, that potentially
involves personally identifiable information (PII) must be reported to
US-CERT within 1 hour of detection regardless of the incident category
reporting timeframe.**

### IR-6 Incident Prioritization

Prioritizing the handling of the incident is perhaps the most critical
decision point in the incident handling process. Incidents should not be
handled on a first-come, first-served basis as a result of resource
limitations. Instead, handling should be prioritized based on two
factors:

-   **Current and Potential Technical Effect of the Incident.** Incident
    handlers should consider not only the current negative technical
    effect of the incident (e.g., unauthorized user-level access to
    data), but also the likely future technical effect of the incident
    if it is not immediately contained (e.g., root compromise). For
    example, a worm spreading among workstations may currently cause a
    minor effect on the agency, but within a few hours the worm traffic
    may cause a major network outage.

-   **Criticality of the Affected Resources.** Resources affected by an
    incident (e.g., firewalls, Web servers, Internet connectivity, user
    workstations, and applications) have different significance to the
    organization. The criticality of a resource is based primarily on
    its data or services, users, trust relationships and
    interdependencies with other resources, and visibility (e.g., a
    public Web server versus an internal department Web server). Many
    organizations have already determined resource criticality through
    their business continuity planning efforts or their Service Level
    Agreements (SLA), which state the maximum time for restoring each
    key resource. When possible, the incident response team should
    acquire and reuse existing valid data on resource criticality.

Combining the criticality of the affected resources and the current and
potential technical effect of the incident determines the business
impact of the incident---for example, root compromise of a user
workstation might result in a minor loss of productivity, whereas
unauthorized user-level access to a public Web server could result in a
major loss of revenue, productivity, access to services, reputation, and
the release of personally identifiable information (PII) (e.g., credit
card numbers, Social Security numbers). The team should prioritize the
response to each incident based on its estimate of the business impact
caused by the incident. For example, inappropriate usage incidents that
are not security related typically do not need to be handled as quickly
as other types of incidents because their business impact is relatively
low.

An organization can best quantify the effect of its own incidents
because of its situational awareness. Therefore, bureaus and offices
that report incidents to DOI-CIRC should assign a severity rating to
each incident that reflects its effect on the bureau/office, Interior,
the Federal government, and the national critical infrastructure. Rating
the effect on the critical infrastructure is important because it
enables US-CERT to effectively respond to incidents that are threatening
or affecting the critical infrastructure. To assign a severity rating
for an incident, organizations should first determine the effect ratings
for the incident, based on the following table**.** *[Two ratings need
to be determined for each incident: the current effect and the projected
(potential) effect]{.underline}*.

  --------------------------------------------------------------------------
  VALUE   RATING     DEFINITION
  ------- ---------- -------------------------------------------------------
  0.00    None       No effect on a single bureau/office or agency, multiple
                     bureaus/offices or agencies, or critical infrastructure

  0.10    Minimal    Negligible effect on a single bureau/office or agency

  0.25    Low        Moderate effect on a single bureau/office or agency

  0.50    Medium     Severe effect on a single bureau/office or agency, or
                     negligible effect on multiple bureaus/offices or
                     agencies or critical infrastructure

  0.75    High       Moderate effect on a multiple bureaus/offices or
                     agencies or critical infrastructure

  1.00    Critical   Severe effect on a multiple bureaus/offices or agencies
                     or critical infrastructure
  --------------------------------------------------------------------------

[]{#__RefHeading___Toc193514826 .anchor}Table 54: Effect Rating
Definitions -- Defined by NIST Special Publication 800-61

After setting the effect rating, organizations should use the following
table for assigning a c*riticality rating* to the systems involved in
the incident.

  --------------------------------------------------------------------------
  VALUE   RATING     DEFINITION
  ------- ---------- -------------------------------------------------------
  0.10    Minimal    Non-critical system (e.g., employee workstations),
                     systems, or infrastructure

  0.25    Low        System or systems that support a single agency's
                     mission (e.g., DNS servers, domain controllers), but
                     are not mission critical

  0.50    Medium     System or systems that are mission critical (e.g.,
                     payroll system, root DNS server) to a single agency

  0.75    High       System or systems that support multiple agencies or
                     sectors of the critical infrastructure

  1.00    Critical   System or systems that are mission critical to multiple
                     agencies or critical infrastructure
  --------------------------------------------------------------------------

[]{#__RefHeading___Toc193514827 .anchor}Table 55: Criticality Rating
Definitions -- Defined by NIST Special Publication 800-61

To determine the overall severity rating for an incident,
bureaus/offices should use the following formula:

**Overall Severity/Effect Score =** Round (10 \* ((Current Effect Rating
\* .5) + (Projected Effect Rating \* .5) + (System Criticality Rating
\* 1) / 2))

Using the resulting score, bureaus/offices can apply the respective
overall rating to the incident, as shown in the following table.

  -----------------------------------------------------------------------
  SCORE                                            RATING
  ------------------------------------------------ ----------------------
  00.00 -- 00.99                                   None

  01.00 -- 02.49                                   Minimal

  02.50 -- 03.74                                   Low

  03.75 -- 04.99                                   Medium

  05.00 -- 07.49                                   High

  07.50 -- 10.00                                   Critical
  -----------------------------------------------------------------------

[]{#__RefHeading___Toc193514828 .anchor}Table 56: Business Impact Rating

### IR-6 Incident Reporting Format

For incidents involving DOI information systems bureaus and offices
shall use a reporting format consistent with that prescribed by the
US-CERT, the content of which follows, and reporting of all such
incidents to the DOI CIRC. Depending on the criticality it is not always
feasible to gather all the information prior to reporting, but to
continue to report information as it is collected. All personnel
involved with the response must possess the required national security
clearance before responding to an incident involving a national security
system. Reports shall include a description about the incident, as much
of the information listed below as possible, and be marked with the
national security classification or non-national security restricted
access notations as appropriate; however, reporting should not be
delayed in order to gain additional information:

1.  Agency name

2.  Point of Contact Information (name, telephone, email)

3.  Incident Category Type (CAT 1, 2, 3, 4, 5, or 6)\*

4.  Incident date/time (time zone)

5.  Source IP, Port, Protocol

6.  Destination IP, Port, Protocol

7.  Operating System and version, patch, etc.

8.  System Function (DNS/Web server, workstation, etc)

9.  Antivirus software installed, version, latest update

10. Location of the system(s) involved in the incident (Washington DC,
    Los Angeles, CA)

11. How was the incident identified (IDS, audit log analysis, system
    administrator)

12. Impact to agency

13. Resolution

\* **Multiple Component**: Because a single incident may encompass two
or more incident categories, a team should categorize incidents by the
transmission mechanism. For example:

-   A virus that creates a backdoor should be handled as a malicious
    code incident, not an unauthorized access incident, because the
    malicious code was the only transmission mechanism used.

-   A virus that creates a backdoor that has been used to gain
    unauthorized access should be treated as a multiple component
    incident because two transmission mechanisms were used.

Bureaus and offices shall use the following additional standard set of
incident-related data fields to be collected for each incident. This
will not only facilitate more effective and consistent incident
handling, but also assist Interior in meeting applicable incident
reporting requirements. The following is a designated set of basic
fields (e.g., incident reporter's name, phone number and location) to be
collected when the incident is reported and an additional set of fields
to be collected by the incident handlers during their response. The two
sets of fields serve as the basis for the incident reporting database
(i.e., DOI-CIRC Portal). Each bureau and office, and DOI-CIRC, should
augment the fields, as needed, based on several factors, including their
respective incident response team model and structure.

**Basic Data Fields**

-   Contact Information for the Incident Reported and Handler

    -   Name

    -   Organizational unit (e.g., agency, bureau, department, division,
        team)

    -   Email Address

    -   Phone Number

    -   Location (e.g., mailing address, office room number)

-   Incident Details

    -   Date/time (including time zone) when the incident was discovered

    -   Estimated date/time (including time zone) when the incident
        started/occurred

    -   Type of incident (e.g., denial of service, malicious code,
        unauthorized access, inappropriate usage, etc.)

    -   Physical location of the incident (e.g., city, state)

    -   Current status of the incident (e.g., ongoing attack)

    -   Source/cause of the incident (if known), including hostnames and
        IP addresses

    -   Description of the incident (e.g., how it was detected, what
        occurred)

    -   Operating system, version, patch level

    -   Antivirus software installed, enabled, and up-to-date (yes/no)

    -   Description of affected resources (e.g., networks, hosts,
        applications, data), including systems' hostnames, IP addresses,
        and function

    -   Estimated technical impact of the incident (e.g., data deleted,
        system crashed, application unavailable (see section regarding
        Determination of Overall Severity/Effect Rating)

    -   Response actions performed (e.g., shut off host, disconnected
        host from network)

    -   Other organizations contacted (e.g., software vendor)

    -   For lost/stolen equipment, identify the make, model, serial
        number and asset/property tag number of each device

    -   Personally Identifiable Information (PII) potentially involved
        (yes/no)

    -   If yes, identify number of potentially affected individuals and
        indicate whether actual or estimated

    -   Specify the type of PII involved and specify as either potential
        or actual

    -   Other forms of sensitive agency information potentially involved
        (yes/no)

    -   Specify the type of other sensitive agency information involved
        and specify as either potential or actual

    -   Information encrypted (yes/no)

    -   Description of means of encryption (e.g., FIPS 140-2 compliant
        encryption (yes/no), name of product/solution/technology used to
        encrypt the information, decryption method (e.g., shared secret
        password and specify password complexity and strength used,
        PKI-based public/private key decryption, unapproved MS Word weak
        password protection only, etc.)

    -   General comments

**Incident Handler Data Fields**

-   Current Status of the Incident Response

-   Summary of the Incident

-   Incident Handling actions

    -   Log of actions taken by all handlers

    -   Contact information for all involved parties

    -   List of evidence gathered

-   Incident Handler Comments

-   Cause of the Incident (e.g., misconfigured application, unpatched
    host)

-   Cost of the Incident (see NIST SP 800-61, section 3.4.2)

-   Overall Severity/Effect Score (Business Impact Rating)

-   Business Impact of the Incident (The business impact of the incident
    could either be a description of the incident's effect (e.g.,
    accounting department unable to perform tasks for two days) or an
    impact category based on the cost (e.g., a "major" incident has a
    cost of over \$100,000).

### IR-6 Chain of Custody

DOI-CIRC, DOI Office of Law Enforcement and Security, OIG Computer
Crimes Unit, or other law enforcement authorities, may direct the Bureau
Chief Information Security Officer (BCISO) to secure a system due to
potential compromise and the need for possible forensic examination of
evidence for potential prosecution. Upon OIG request, the BCISO must:

-   Establish a Chain of Custody that documents (in writing) the name,
    title, office, and phone number of each individual having sequential
    possession of the system.

-   Update the Chain of Custody each time the system changes possession
    (e.g., from the BCISO to the OIG, from the OIG to law enforcement,
    from law enforcement back to the BCISO, etc.).

To avoid possible obstruction of justice charges, BCISO's must
coordinate all activities with the proper authorities (e.g., OIG or law
enforcement) until the system is no longer needed as evidence for
pending or ongoing investigations or prosecution.

When cleared for release to service, ensure that all data considered to
be federal records has been saved in accordance with applicable records
management laws and regulations, then follow this policy for media
sanitization and disposal before returning the system to service or
before disposing of the system if no longer operable.

## IR-7 -- Incident Response Assistance 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall provide an incident response support resource
that offers advice and assistance to users of information systems for
the handling and reporting security incidents. The support resource
shall be an integrated part of the bureau or office's incident response
capability.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) The organization employs automated           X              X
  mechanisms to increase the availability of                        
  incident response-related information and support.                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514829 .anchor}Table 57: IR-7 -- Incident
Response Assistance Mandatory Policy Enhancement(s)

#### Additional Policy Guidance:

Possible implementations of incident response support resources in an
organization include a help desk or an assistance group and access to
forensics services, when required.

### IR-7 Additional Incident Response Guidance

The following publications provide guidance on the ongoing process of
establishing an effective CIRC to detect intrusions as well as handle
and report computer incidents.

> Carnegie-Mellon *Handbook for Computer Security Incident Response
> Teams (CSIRT)* - This document describes the components and some
> procedures for establishing a computer security incident response
> team, including the types of activities and qualifications required of
> the team members.

The US-CERT provides assistance to federal agencies in handling
incidents, technical queries, as well as alerts and advisories, and has
a 24-hour incident response center at 1-888-282-0870 (via e-mail at
soc@us-cert.gov).

#  Maintenance (MA)

These are controls used to monitor the installation of, and updates to,
hardware and software to ensure that the system functions as expected
and that a historical record is maintained of changes. The process of
configuration management provides for a controlled environment in which
changes to hardware and software are properly authorized, tested, and
approved before implementation. Bureaus and offices shall comply with
the NIST Special Publication 800-53, Rev.1, *Recommended Security
Controls for Federal Information Systems,* system maintenance controls
listed in the following table:

+--------+------------------------+-----------+---------+-------------+
| Maint  |                        |           |         |             |
| enance |                        |           |         |             |
+--------+------------------------+-----------+---------+-------------+
|        |                        | Control   |         |             |
|        |                        | Baselines |         |             |
| C      | Control Name           |           |         |             |
| ontrol |                        |           |         |             |
| Number |                        |           |         |             |
+--------+------------------------+-----------+---------+-------------+
|        |                        | Low       | M       | High        |
|        |                        |           | oderate |             |
+--------+------------------------+-----------+---------+-------------+
| MA-1   | System Maintenance     | MA-1      | MA-1    | MA-1        |
|        | Policy and Procedures  |           |         |             |
+--------+------------------------+-----------+---------+-------------+
| MA-2   | Controlled Maintenance | MA-2      | MA-2    | MA-2 (1)    |
|        |                        |           | (1)     | (2)         |
+--------+------------------------+-----------+---------+-------------+
| MA-3   | Maintenance Tools      | Not       | MA-3    | MA-3 (1)    |
|        |                        | Selected  |         | (2) (3)     |
+--------+------------------------+-----------+---------+-------------+
| MA-4   | Remote Maintenance     | MA-4      | MA-4(1) | MA-4 (1)    |
|        |                        |           | (2)     | (2) (3)     |
+--------+------------------------+-----------+---------+-------------+
| MA-5   | Maintenance Personnel  | MA-5      | MA-5    | MA-5        |
+--------+------------------------+-----------+---------+-------------+
| MA-6   | Timely Maintenance     | Not       | MA-6    | MA-6        |
|        |                        | Selected  |         |             |
+--------+------------------------+-----------+---------+-------------+

[]{#__RefHeading___Toc193514830 .anchor}Table 58: System Maintenance
Controls

## MA-1 -- System Maintenance Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, information system maintenance policy that
    addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the information system maintenance policy and associated system
    maintenance controls.

## MA-2 -- Controlled Maintenance 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall schedule, perform, document, and review
records of routine preventative and regular maintenance (including
repairs) on the components of all information systems in accordance with
manufacturer or vendor specifications and/or bureau or office
requirements.

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall maintain        | X        | X      |
| maintenance records for information systems     |          |        |
| that include:                                   |          |        |
|                                                 |          |        |
| > \(i\) the date and time of maintenance;       |          |        |
| >                                               |          |        |
| > \(ii\) name of the individual performing the  |          |        |
| > maintenance;                                  |          |        |
| >                                               |          |        |
| > \(iii\) name of escort, if necessary;         |          |        |
| >                                               |          |        |
| > \(iv\) a description of the maintenance       |          |        |
| > performed; and                                |          |        |
| >                                               |          |        |
| > \(v\) a list of equipment removed or replaced |          |        |
| > (including                                    |          |        |
| >                                               |          |        |
| > identification numbers, if applicable).       |          |        |
+-------------------------------------------------+----------+--------+
| \(2\) Bureaus and offices shall employ          |          | X      |
| automated mechanisms to schedule and conduct    |          |        |
| maintenance as required, and to create up-to    |          |        |
| date, accurate, complete, and available records |          |        |
| of all maintenance actions, both needed and     |          |        |
| completed.                                      |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514831 .anchor}Table 59: MA-2 -- Controlled
Maintenance Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

MA-2(a)

All maintenance activities to include routine, scheduled maintenance and
repairs shall be controlled; whether performed on site or remotely and
whether the equipment is serviced on site or removed to another
location.

MA-2(b)

Appropriate officials \[Division/Branch or Office Directors, Program
Mangers or Chief Information Officers\] shall approve the removal of
information systems or information system components from the facility
when repairs are necessary.

MA-2(c)

If the information system or components of the system require off-site
repair, bureaus and offices shall remove all information from associated
media using approved procedures.

MA-2(d)

After maintenance is performed on information systems, bureaus and
offices shall check all potentially impacted security controls to verify
that the controls are still functioning properly.

## MA-3 -- Maintenance Tools 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall approve, control, and monitor the use of
Moderate and High-impact information system maintenance tools and
maintain the tools on an ongoing basis.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall inspect all                       X
  maintenance tools (e.g., diagnostic and test                      
  equipment) carried into a facility by maintenance                 
  personnel for obvious improper modifications.                     

  \(2\) Bureaus and offices shall check all media                   X
  containing diagnostic test programs (e.g.,                        
  software or firmware used for system maintenance                  
  or diagnostics) for malicious code before the                     
  media is used in information systems.                             

  \(3\) Bureaus and offices shall check all                         X
  maintenance equipment with the capability of                      
  retaining information so that no DOI data is                      
  written on the equipment or ensure the equipment                  
  is appropriately sanitized before release; if the                 
  equipment cannot be sanitized, the equipment shall                
  remain within the facility or is destroyed, unless                
  an appropriate official \[Chief Information                       
  Officer\] explicitly authorizes an exception.                     
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514832 .anchor}Table 60: MA-3 -- Maintenance
Tools Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(4\) Bureaus and offices should consider                         X
  employing automated mechanisms to restrict the use                
  of maintenance tools to authorized personnel only.                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514833 .anchor}Table 61: MA-3 -- Maintenance
Tools Recommended Policy Enhancement(s)

#### Additional Policy Guidance:

This requirement is intended to address hardware and software brought
into information systems specifically for diagnostic/repair actions
(e.g., a hardware or software packet sniffer that is introduced for the
purpose of a particular maintenance activity).

This requirement does not address hardware and/or software components
that may support information system maintenance, yet are a part of the
system (e.g., the software implementing "ping", "ls", "ipconfig" or the
hardware and software implementing the monitoring port of an Ethernet
switch).

## MA-4 -- Remote Maintenance 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall authorize, monitor, and control remotely
executed maintenance and diagnostic activities.

#### Mandatory Policy Enhancement(s):

  ------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                          APPLICABLITY   

                                                    MODERATE       HIGH

  \(1\) The organization audits all remote          X              X
  maintenance and diagnostic sessions and                          
  appropriate organizational personnel review the                  
  maintenance records of the remote sessions.                      

  \(2\) The organization addresses the installation X              X
  and use of remote maintenance and diagnostic                     
  links in the security plan for the information                   
  system.                                                          

  \(3\) Bureaus and offices shall not allow remote                 X
  maintenance or diagnostic services to be                         
  performed by a provider that does not implement                  
  for its own information systems, the same level                  
  of security as that implemented on the systems                   
  being serviced, unless the component being                       
  serviced is removed from the information system                  
  and sanitized (with regard to organizational                     
  information) before the service begins and also                  
  sanitized (with regard to potentially malicious                  
  software) after the service is performed and                     
  before being reconnected to the information                      
  system.                                                          
  ------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514834 .anchor}Table 62: MA-4 -- Remote
Maintenance Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

MA-4(a)

Bureaus and offices shall ensure that if remote maintenance and
diagnostic activities are conducted by individuals that communication is
through a controlled network.

MA-4(b)

The use of remote maintenance and diagnostic tools shall be consistent
with Departmental, bureau and office policies and documented in the
security plan for the information system.

MA-4(c)

Bureaus and offices shall maintain records for all remote maintenance
and diagnostic activities.

MA-4(d)

When remote maintenance is completed, bureaus and offices (or
information systems in certain cases) shall terminate all sessions and
remote connections invoked in the performance of that activity.

MA-4(e)

If password-based authentication is used to accomplish remote
maintenance, by external vendors, bureaus and offices shall change the
password following each remote maintenance session.

MA-4(f)

Bureaus and offices shall audit all remote maintenance and diagnostic
sessions and appropriate personnel shall review the maintenance records
of the remote sessions.

MA-4(g)

Bureaus and offices shall address the installation and use of remote
maintenance and diagnostic links in the System Security Plans for the
information systems.

#### Additional Policy Guidance:

Other techniques and/or controls to consider for improving the security
of remote maintenance include encrypting and decrypting communications.

## MA-5 -- Maintenance Personnel

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall only allow authorized personnel to perform
maintenance on all information systems.

#### Policy Supplement(s):

MA-5(a)

Maintenance personnel (whether performing maintenance locally or
remotely) have appropriate access authorizations to the information
system when maintenance activities allow access to organizational
information or could result in a future compromise of confidentiality,
integrity, or availability.

MA-5(b)

When maintenance personnel do not have the needed access authorizations,
bureau or office personnel with appropriate access authorizations shall
supervise maintenance personnel during the performance of maintenance
activities on the information system.

## MA-6 -- Timely Maintenance

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall have the capability to receive maintenance
support and spare parts for bureau defined critical information system
components within the documented bureau or office specified timeframe of
Moderate and High-impact information systems failure.

# Media Protection (MP)

Bureaus and offices shall ensure that IT security programs include
procedures for storing, handling and destroying information media.
Bureaus and offices shall comply with the NIST Special Publication
800-53,Rev. 1, *Recommended Security Controls for Federal Information
Systems,* media protection controls listed in the following table:

+------+-----------------------------+------------+---------+---------+---+
|  M   |                             |            |         |         |   |
| edia |                             |            |         |         |   |
| Pr   |                             |            |         |         |   |
| otec |                             |            |         |         |   |
| tion |                             |            |         |         |   |
+------+-----------------------------+------------+---------+---------+---+
|      |                             | Control    |         |         |   |
|      |                             | Baselines  |         |         |   |
| Con  | Control Name                |            |         |         |   |
| trol |                             |            |         |         |   |
| Nu   |                             |            |         |         |   |
| mber |                             |            |         |         |   |
+------+-----------------------------+------------+---------+---------+---+
|      |                             | Low        | M       | High    |   |
|      |                             |            | oderate |         |   |
+------+-----------------------------+------------+---------+---------+---+
| MP-1 | Media Protection Policy and | MP-1       | MP-1    | MP-1    |   |
|      | Procedures                  |            |         |         |   |
+------+-----------------------------+------------+---------+---------+---+
| MP-2 | Media Access                | MP-2       | MP-2    | MP-2    |   |
|      |                             |            | (1)     | (1)     |   |
+------+-----------------------------+------------+---------+---------+---+
| MP-3 | Media Labeling              | Not        | MP-3    | MP-3    |   |
|      |                             | Selected   |         |         |   |
+------+-----------------------------+------------+---------+---------+---+
| MP-4 | Media Storage               | Not        | MP-4    | MP-4    |   |
|      |                             | Selected   |         |         |   |
+------+-----------------------------+------------+---------+---------+---+
| MP-5 | Media Transport             | Not        | MP-5    | MP-5    |   |
|      |                             | Selected   | (1) (2) | (1) (2) |   |
|      |                             |            | (3)     | (3)     |   |
+------+-----------------------------+------------+---------+---------+---+
| MP-6 | Media Sanitization and      | MP-6       | MP-6    | MP-6    |   |
|      | Disposal                    |            | (1) (2) | (1) (2) |   |
+------+-----------------------------+------------+---------+---------+---+

[]{#__RefHeading___Toc193514835 .anchor}Table 63: Media Protection
Controls

## MP-1 -- Media Protection Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, media protection policy that addresses purpose,
    scope, roles, responsibilities, management commitment, coordination
    among organizational entities, and compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the media protection policy and associated media protection
    controls.

### MP-1 Information Protection Measures

To provide for adequate handling of sensitive DOI information, bureaus
and offices shall ensure that DOI employees:

1.  Accurately categorize and label all electronic files, hard copy
    printouts, and removable media (diskettes and CD-ROMs) containing
    data categorized as information system, U.S. Code Title or Public
    Law protected data, or national security information (confidential,
    secret, top secret, or other designation). See the DOI Security
    Standards, for more guidance on marking of national security and
    sensitive but unclassified information.

2.  Enable [audit logging](#Audit_Trails) and protect the logs.

3.  Assign [security categories](#levels_and_types) commensurate with
    the information to be protected.

4.  Make appropriate use of the following:

    a.  locked media libraries;

    b.  operator instructions for handling tampering or other incidents;

    c.  read-only safeguards;

    d.  least-privilege doctrine for information confidentiality and
        availability; and

    e.  auditing of the safeguards as appropriate.

### MP-1 Electronic Transmission of Sensitive Information 

Electronic transmission of sensitive information is authorized by phone,
fax, or e-mail when necessary for the conduct of official business.
Sensitive information must be encrypted in transmission because there is
no expectation of protection of information sent over an unprotected
network. All DOI personnel must understand that systems such as the
Internet are untrusted, in that transmissions may be monitored,
intercepted, and modified. Information transmitted using untrusted
systems is at risk because there are no assurances that it will not be
exploited to the disadvantage of the government. Methods of electronic
transmission include voice discussions over a public telephone line,
sending documents to or from a non-secure facsimile (fax) machine, or
data transmission using a non-secure computer network (e.g., e-mail).
Users should exercise caution before posting information on the Internet
or using the Internet for official government business.

### MP-1 Protection of Classified or National Security Information 

DOI Departmental Manual, part 442, provides the protection requirements
for the handling and marking of classified national security
information. Sensitive Compartmented Information (SCI) and facilities
must be protected in accordance with Central Intelligence Agency
directives, Number 6 series -- specifically DCID 6/3 and DCID 6/9,
respectively.

## MP-2 -- Media Access

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall restrict access to all information system
media to authorized individuals.

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall employ          | X        | X      |
| automated mechanisms to restrict access to      |          |        |
| media storage areas and to audit access         |          |        |
| attempts and access granted.                    |          |        |
|                                                 |          |        |
| This policy enhancement is primarily applicable |          |        |
| to designated media storage areas within an     |          |        |
| organization where a significant volume of      |          |        |
| media is stored and is not intended to apply to |          |        |
| every location where some media is stored       |          |        |
| (e.g., in individual offices).                  |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514836 .anchor}Table 64: MP-2 -- Media Access
Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

MP-2(a)

Information system media includes both digital media (e.g., diskettes,
magnetic tapes, external/removable hard drives, flash/thumb drives,
compact disks, and digital video disks) and non-digital media (e.g.,
paper, microfilm).

MP-2(b)

This policy also applies to portable and mobile computing and
communications devices with information storage capability (e.g.,
notebook computers, personal digital assistants, cellular telephones).

MP-2(c)

Bureaus and offices shall document in their policies and procedures, the
media requiring restricted access, individuals authorized to access the
media, and the specific measures taken to restrict access.

## MP-3 -- Media Labeling 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall (i) affix external labels to removable
information system media and information system output indicating the
distribution limitations, handling caveats and applicable security
markings (if any) of the information; and (ii) exempt removable
information systems media and information system output from labeling so
long as they remain within controlled areas.

### MP-3 Sensitive but Unclassified (SBU), and For Official Use Only (FOUO) Designations

All DOI information shall be properly marked, handled, stored and
protected from the risk and magnitude of loss or harm that could result
from inadvertent or deliberate disclosure, alteration or destruction.

Sensitive But Unclassified (SBU) information shall be properly marked,
handled, stored and protected from the risk and magnitude of loss or
harm that could result from inadvertent or deliberate disclosure,
alteration or destruction. SBU information also includes Sensitive
Security Information (SSI). However the SBU category contains
information that is not security related but is still sensitive in terms
of its risk of exposure.

For Official Use Only (FOUO) identifies information that is exempt from
mandatory release under the provision of the Freedom of Information Act
(FOIA). For Official Use Only (FOUO) is a document designation, not a
classification. This designation is used to identify information or
material which, although unclassified, may not be appropriate for public
release.

#### Policy Supplement(s):

MP-3(a)

This policy applies to portable and mobile computing and communications
devices with information storage capability (e.g., notebook computers,
personal digital assistants, cellular telephones). Refer to the
***INFORMATION CLASSIFICATION SECURITY STANDARD*** for additional
information.

MP-3(b)

A controlled area is any area or space for which the bureau or office
has confidence that the physical and procedural protections provided are
sufficient to meet the requirements established for protecting the
information and/or information systems.

## MP-4 -- Media Storage 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall physically control and securely store
information system media within controlled areas.

#### Policy Supplement(s):

MP-4(a)

Information system media includes both digital media (e.g., diskettes,
magnetic tapes, external/removable hard drives, flash/thumb drives,
compact disks, and digital video disks) and non-digital media (e.g.,
paper, microfilm).

MP-4(b)

A controlled area is any area or space for which the bureau or office
has confidence that the physical and procedural protections provided are
sufficient to meet the requirements established for protecting the
information and/or information systems.

MP-4(c)

This policy applies to portable and mobile computing and communications
devices with information storage capability (e.g., notebook computers,
personal digital assistants, cellular telephones).

MP-4(d)

Bureaus and offices shall document in their policies and procedures,
media requiring physical protection and the specific measures taken to
afford such protection.

MP-4(e)

Bureaus and offices shall protect identified information system media
until the media are destroyed or sanitized using approved equipment,
techniques, and procedures.

#### Additional Policy Guidance:

Telephone systems are also considered information systems and may have
the capability to store information on internal media (e.g., on
voicemail systems). Since telephone systems do not have, in most cases,
the identification, authentication, and access control mechanisms
typically employed in other information systems, bureaus and offices
should exercise extreme caution in the types of information stored on
telephone voicemail systems.

## MP-5 -- Media Transport 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall protect and control all information system
media during transport outside of controlled areas and restrict the
activities associated with transport of such media to authorized
personnel.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall protect digital    X              X
  and non-digital media during transport outside of                 
  controlled areas using trusted carriers (e.g. USPS                
  using Registered Mail, FED-EX or UPS) that provide                
  positive control of the media.                                    

  \(2\) Bureaus and offices shall document, where    X              X
  appropriate, activities associated with the                       
  transport of information system media using the                   
  trusted carrier's (e.g. USPS using Registered                     
  Mail, FED-EX or UPS) official custody record.                     

  \(3\) Bureaus and offices shall employ an          X              X
  identified custodian at all times to transport                    
  information system media.                                         
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514837 .anchor}Table 65: MP-5 -- Media
Transport Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

MP-5(a)

Bureaus and offices shall employ cryptography to protect sensitive
information residing on digital media during transport outside of
controlled areas.

MP-5(b)

Information system media includes both digital media (e.g., diskettes,
tapes, removable hard drives, flash/thumb drives, compact disks, digital
video disks) and non-digital media (e.g., paper, microfilm).

MP-5(c)

A controlled area is any area or space for which a bureau or offices has
confidence that the physical and procedural protections provided are
sufficient to meet the requirements established for protecting the
information and/or information system.

MP-5(d)

This policy also applies to portable and mobile computing and
communications devices with information storage capability (e.g.,
notebook computers, personal digital assistants, cellular telephones)
that are transported outside of controlled areas.

MP-5(e)

Bureaus and offices shall document in their policies and procedures, any
media requiring protection during transport and the specific measures
taken to protect such transported media.

#### Additional Policy Guidance:

Telephone systems are also considered information systems and may have
the capability to store information on internal media (e.g., on
voicemail systems). Since telephone systems do not have, in most cases,
the identification, authentication, and access control mechanisms
typically employed in other information systems, bureaus and offices
should exercise extreme caution in the types of information stored on
telephone voicemail systems that are transported outside of controlled
areas.

## MP-6 -- Media Sanitization and Disposal

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall sanitize information system media, both
digital and non-digital, prior to disposal or release for reuse.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall track, document,   X              X
  and verify media sanitization and disposal                        
  actions.                                                          

  \(2\) Bureaus and offices shall periodically test  X              X
  sanitization equipment and procedures to verify                   
  correct performance.                                              
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514838 .anchor}Table 66: MP-6 -- Media
Sanitization and Disposal Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

MP-6(a)

Bureau and office media sanitization and disposal procedures shall be in
compliance with NIST Special Publication 800-88, *Guidelines for Media
Sanitization*.

MP-6(b)

Bureaus and offices shall use their discretion on sanitization
techniques and procedures for media containing information deemed to be
in the public domain or publicly releasable, or deemed to have no
adverse impact on the organization or individuals if released for reuse
or disposed.

#### Additional Policy Guidance:

Sanitization is the process used to remove information from information
system media such that there is reasonable assurance, in proportion to
the confidentiality of the information, that the information cannot be
retrieved or reconstructed. Sanitization techniques, including clearing,
purging, and destroying media information, ensure that organizational
information is not disclosed to unauthorized individuals when such media
is reused or disposed.

In DOI, virtually all computers should be considered to potentially
contain sensitive information. Bureaus/Offices will use one of the two
following approaches to remove sensitive data, depending on the level of
sensitivity, when transferring, donating, or disposing computer
equipment.

National Security Information System (NSIS) - That is, any system
processing information classified as Top Secret, Secret, or
Confidential. Storage media for these systems will be dismantled and
destroyed, or degaussed by a National Security Agency approved
degaussing device. Storage media used in NSIS systems will not be
released outside of United States Government classified information
control without the express written permission of the Department\'s
Chief Information Officer and the Director of Managing Risks and Public
Safety.

Managers also have the responsibility of assessing risk of internal
equipment transfers; however, even internal transfers of this security
level of equipment should be destroyed or properly sanitized.

Unclassified information is any information system not processing
National Security Information. Storage media for these systems will be
sanitized in accordance with NIST Special Publication 800-88, Guidelines
for Media Sanitization. Managers have the responsibility of ensuring the
equipment is sanitized before computer equipment is transferred
(internal transfers included), donated or destroyed.

No equipment should be accessed or transferred until the appropriate
method of data protection has been applied to all storage media
contained within that equipment. In some cases, nonvolatile memory, such
as removable flash cards, exist and may contain sensitive information.
These forms of memory should also be erased or removed from the device.
Also, ensure that all removable storage media (floppies, ZIP disks,
backup tapes, CD-ROMs, etc.) are removed or destroyed before the
equipment is transferred, disposed of, or donated.

Certification must be provided to the property officers to ensure
degaussing and/or forms of memory have been erased or removed from the
device. No property may be transferred, donated, recycled, sold or
scrapped without the approval of the servicing property office.

#  

# Physical and Environmental Protection (PE)

Bureaus and offices shall comply with the NIST Special Publication
800-53,Rev. 1, *Recommended Security Controls for Federal Information
Systems,* physical and environmental protection controls listed in the
following table:

+------+--------------------------+----------+-----------+-----------+
|      |                          |          |           |           |
| Phys |                          |          |           |           |
| ical |                          |          |           |           |
| and  |                          |          |           |           |
| E    |                          |          |           |           |
| nvir |                          |          |           |           |
| onme |                          |          |           |           |
| ntal |                          |          |           |           |
| Pr   |                          |          |           |           |
| otec |                          |          |           |           |
| tion |                          |          |           |           |
+------+--------------------------+----------+-----------+-----------+
|      |                          | Control  |           |           |
|      |                          | B        |           |           |
| Con  | Control Name             | aselines |           |           |
| trol |                          |          |           |           |
| Nu   |                          |          |           |           |
| mber |                          |          |           |           |
+------+--------------------------+----------+-----------+-----------+
|      |                          | Low      | Moderate  | High      |
+------+--------------------------+----------+-----------+-----------+
| PE-1 | Physical and             | PE-1     | PE-1      | PE-1      |
|      | Environmental Protection |          |           |           |
|      | Policy and Procedures    |          |           |           |
+------+--------------------------+----------+-----------+-----------+
| PE-2 | Physical Access          | PE-2     | PE-2      | PE-2      |
|      | Authorizations           |          |           |           |
+------+--------------------------+----------+-----------+-----------+
| PE-3 | Physical Access Control  | PE-3     | PE-3      | PE-3 (1)  |
+------+--------------------------+----------+-----------+-----------+
| PE-4 | Access Control for       | Not      | Not       | PE-4      |
|      | Transmission Medium      | Selected | Selected  |           |
+------+--------------------------+----------+-----------+-----------+
| PE-5 | Access Control for       | Not      | PE-5      | PE-5      |
|      | Display Medium           | Selected |           |           |
+------+--------------------------+----------+-----------+-----------+
| PE-6 | Monitoring Physical      | PE-6     | PE-6 (1)  | PE-6 (1)  |
|      | Access                   |          |           | (2)       |
+------+--------------------------+----------+-----------+-----------+
| PE-7 | Visitor Control          | PE-7     | PE-7 (1)  | PE-7 (1)  |
+------+--------------------------+----------+-----------+-----------+
| PE-8 | Access Records           | PE-8     | PE-8      | PE-8 (1)  |
|      |                          |          |           | (2)       |
+------+--------------------------+----------+-----------+-----------+
| PE-9 | Power Equipment and      | Not      | PE-9      | PE-9      |
|      | Power Cabling            | Selected |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Emergency Shutoff        | Not      | PE-10 (1) | PE-10 (1) |
| E-10 |                          | Selected |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Emergency Power          | Not      | PE-11     | PE-11 (1) |
| E-11 |                          | Selected |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Emergency Lighting       | PE-12    | PE-12     | PE-12     |
| E-12 |                          |          |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Fire Protection          | PE-13    | PE-13 (1) | PE-13 (1) |
| E-13 |                          |          | (2) (3)   | (2) (3)   |
+------+--------------------------+----------+-----------+-----------+
| P    | Temperature and Humidity | PE-14    | PE-14     | PE-14     |
| E-14 | Controls                 |          |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Water Damage Protection  | PE-15    | PE-15     | PE-15 (1) |
| E-15 |                          |          |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Delivery and Removal     | PE-16    | PE-16     | PE-16     |
| E-16 |                          |          |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Alternate Work Site      | Not      | PE-17     | PE-17     |
| E-17 |                          | Selected |           |           |
+------+--------------------------+----------+-----------+-----------+
| PE   | Location of Information  | Not      | PE-18     | PE-18 (1) |
| -18  | System Components        | Selected |           |           |
+------+--------------------------+----------+-----------+-----------+
| P    | Information Leakage      | Not      | Not       | Not       |
| E-19 |                          | Selected | Selected  | Selected  |
+------+--------------------------+----------+-----------+-----------+

[]{#__RefHeading___Toc193514839 .anchor}Table 67: Physical and
Environmental Protection Controls

## PE-1 -- Physical and Environmental Protection Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### 

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update (at least annually) for the protection of information
system(s):

1.  Formal, documented, physical and environmental protection policy
    that addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the physical and environmental protection policy and associated
    physical and environmental protection controls.

### PE-1 Physical and Environmental Protection Controls Implementation

The System Owner must document the physical and environmental protection
controls in the IT System Security Plan and implement the protection
measures as dictated by this policy as appropriate for the security
category of the information system(s) to be protected. The results of a
risk assessment help determine the physical security requirements of
controlled areas.

## PE-2 -- Physical Access Authorizations 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop and keep current a list of personnel
with authorized access to the facilities where DOI information systems
reside (except for those areas within the facility officially designated
as publicly accessible) and issue appropriate authorization credentials
(e.g., badges, identification cards, smart cards). Designated officials
within the bureau or office \[Facility Security Officers, Information
System Security Officers and/or BCISOs\] shall review and approve the
access list and authorization credentials at least annually.

#### Policy Supplement(s):

PE-2(a)

Bureaus and offices shall promptly remove from access lists any
personnel no longer requiring access to the facility where the
information system resides.

## PE-3 -- Physical Access Control 

#### Applicability:

All Information Systems

#### 

#### Policy Statement:

Bureaus and offices shall control all physical access points (including
designated entry/exit points) to the facilities where DOI information
systems reside (except for those areas within the facility officially
designated as publicly accessible) and verify individual access
authorizations before granting access to facilities. Bureaus and offices
shall control access to areas officially designated as publicly
accessible, as appropriate, in accordance with the organization's
assessment of risk. Packages, briefcases, and other containers in the
immediate possession of visitors, employees, or other persons arriving
on, working at, visiting, or departing from Federal buildings and
grounds, are subject to reasonable inspection by personnel security and
security guards in accordance with DOI Departmental Manual 444 Part 1.

Upon entering or exiting any agency facility, employees, contractors,
volunteers, and/or visitors, with laptops must have in possession an
authorized property pass. All laptops that do not have an associated
property pass must obtain a pass from the building security personnel in
conjunction with the visited office.

#### Mandatory Policy Enhancement(s):

+-------------------------------------------------+----------+--------+
| MANDATORY ENHANCEMENT(S)                        | APPL     |        |
|                                                 | ICABLITY |        |
+-------------------------------------------------+----------+--------+
|                                                 | MODERATE | HIGH   |
+-------------------------------------------------+----------+--------+
| \(1\) Bureaus and offices shall ensure for      |          | X      |
| server rooms, communications centers or any     |          |        |
| other areas within a facility containing large  |          |        |
| concentrations of information system components |          |        |
| that controls for the physical access to the    |          |        |
| information system are independent of the       |          |        |
| physical access controls for the facility.      |          |        |
|                                                 |          |        |
| This policy enhancement, in general, applies to |          |        |
| server rooms, communications centers, or any    |          |        |
| other areas within a facility containing large  |          |        |
| concentrations of information system components |          |        |
| or components with a higher impact level than   |          |        |
| that of the majority of the facility. The       |          |        |
| intent is to provide an additional layer of     |          |        |
| physical security for those areas where the     |          |        |
| organization may be more vulnerable due to the  |          |        |
| concentration of information system components  |          |        |
| or the impact level of the components. The      |          |        |
| control enhancement is not intended to apply to |          |        |
| workstations or peripheral devices that are     |          |        |
| typically dispersed throughout the facility and |          |        |
| used routinely by organizational personnel.     |          |        |
+-------------------------------------------------+----------+--------+

[]{#__RefHeading___Toc193514840 .anchor}Table 68: PE-3 -- Physical
Access Control Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

PE-3(a)

Physical access point controls include physical access devices (e.g.,
keys, locks, combinations, card readers) and/or guards to control entry
to facilities containing information systems.

PE-3(b)

Bureaus and offices shall ensure that keys, combinations, and other
access devices are secured and inventoried regularly.

PE-3(c)

Bureaus and offices shall change combinations and keys periodically; and
when keys are lost, combinations are compromised, or when individual's
roles/responsibilities change, are transferred or are terminated.

PE-3(d)

Where the federal Personal Identity Verification (PIV) credential is
being used as identification token and token-based access control is
employed, bureaus and offices shall ensure the access control system
conforms to the requirements of FIPS 201, *Personal Identity
Verification (PIV) of Federal Employees and Contractors* and NIST
Special Publication 800-73, *Interfaces for Personal Identity
Verification*.

PE-3(e)

If the token-based access control function employs cryptographic
verification, bureaus and offices shall ensure the access control system
conforms to the requirements of NIST Special Publication 800-78,
*Cryptographic Algorithms and Key Sizes for Personal Identity
Verification*.

PE-3(f)

If the token-based access control function employs biometric
verification, bureaus and offices shall ensure the access control system
conforms to the requirements of NIST Special Publication 800-76,
*Biometric Data Specification for Personal Identity Verification*.

## PE-4 -- Access Control for Transmission Medium 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall control physical access to High-impact
information system's distribution and transmission lines within
organizational facilities to prevent accidental damage, eavesdropping,
in-transit modification, disruption, or physical tampering.

#### Policy Supplement(s):

PE-4(a)

Appropriate protective measures to control physical access to
High-impact information system distribution and transmission lines
include:

1.  locked wiring closets;

2.  disconnected or locked spare jacks; and/or

3.  protection of cabling by conduit or cable trays.

## PE-5 -- Access Control for Display Medium 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall control physical access to Moderate and
High-impact information system devices that display information to
prevent unauthorized individuals from observing the display output.

## PE-6 -- Monitoring Physical Access 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall monitor physical access to all information
systems to detect and respond to physical security incidents.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall monitor real-time  X              X
  physical intrusion alarms and surveillance                        
  equipment.                                                        

  \(2\) Bureaus and offices shall employ automated                  X
  mechanisms to recognize potential intrusions and                  
  initiate appropriate response actions.                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514841 .anchor}Table 69: PE-6 -- Monitoring
Physical Access Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

PE-6(a)

Bureaus and offices shall review physical access logs periodically and
investigate any apparent security violations or suspicious physical
access activities. Procedures to response to detected physical security
incidents shall be part of the incident response capability.

## 

## 

## PE-7 -- Visitor Control 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall control physical access to all information
systems by authenticating visitors before authorizing access to
facilities or areas other than areas designated as publicly accessible.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure escorts for X              X
  visitors and monitor visitor activity, when                       
  required.                                                         
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514842 .anchor}Table 70: PE-7 -- Visitor
Control Mandatory Policy Enhancement(s)

## PE-8 -- Access Records

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall maintain visitor access records to the
facility where DOI information systems reside (except for those areas
within the facility officially designated as publicly accessible) that
includes:

1.  name and organization of the person visiting;

2.  signature of the visitor;

3.  form of identification;

4.  date of access;

5.  time of entry and departure;

6.  purpose of visit; and

7.  name and organization of person visited.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated                  X
  mechanisms to facilitate the maintenance and                      
  review of access records.                                         

  \(2\) Bureaus and offices shall maintain a record                 X
  of all physical access, both visitor and                          
  authorized individuals.                                           
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514843 .anchor}Table 71: PE-8 -- Access Records
Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

PE-8(a)

Designated officials within the organization review the visitor access
records within 30 days after closeout to ensure compliance with policies
and procedures.

## PE-9 -- Power Equipment and Power Cabling 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall protect power equipment and power cabling for
Moderate and High-impact information systems from damage and
destruction.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  employing redundant and parallel power cabling                    
  paths.                                                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514844 .anchor}Table 72: PE-9 -- Power
Equipment and Power Cabling Mandatory Policy Enhancement(s)

## PE-10 -- Emergency Shutoff

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that specific locations within
facilities containing a concentration of Moderate and High impact
information system resources have the capability of shutting off power
to any information system component that may be malfunctioning or
threatened without endangering personnel by requiring them to approach
the equipment.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall protect emergency  X              X
  power-off capability from accidental and                          
  intentional/unauthorized activation.                              
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514845 .anchor}Table 73: PE-10 -- Emergency
Shutoff Mandatory Policy Enhancement(s)

## PE-11 -- Emergency Power

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall provide a short-term uninterruptible power
supply to facilitate an orderly shutdown of Moderate and High impact
information systems in the event of a primary power source loss.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall provide a                         X
  long-term alternate power supply for information                  
  systems that is capable of maintaining minimally                  
  required operational capability in the event of an                
  extended loss of the primary power source.                        
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514846 .anchor}Table 74: PE-11 -- Emergency
Power Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(2\) Bureaus and offices should consider                         X
  providing a long-term alternate power supply for                  
  information systems that is self-contained and not                
  reliant on external power generation.                             
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514847 .anchor}Table 75: PE-11 -- Emergency
Power Recommended Policy Enhancement(s)

## PE-12 -- Emergency Lighting

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall employ and maintain automatic emergency
lighting systems that activate in the event of a power outage or
disruption and that cover emergency exits and evacuation routes.

## PE-13 -- Fire Protection 

#### Applicability:

All Information Systems

#### 

#### Policy Statement:

Bureaus and offices shall employ and maintain fire suppression and
detection devices/systems that can be activated in the event of a fire.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ fire        X              X
  detection devices/systems that activate                           
  automatically and provide notification to bureau                  
  or offices and emergency responders in the event                  
  of a fire.                                                        

  \(2\) Bureaus and offices shall employ fire        X              X
  suppression devices/systems that provide automatic                
  notification of any activation to the organization                
  and emergency responders.                                         

  \(3\) Bureaus and offices shall employ automatic   X              X
  fire suppression capability in facilities that are                
  not staffed on a continuous basis.                                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514848 .anchor}Table 76: PE-13 Fire Protection
Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

PE-13(a)

Fire suppression and detection devices shall include: sprinkler systems;
handheld fire extinguishers; fixed fire hoses; and smoke detectors.

## PE-14 -- Temperature and Humidity Controls 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall regularly maintain within acceptable levels
and monitor the temperature and humidity within facilities containing
DOI information systems.

## PE-15 -- Water Damage Protection 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall protect all information systems from water
damage resulting from broken plumbing lines or other sources of water
leakage by providing master shutoff valves that are accessible, working
properly, and known to key personnel.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ mechanisms                 X
  to prevent, without manual intervention, water                    
  damage in the event of a significant water leak.                  
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514849 .anchor}Table 77: PE-15 -- Water Damage
Protection Mandatory Policy Enhancement(s)

## PE-16 -- Delivery and Removal 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall authorize and control all information
system-related items entering and exiting the facility and maintain
appropriate records of those items.

#### Policy Supplement(s):

PE-16(a)

Bureaus and offices shall control delivery areas and, if possible,
isolate the areas from information systems and media libraries to avoid
unauthorized physical access.

## PE-17 -- Alternate Work Site 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall employ appropriate management, operational,
and technical information system security controls at alternate work
sites in accordance with the DOI Telework Policy and the remote access
section of this handbook.

#### Policy Supplement(s):

PE-17(a)

Bureaus and offices shall provide a means for employees to communicate
with information system security staff in case of security problems.

#### 

#### 

#### Additional Policy Guidance:

Bureaus and offices are required to establish telework policies in
accordance with Section 359 and Public Law 106-346, and to designate
telework positions in accordance with the November 17, 2004 memorandum
"Designation of Telework Positions" from the Deputy Assistance for
Performance, Accountability and Human Resources. Telework practices
shall be carried out as described in the DOI Telework Policy. All
implementations of remote access to the DOI network must comply with the
Enterprise Services Remote Access solution. NIST Special Publication
800-46, *Security for Telecommuting and Broadband Communications* also
provides guidance on security in telecommuting and broadband
communications.

## PE-18 -- Location of Information System Components

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High impact
information system components within facilities are positioned to
minimize potential damage from physical and environmental hazards and to
minimize the opportunity for unauthorized access.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall plan the location                 X
  or site of facilities where the information system                
  resides with regard to physical and environmental                 
  hazards and for existing facilities, consider the                 
  physical and environmental hazards in its risk                    
  mitigation strategy.                                              
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514850 .anchor}Table 78: PE-18 -- Location of
Information System Components Mandatory Policy Enhancement(s)

#### Additional Policy Guidance:

Physical and environmental hazards include, for example, flooding, fire,
tornados, earthquakes, hurricanes, acts of terrorism, vandalism,
electrical interference, and electromagnetic radiation.

## PE-19 -- Information Leakage

Bureaus and offices should protect information systems from information
leakage due to electromagnetic signals emanations.

# Planning (PL)

Bureaus and offices shall comply with the NIST Special Publication
800-53, Rev.1, *Recommended Security Controls for Federal Information
Systems,* planning controls listed in the following table, for all DOI
IT security programs, as well as general support systems and major
applications under their responsibility.

+-----------+---------------------------+------------+--------+------+
|  Planning |                           |            |        |      |
+-----------+---------------------------+------------+--------+------+
|           |                           | Control    |        |      |
|           |                           | Baselines  |        |      |
| Control   | Control Name              |            |        |      |
| Number    |                           |            |        |      |
+-----------+---------------------------+------------+--------+------+
|           |                           | Low        | Mo     | High |
|           |                           |            | derate |      |
+-----------+---------------------------+------------+--------+------+
| PL-1      | Security Planning Policy  | PL-1       | PL-1   | PL-1 |
|           | and Procedures            |            |        |      |
+-----------+---------------------------+------------+--------+------+
| PL-2      | System Security Plan      | PL-2       | PL-2   | PL-2 |
+-----------+---------------------------+------------+--------+------+
| PL-3      | System Security Plan      | PL-3       | PL-3   | PL-3 |
|           | Update                    |            |        |      |
+-----------+---------------------------+------------+--------+------+
| PL-4      | Rules of Behavior         | PL-4       | PL-4   | PL-4 |
+-----------+---------------------------+------------+--------+------+
| PL-5      | Privacy Impact Assessment | PL-5       | PL-5   | PL-5 |
+-----------+---------------------------+------------+--------+------+
| PL-6      | Security-Related Activity | Not        | PL-6   | PL-6 |
|           | Planning                  | Selected   |        |      |
+-----------+---------------------------+------------+--------+------+

[]{#__RefHeading___Toc193514851 .anchor}Table 79: Planning Controls

## PL-1 -- Security Planning Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, security planning policy that addresses purpose,
    scope, roles, responsibilities, management commitment, coordination
    among organizational entities, and compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the security planning policy and associated security planning
    controls.

### PL-1 Bureau and Office IT Security Program Plans

Bureaus and offices shall submit an Information Technology Security
Program Plan to the CISO at least annually.

Bureau and office IT Security Program Plans shall detail bureau plans on
implementing the IT security requirements set forth by the department.
Bureau IT Security Program Plans shall also include:

1.  program successes in the past calendar year;

2.  allocated budget to manage the IT security program; and

3.  implementation challenges facing bureaus and offices in the upcoming
    calendar year.

## PL-2 -- System Security Plan

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop and implement a security plan for all
information systems that provides an overview of the security
requirements for the system and a description of the security controls
in place or planned for meeting those requirements. Designated officials
within the organization \[Authorizing Official, System Owner and System
Security Officer\] must review and approve the plan.

#### Policy Supplement(s):

PL-2(a)

Bureaus and offices shall ensure that security plans are aligned with
the bureau or office's information system architecture and information
security architecture.

### PL-2 IT System Security Plan Overview

FISMA and OMB Circular A-130 require all major applications and general
support systems to have a security plan. Security plans should be
aligned with the department's information security architecture. NIST
Special Publication 800-18, Rev.1, *Guide for Developing Security Plans
for Federal Information Systems* provides guidance on security planning.

An IT System Security Plan (SSP) provides an overview of the system
impact level and types of information processed or stored in a system
and the related security requirements to protect the data. It also
describes the controls in place and planned for meeting those
requirements. The IT System Security Plan provides all of the
information necessary to secure an IT system throughout the system's
life cycle, including:

1.  an overview of the security requirements of the system and the
    information processed;

2.  a delineation of the responsibilities and expected behavior of all
    individuals who access the system (including Rules of Behavior or
    Acceptable Use Policies);

3.  information and agreement regarding interconnections with other
    systems; and;

4.  other information necessary for the operation and maintenance of the
    system.

The DOI Certification and Accreditation Guide and Templates Guide and
Templates contain complete details on the contents of the SSP.

### PL-2 Compliance -- IT System Security Plan Elements

Bureaus and offices shall follow the methodology prescribed by the NIST
SP 800-18, Rev.1, *Guide for Developing Security Plans for Information
Technology Systems* and the format outlined in the DOI Certification and
Accreditation Guide and Templates Guide.

In addition, bureaus and offices shall ensure that all information
system security plans document the following elements:

1.  Dates, version numbers, revision/history pages and when final,
    approval signatures;

2.  Complete description and diagrams of the information system
    accreditation boundary. Accreditation boundary descriptions shall
    include but not be limited to:

    a.  Boundary nomenclature

    b.  Internet protocol addresses and hostnames

    c.  Operating systems and versions

    d.  Applications and versions

    e.  Asset tag information

3.  Complete listing of all information system information types and
    sensitivity determinations, as defined in NIST Special Publication
    800-60, *Guide for Mapping Types of Information and Information
    Systems to Security Categories*.

4.  Listing of security categorizations for each information type
    documented.

5.  An overall security categorization determination for the information
    system based on each of the security categorizations of the
    information types, in accordance with FIPS Publication 199,
    *Standards for Security Categorization of Federal Information and
    Information Systems*.

6.  All required security controls for the information system and their
    implementation status (e.g., "implemented", "planned", "not
    implemented and mitigating controls"), in accordance with NIST
    800-53, Rev.1, *Recommended Security Controls for Federal
    Information Systems*.

7.  Identification of designated personnel for System Owner, Authorizing
    Official, and System Security Officer.

8.  Identification (inventory listing source, title, version) of all
    relevant and applicable Security Technical Implementation Guides
    (STIGs).

9.  Implementation status of each Security Technical Implementation
    Guide (STIG). The implementation status shall include, the date the
    security configuration item was implemented, if operating as
    intended, and verification of effectiveness.

    a.  If the security configuration is not implemented, the status
        shall include a future implementation date.

    b.  If the security configuration cannot be implemented, the status
        shall include a formal acceptance of risk by the Authorizing
        Official.

## PL-3 -- System Security Plan Update

#### Applicability:

All Information Systems

#### 

#### Policy Statement:

Bureaus and offices shall review security plans for all information
systems at least annually and revise the plan to address any major
system and/or organizational changes or problems identified during plan
implementation or security control assessments.

#### Policy Supplement(s):

PL-3(a)

Bureaus and offices shall define significant changes in advance and
identify them in the configuration management process. Please refer to
the Certification, Accreditation, and Security Assessment section of
this handbook for further policy requirements.

## PL-4 -- Rules of Behavior

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall establish and make readily available to all
information system users a set of rules that describes their
responsibilities and expected behavior with regard to information and
information system usage.

#### Policy Supplement(s):

PL-4(a)

Bureaus and offices shall ensure receipt of signed acknowledgement from
users indicating that they have read, understand, and agree to abide by
the rules of behavior, before authorizing access to the information
system and its resident information.

PL-4(b)

Bureaus and offices may leverage electronic signatures for use in
acknowledging rules of behavior.

PL-4(c)

Electronic signatures are acceptable for use in acknowledging rules of
behavior.

### PL-4 Rules of Behavior Contents

Rules of Behavior, also called Acceptable Use Policies (AUPs) or
standards, instruct system users (both federal and contractor) about
ways in which they may and may not use IT systems. These rules
communicate to every individual his/her role in protecting IT resources,
and advise them of their obligations. The rules often cover Internet and
e-mail use, dial-up use, use of copyrighted software, use of government
resources, assignment and limitation of system privileges, and
individual accountability.

Bureaus and offices must ensure that "rules of behavior" documentation
clearly delineates responsibilities and expected behavior of all
personnel with access to information systems.

The rules shall state the consequences of inconsistent behavior or
noncompliance and shall be made available to every employee or
contractor prior to receiving access to bureau or office information
systems.

Rules of behavior documentation shall include a signature page, as it is
required that all employees with access to information systems
acknowledge receipt, indicating that they have read, understand, and
agree to abide by the rules of behavior.

Topics covered by information system rules of behavior shall, at a
minimum, include:

1.  User responsibilities, expected use of system, and behavior;

2.  Define appropriate limits on interconnections;

3.  Describe consequences of behavior not consistent with rules; and

4.  Access to sensitive data and PII

Rules shall also, as appropriate, cover:

1.  Teleworking

2.  Remote Access

3.  Acceptable Internet Use

4.  Use of government equipment

Bureaus and offices can also include, by reference, the policies and
procedures governing information security and other applicable policies
in the text of the rules of behavior.

### PL-4 Rules of Behavior Compliance Monitoring

DOI networks and IT systems do not inherently provide users a right of
privacy except as may be provided under the Privacy Act or other
legislation; therefore bureaus and offices are permitted to audit user
activity in accordance with the Rules of Behavior. However, System
Owners must notify users of this prior to system access to avoid any
question about an implied right to privacy on the system. For example,
bureaus and offices must ensure that the network warning banner
communicates the intent to monitor users during the authorized or
unauthorized use of DOI IT systems.

## PL-5 -- Privacy Impact Assessments (PIAs)

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall conduct Privacy Impact Assessments (PIAs) on
all information system in accordance with OMB policy.

#### Additional Policy Guidance:

The DOI Certification and Accreditation Guide and Templates contain
details on completing the PIA and additional guidance can be found in
OMB Memorandum 03-22, *Guidance for Implementing the Privacy Provisions
of the E-Government Act of 2002* which details guidance for implementing
the privacy provisions of the E-Government Act of 2002. The DOI Privacy
Impact Assessment and Guide is available through the DOI Privacy Program
website[^11].

## PL-6 -- Security Related Activity Planning

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall plan and coordinate security-related
activities affecting Moderate and High impact information systems before
conducting such activities in order to minimize the impact on operations
(i.e., mission, functions, image, and reputation) and assets.

#### Policy Supplement(s):

PL-6(a)

Routine security-related activities shall include, but not be limited
to, security assessments, audits, system hardware and software
maintenance, security certifications, and testing/exercises.

#  

# Personnel Security (PS)

Effective administration of users\' computer access is essential to
maintaining system security. Administration of system users focuses on
identification, authentication, and access authorizations. Bureaus and
offices shall include a process of auditing and otherwise periodically
verifying the legitimacy of current accounts and access authorizations
in IT Security Programs. In addition, processes must address the timely
modification or removal of access and associated issues for employees
who are reassigned, promoted, or terminated, or who retire. Many
important issues in computer security involve federal and contractor
system users, designers/programmers, implementers/maintainers, and
managers. A broad range of security issues relates to how these
individuals interact with computers and the access and authorities they
need to do their job. No computer system can be secured without properly
addressing these security issues. Bureaus and offices shall comply with
the NIST Special Publication 800-53, Rev.1, *Recommended Security
Controls for Federal Information Systems*, personnel security controls
listed in the following table:

+---------+-------------------------------+---------+---------+-------+
|  Pe     |                               |         |         |       |
| rsonnel |                               |         |         |       |
| S       |                               |         |         |       |
| ecurity |                               |         |         |       |
+---------+-------------------------------+---------+---------+-------+
|         |                               | Control |         |       |
|         |                               | Ba      |         |       |
| Control | Control Name                  | selines |         |       |
| Number  |                               |         |         |       |
+---------+-------------------------------+---------+---------+-------+
|         |                               | Low     | M       | High  |
|         |                               |         | oderate |       |
+---------+-------------------------------+---------+---------+-------+
| PS-1    | Personnel Security Policy and | PS-1    | PS-1    | PS-1  |
|         | Procedures                    |         |         |       |
+---------+-------------------------------+---------+---------+-------+
| PS-2    | Position Categorization       | PS-2    | PS-2    | PS-2  |
+---------+-------------------------------+---------+---------+-------+
| PS-3    | Personnel Screening           | PS-3    | PS-3    | PS-3  |
+---------+-------------------------------+---------+---------+-------+
| PS-4    | Personnel Termination         | PS-4    | PS-4    | PS-4  |
+---------+-------------------------------+---------+---------+-------+
| PS-5    | Personnel Transfer            | PS-5    | PS-5    | PS-5  |
+---------+-------------------------------+---------+---------+-------+
| PS-6    | Access Agreements             | PS-6    | PS-6    | PS-6  |
+---------+-------------------------------+---------+---------+-------+
| PS-7    | Third-Party Personnel         | PS-7    | PS-7    | PS-7  |
|         | Security                      |         |         |       |
+---------+-------------------------------+---------+---------+-------+
| PS-8    | Personnel Sanctions           | PS-8    | PS-8    | PS-8  |
+---------+-------------------------------+---------+---------+-------+

[]{#__RefHeading___Toc193514852 .anchor}Table 80: Personnel Security
Controls

## PS-1 -- Personnel Security Policy and Procedures

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, personnel security policy that addresses
    purpose, scope, roles, responsibilities, management commitment,
    coordination among organizational entities, and compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the personnel security policy and associated personnel security
    controls.

## PS-2 -- Position Categorization

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall assign risk designations to all positions and
establish screening criteria for individuals filling those positions.
Position risk designations shall be reviewed at least every 3 years and
revised as necessary.

### PS-2 Position Designations of Personnel (Federal and Contractor)

Bureaus and offices shall comply with the requirements included in
Department Manual 441, Chapter 3, Attachment 4A, which provides criteria
for national security positions, and for High, Medium, and Low "Risk"
non-national security positions.

## PS-3 -- Personnel Screening 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall screen individuals \[i.e., federal employees,
contractors and temporary assigned personnel\] requiring access to DOI
information and information systems before authorizing access.

#### Policy Supplement(s):

PS-3(a)

Screening shall be performed consistent with guidance provided in
Department Manual 375, Chapter 19, section 19.9.b.1. A risk-based,
cost-effective approach must be followed to determine the risk of harm
to the system.

## PS-4 -- Personnel Termination 

#### Applicability:

All Information Systems

#### 

#### 

#### Policy Statement:

The Manager (DOI employee or Contractor employee) in conjunction with
the System Owner (e.g., supervisor, team lead) and/or COTR responsible
for the exiting employee's/contractor's work area, must ensure the
following items are returned to the DOI:

##### Software/Hardware/Documentation 

-   Collect all Software Source code utilized by or developed for the
    DOI.

-   Collect technical documentation, including all work in progress and
    all other documentation used or developed on the job. This includes
    DOI and non-DOI documentation.

-   Collect hardware modifications, including work in progress and all
    other hardware used on the job.

-   Collect Software and Hardware Tools provided by the DOI to perform
    the duties of the vacated position.

-   Collect all work that was being performed by the
    employee/contractor.

##### [Personal Computers -]{.underline} Desktop Workstation(s) and Laptop(s)

-   All development work stored on the computer hard drives or stored in
    LAN accounts accessible by the vacating person, must be downloaded
    to removable media and provided to the DOI.

-   Exiting employee/contractor must remove all personal data that may
    be on the computers and on the LAN file servers.

-   Passwords must be disabled on computers being returned to the DOI,
    prior to the departure of the exiting employee/contractor, to
    facilitate reuse of the resource.

-   Ensure that Barcodes and Serial Numbers match Property Custodians
    property list and that exiting employee/contractor returned all
    workstations and laptops prior to departure.

-   Provide facility IT personnel with a network change request to
    remove user accounts.

-   Disable Encryption System accounts for the exiting
    employee/contractor.

-   Re-format and re-image the hard drive.

##### DOI support systems 

-   All development work stored in DOI Support System accounts
    accessible by the vacating person, must be downloaded to removable
    media (or transferred to another account) and provided to the DOI.

-   Exiting employee/contractors account must be deactivated on the
    support systems.

-   Collect all DOI documentation and system manuals in possession of
    the exiting employee/contractor.

-   Inform field sites, Program Office, and support Contractors of
    personnel change, and advise them to remove employee from all
    mailing lists and all security access systems.

-   Notify all co-workers and division managers that the
    employee/contractor is no longer supporting the program.

-   Advise the appropriate helpdesks that the employee/contractor is no
    longer available for callback.

##### Administrative Systems

Ensure the following accounts are disabled as applicable for the exiting
employee / contractor:

-   Purchasing Agent/Approving Official - Credit Card System.

-   Travel Manager Account

-   Voice Mail

-   Pager Systems

-   Any password protected Website with exiting person's account

##### Administrative Tools/Items

Ensure the following items are collected from the employee/contractor:

-   Phone Card(s)

-   Travel Credit Card

-   Purchasing Agent Credit Card.

-   Cell Phone(s)

-   Keys to all locked cabinets, desks, computers.

-   Collect security badge or advise security to remove access to any
    secure areas.

-   Change all lock combinations and or door access codes used by the
    exiting person.

-   Ensure the appropriate Property Custodian(s) concur(s) that all
    equipment has been returned.

-   Have exiting employee/contractor sign the attached DOI clearance
    sheet.

#### Policy Supplement(s):

PS-4(a)

Bureaus and offices shall ensure these actions are taken immediately
upon an employee's termination.

## PS-5 -- Personnel Transfer 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall review all information systems/facilities
access authorizations when personnel are reassigned or transferred to
other positions within the organization and initiate appropriate actions
(e.g., reissuing keys, identification cards, building passes; closing
old accounts and establishing new accounts; and changing system access
authorizations).

#### 

#### 

#### 

#### Additional Policy Guidance:

A change in user access, and therefore, suitability and system risk, may
arise when an employee changes bureaus or offices within DOI or changes
job duties. Bureaus and offices should ensure that their IT Security
Programs address the security issues of these changes.

## PS-6 -- Access Agreements 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure completion and signature of the
appropriate access agreements (e.g., nondisclosure agreements,
acceptable use agreements, rules of behavior, conflict-of-interest
agreements) for all individuals requiring access to DOI information and
information systems before authorizing access and review and update the
agreements at least annually.

## PS-7 -- Third-Party Personnel Security 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall establish personnel security requirements
including security roles and responsibilities, for third-party providers
(e.g., service bureaus, contractors, and other organizations providing
information system development, information technology services,
outsourced applications, network and security management) and monitor
provider compliance.

#### Policy Supplement(s):

PS-7(a)

Bureaus and offices shall explicitly include personnel security
requirements in acquisition-related documents.

### PS-7 Effective Administration of Contract Staff

This section describes the Information Security policy for establishing
Information Security requirements for DOI IT--related procurements. All
DOI contract-awarding officials must adhere to the policy guidelines
presented below, whether the IT-related services are procured by DOI or
other federal government organizations on behalf of DOI.

The Program Manager or Information System Owner has the primary
responsibility to assure that contractors are aware of and comply with
DOI Information Security Program elements. They must also work with
bureau and office program managers, including BCISOs, to address IT
security requirements in all stages of an acquisition (i.e., from the
earliest budgeting and acquisition planning stages through requirements
development, solicitation, source evaluation and selection, contract
award and administration). Information System Owners must work with
their respective personnel security office before a solicitation is
released to designate contract risk levels (for all on site contracts,
not just IT), as well as after award, to arrange for background
investigations on contractor employees. The operating unit must provide
the contracting office with the appropriate risk determination for the
contract, and the contracting office includes the corresponding
appropriate language in the contract as described below.

In accordance with the requirements of the Departmental Manual 375,
Chapter 19, every DOI procurement solicitation document such as Request
for Proposals (RFP), Requests For Information (RFI), Statements of Work
(SOW), Statements of Requirements (SOR), etc. that involve the
development of an Information Technology (IT) system or the use of DOI
information resources, must include appropriate Information Security
requirements. Information Security requirements must be considered in
all phases of the DOI procurement cycle: planning, solicitation, source
selection/award, and contract administration.

Follow Specific guidance as per, DOI Privacy Act regulations and FAR 43
CFR for Privacy Act Systems requirements. See specifically FAR
Contracting Officer and System Manager responsibilities (See FAR at 48
CFR 24.103 http://www.arnet.gov/far/). Privacy clauses at 52.224-1 & 2
(http://www.arnet.gov/far/farqueryframe.html). Also see DOI Acquisition
Regulations (DIAR) 1452.224-1:
http://www.doi.gov/pam/1452-3.html#244-1%20

##### Requirements for Acquisitions and Contractual Agreements

All contractors and other external organizations who are involved in
developing information systems for use by DOI, or in providing any other
type of service for DOI in which federal information resources are used,
must comply with the following guidance.

Information Security requirements will be considered in all phases or
stages of the DOI procurement process. The applicable Program
Manager/System Owner is responsible for ensuring that the solicitation
document includes the appropriate Information Security requirements. The
Information Security requirements must be sufficiently detailed to
enable service providers to understand what is required. A general
statement that the service provider must agree to comply with applicable
requirements is not acceptable. The Information Security requirements in
the solicitation documents must address all pertinent DOI information
system security requirements. The applicable DOI Program Manager/System
Owner is responsible for ensuring that DOI information system security
requirements are implemented and complied with for any information
system under their management control or purview. The applicable DOI
Program Manager/System Owner will involve the appropriate Information
Security personnel from the beginning of the procurement lifecycle to
disposition, for any IT-related procurement.

##### 

##### 

##### 

##### Guidelines to Program Manager or Information System Owner Tasks

The general processes recommended for implementing Information Security
requirements in IT-related contracts are as follows:

1.  Identify Information Security and privacy requirements during the
    requirements analysis development phase, with specific analysis of
    availability, integrity, and confidentiality and the technical
    requirements of the contract;

2.  Use FIPS 199 and the NIST Special Publication 800-60, *Guide for
    Mapping Types of Information and Information Systems to Security
    Categories* to determine system sensitivity and criticality;

3.  Ensure that all hardware and software purchases conform to the
    current version of the [DOI
    TRM](http://www.doi.gov/ocio/architecture);

4.  Ensure that all system development efforts comply with the best
    practices, technical standards and product standards identified in
    the current version of the [DOI
    TRM](http://www.doi.gov/ocio/architecture);

5.  Determine which Information Security measures will be necessary to
    protect PII and SBU information by listing the potential threats and
    vulnerabilities and then describing the measures needed to provide
    protection, including physical and environmental security
    safeguards;

6.  If information sharing is involved, resolve any conflicts among all
    affected information owners or custodians and establish whatever
    MOUs, MOAs, and SLAs are necessary. In general, the information
    owner or custodian will establish the security level for their
    respective information;

7.  Develop specifications (either a Statement of Work (SOW) or
    Performance Work Statement) that include appropriate Information
    Security requirements and address appropriate technical,
    administrative, physical and personnel security requirements;

8.  Develop evaluation criteria for use in the selection of the
    contractor;

9.  Participate in evaluation of the proposals received in response to
    the DOI procurement document to ensure that they address and meet
    the minimum Information Security requirements and make a source
    selection recommendation;

10. Undergo appropriate training to qualify as a Contracting Officers
    Representative (COR) and serve as a COR as necessary;

11. Prior to implementing any software configuration changes, obtain
    approval of the applicable Configuration/Change Control Board or
    Architectural Review Board. If no board exists, consult with the
    OCIO, Chief Technical Officer on the proper course of action;

12. Prior to being moved into production, obtain approval of the
    applicable Technical Review Board, Configuration/Change Control
    Board or Architectural Review Board (ARB) for all software updates.
    Ensure the Independent Verification and Validation (IV&V) is
    performed. If no board exists, consult with the OCIO, Chief
    Technical Officer (CTO) on the proper course of action;

13. Ensure that periodic reviews of the project are conducted to
    ascertain whether Information Security has been maintained at the
    appropriate level and compliance with the Information Security
    Program continued after award. All instances of noncompliance should
    be reported to the Contracting Officer or designated representative,
    for necessary action; and

14. Conduct closeout activities, including return of all SBU information
    and information resources provided during the life of this contract
    at the expiration or completion of this contract.

##### 

##### 

##### Guidelines to Contracting Officer Tasks

1.  Support the Program Manager or System Owner during the requirements
    analysis phase by conducting market research and providing
    procurement planning assistance as needed;

2.  Review incoming SOWs and Performance Work Statements for IT-related
    acquisitions to ensure that Information Security has been addressed.
    If it has not, coordinate with the requisitioning party to ensure
    compliance with the DOI Information Security program;

3.  Include Information Security as an evaluation factor in IT-related
    acquisitions and ensure that Information Security interests are
    represented during the evaluation period; and

4.  Appoint Contracting Officer's Technical Representatives (COTRs) who
    are knowledgeable in Information Security. If appropriate, appoint
    special COTRs with authority limited to Information Security matters
    in addition to general COTRs.

5.  Guidelines to Information Security Personnel Tasks

6.  Support the Program Manager or Information System Owner during the
    requirements analysis phase by evaluating requirements and providing
    advice on appropriate security measures;

7.  Review proposed Statements of Work and Performance Work Statements
    to ensure that the resulting contracts sufficiently define
    Information Security requirements, provide a means to respond to
    Information Security issues, and include a right to terminate the
    contract if it can be shown that the contractor does not abide by
    the Information Security terms of the contract;

8.  Participate in evaluation of offers to ensure that Information
    Security requirements are adequately addressed;

9.  Approve contractors' Information security Certification and
    Accreditation (C&A) support documents in a timely manner;

10. Undergo appropriate training to qualify and serve as COTRs, as
    necessary.

##### Guidelines for Including Information Security Requirements in Contracts

The security requirements addressed the following table are required in
all RFPs, RFIs, SOWs, SORs, etc. that involve the development of an
information system or the use of DOI information resources, and must
include (but are not limited to) the following Information Security
requirements.

+---+--------+-----------+---------+----------------------------------+
|   | If you |           |         | Put this requirement in the      |
|   | are    |           |         | Statement of Work or constraint  |
|   | b      |           |         | in the Performance Work          |
|   | uying: |           |         | Statement:                       |
+---+--------+-----------+---------+----------------------------------+
|   | COTS   | De        | Out     |                                  |
|   | Ha     | velopment | sourced |                                  |
|   | rdware | or        | IT      |                                  |
|   | or     | Ma        | S       |                                  |
|   | So     | intenance | ervices |                                  |
|   | ftware | of Custom | or      |                                  |
|   |        | App       | On-site |                                  |
|   |        | lications | Support |                                  |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    |          |        | **Background Investigations.**   |
|   |        |           |         | Contractor employees who will    |
|   |        |           |         | have access to DOI information   |
|   |        |           |         | or will develop custom           |
|   |        |           |         | applications are subject to      |
|   |        |           |         | background investigations. The   |
|   |        |           |         | level/complexity of background   |
|   |        |           |         | investigations must be the same  |
|   |        |           |         | as for a federal employee        |
|   |        |           |         | holding a similar position;      |
|   |        |           |         | DM441, Chapter 3, provides       |
|   |        |           |         | guidance for the appropriate     |
|   |        |           |         | background investigations based  |
|   |        |           |         | on types of access. The          |
|   |        |           |         | solicitation and contract should |
|   |        |           |         | state the levels required for    |
|   |        |           |         | applicable labor categories or   |
|   |        |           |         | positions.                       |
|   |        |           |         |                                  |
|   |        |           |         | Ordinarily, the vendor should be |
|   |        |           |         | responsible for paying the cost  |
|   |        |           |         | the background investigations.   |
|   |        |           |         | Existing clearances at the same  |
|   |        |           |         | or higher levels may be          |
|   |        |           |         | accepted. The request forms      |
|   |        |           |         | should be included in the        |
|   |        |           |         | solicitation if possible. Work   |
|   |        |           |         | cannot begin on the DOI system   |
|   |        |           |         | until the background             |
|   |        |           |         | investigation has at least been  |
|   |        |           |         | initiated and the National       |
|   |        |           |         | Agency Check (NAC) is completed. |
+---+--------+-----------+---------+----------------------------------+
| 2 | N/A    |          |        | **Non-disclosure Agreement.**    |
|   |        |           |         | Contractor employees who will    |
|   |        |           |         | have access to DOI or Service    |
|   |        |           |         | information or will develop      |
|   |        |           |         | custom applications must sign a  |
|   |        |           |         | non-disclosure agreement prior   |
|   |        |           |         | to gaining access. Each          |
|   |        |           |         | agreement must be tailored to    |
|   |        |           |         | the contract. A draft or sample  |
|   |        |           |         | agreement may be included in     |
|   |        |           |         | solicitations. After award, the  |
|   |        |           |         | COR will develop the final       |
|   |        |           |         | agreements, with the assistance  |
|   |        |           |         | of the Solicitor.                |
+---+--------+-----------+---------+----------------------------------+
| 3 | N/A    |          |        | **Training.** Contractor         |
|   |        |           |         | employees must successfully      |
|   |        |           |         | complete DOI's end-user computer |
|   |        |           |         | security awareness training      |
|   |        |           |         | prior to being granted access to |
|   |        |           |         | DOI data or being issued a user  |
|   |        |           |         | account. Training must be        |
|   |        |           |         | renewed annually. Additionally,  |
|   |        |           |         | the contract employees must sign |
|   |        |           |         | a Statement of Responsibility    |
|   |        |           |         | (SOR) that states they have read |
|   |        |           |         | the appropriate Rules of         |
|   |        |           |         | Behavior and other applicable    |
|   |        |           |         | Information security policies.   |
+---+--------+-----------+---------+----------------------------------+
| 4 | N/A    | N/A       |        | **Personnel Changes.** The       |
|   |        |           |         | contractor must notify the COR   |
|   |        |           |         | immediately when an employee     |
|   |        |           |         | working on a DOI system is       |
|   |        |           |         | reassigned or leaves the         |
|   |        |           |         | contractor's employ. For         |
|   |        |           |         | unfriendly terminations, the COR |
|   |        |           |         | must be contacted PRIOR to the   |
|   |        |           |         | termination, as is practicable.  |
|   |        |           |         | The Bureau/Office Security       |
|   |        |           |         | Officer should also be notified. |
+---+--------+-----------+---------+----------------------------------+
| 5 | N/A    |          |        | **Contractor Location.** Custom  |
|   |        |           |         | software development and         |
|   |        |           |         | outsourced operations must be    |
|   |        |           |         | located in the United States to  |
|   |        |           |         | the maximum extent practical. If |
|   |        |           |         | such services are proposed to be |
|   |        |           |         | performed abroad, the contractor |
|   |        |           |         | must provide an acceptable       |
|   |        |           |         | security plan specifically to    |
|   |        |           |         | address mitigation of the        |
|   |        |           |         | resulting problems of            |
|   |        |           |         | communication, control, data     |
|   |        |           |         | protection, and so forth.        |
|   |        |           |         | Location within the U.S. may be  |
|   |        |           |         | an evaluation factor.            |
+---+--------+-----------+---------+----------------------------------+
| 6 | N/A    |          | N/A     | **Applicable Standards.**        |
|   |        |           |         | Contractors must follow the DOI  |
|   |        |           |         | System Development Life Cycle    |
|   |        |           |         | (SDLC), NIST SP 800-64 and the   |
|   |        |           |         | DOI SDLC Security Integration    |
|   |        |           |         | Guide. Solicitations must        |
|   |        |           |         | include either the complete      |
|   |        |           |         | publications or a reference to   |
|   |        |           |         | public facilities, such as a     |
|   |        |           |         | website or office, where they    |
|   |        |           |         | may be accessed.                 |
+---+--------+-----------+---------+----------------------------------+
| 7 | N/A    |          |        | **Security Categorization:** The |
|   |        |           |         | Contractor must use the FIPS 199 |
|   |        |           |         | and the NIST SP 800-60 for all   |
|   |        |           |         | systems to determine information |
|   |        |           |         | types and security               |
|   |        |           |         | categorization based on mission  |
|   |        |           |         | impact, data sensitivity, risk   |
|   |        |           |         | level, and bureau / departmental |
|   |        |           |         | / national criticality.          |
|   |        |           |         | Solicitations must include       |
|   |        |           |         | either the complete publication  |
|   |        |           |         | or a reference to public         |
|   |        |           |         | facilities, such as a website or |
|   |        |           |         | office, where it may be          |
|   |        |           |         | accessed.                        |
+---+--------+-----------+---------+----------------------------------+
| 8 | N/A    |          |        | **Property Rights.** DOI will    |
|   |        |           |         | own the intellectual property    |
|   |        |           |         | rights to any software developed |
|   |        |           |         | on its behalf to the maximum     |
|   |        |           |         | extent practical. Generally, FAR |
|   |        |           |         | 52.227-14, Rights in             |
|   |        |           |         | Data-General, and its alternates |
|   |        |           |         | will be used in the contract.    |
|   |        |           |         | However, deviation from this     |
|   |        |           |         | policy may be necessary as       |
|   |        |           |         | circumstances warrant.           |
+---+--------+-----------+---------+----------------------------------+
| 9 | N/A    |          |        | **IV&V.** Software updates must  |
|   |        |           |         | be independently verified and    |
|   |        |           |         | validated prior to being moved   |
|   |        |           |         | into production. The             |
|   |        |           |         | solicitation and contract should |
|   |        |           |         | be clear as to which party       |
|   |        |           |         | performs this function and is    |
|   |        |           |         | responsible for associated       |
|   |        |           |         | costs.                           |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    |          |        | **Certification and              |
| 0 |        |           |         | Accreditation.** Major           |
|   |        |           |         | Applications and General Support |
|   |        |           |         | Systems must be certified and    |
|   |        |           |         | accredited (C&A) prior to going  |
|   |        |           |         | into production and reaccredited |
|   |        |           |         | every three years or whenever    |
|   |        |           |         | there is a major change that     |
|   |        |           |         | affects security. C&A documents  |
|   |        |           |         | will be provided to the COR in   |
|   |        |           |         | both hard copy and electronic    |
|   |        |           |         | (specify) forms.                 |
|   |        |           |         |                                  |
|   |        |           |         | The contractor must follow NIST  |
|   |        |           |         | SP 800-37, 800-18, Rev.1,        |
|   |        |           |         | 800-30, 800-60 vol. 1 and vol.   |
|   |        |           |         | 2, 800-53, Rev.1 - Annex 1,      |
|   |        |           |         | Annex 2 and Annex 3, FIPS 199    |
|   |        |           |         | and FIPS 200, the associated DOI |
|   |        |           |         | guides/templates, the DOI        |
|   |        |           |         | Security Test & Evaluation       |
|   |        |           |         | (ST&E) Guide, and the DOI        |
|   |        |           |         | Privacy Impact Assessment.       |
|   |        |           |         | Solicitations must include       |
|   |        |           |         | either the complete publications |
|   |        |           |         | or a reference to public         |
|   |        |           |         | facilities, such as a website or |
|   |        |           |         | office, where they be accessed.  |
|   |        |           |         |                                  |
|   |        |           |         | The government will reserve the  |
|   |        |           |         | right to conduct the ST&E, using |
|   |        |           |         | either government personnel or   |
|   |        |           |         | an independent contractor.       |
|   |        |           |         |                                  |
|   |        |           |         | The contractor will take         |
|   |        |           |         | appropriate and timely action    |
|   |        |           |         | (this can be specified in the    |
|   |        |           |         | contract) to correct or mitigate |
|   |        |           |         | any weaknesses discovered during |
|   |        |           |         | such testing, generally at no    |
|   |        |           |         | additional cost.                 |
|   |        |           |         |                                  |
|   |        |           |         | The authorizing official         |
|   |        |           |         | (Designated                      |
|   |        |           |         | Approving/Accrediting Authority) |
|   |        |           |         | for the system will be the       |
|   |        |           |         | official identified in DOI       |
|   |        |           |         | Secretarial Order No. 3255.      |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    | N/A       |        | **Internet Logon Banner.** A     |
| 1 |        |           |         | DOI-approved internet logon      |
|   |        |           |         | banner must be displayed on the  |
|   |        |           |         | first page of any publicly       |
|   |        |           |         | accessible web pages owned by    |
|   |        |           |         | DOI. The information contained   |
|   |        |           |         | in the banner is standard and    |
|   |        |           |         | must be approved by DOI legal    |
|   |        |           |         | staff.                           |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    |          |        | **Incident Reporting.** The      |
| 2 |        |           |         | contractor must report computer  |
|   |        |           |         | security incidents affecting DOI |
|   |        |           |         | data or systems in accordance    |
|   |        |           |         | with the DOI Computer Incident   |
|   |        |           |         | Response Guide. Solicitations    |
|   |        |           |         | must include either the complete |
|   |        |           |         | publication or a reference to    |
|   |        |           |         | public facilities, such as a     |
|   |        |           |         | website or office, where it may  |
|   |        |           |         | be accessed.                     |
+---+--------+-----------+---------+----------------------------------+
| 1 |       |          |        | **Quality Control.** All         |
| 3 |        |           |         | software or hardware purchased   |
|   |        |           |         | must be free of malicious code   |
|   |        |           |         | such as viruses, Trojan horse    |
|   |        |           |         | programs, worms, spyware, etc.   |
|   |        |           |         | Validation of this must be       |
|   |        |           |         | written into the contract.       |
|   |        |           |         |                                  |
|   |        |           |         | Malicious code or malware is     |
|   |        |           |         | defined as software (or          |
|   |        |           |         | firmware) designed to damage or  |
|   |        |           |         | do other unwanted actions on a   |
|   |        |           |         | computer system. Examples of     |
|   |        |           |         | malware include viruses, worms,  |
|   |        |           |         | Trojan horses and spyware.       |
|   |        |           |         | Viruses, for example, can cause  |
|   |        |           |         | havoc on a computer's hard drive |
|   |        |           |         | by deleting files or directory   |
|   |        |           |         | information. Spyware can gather  |
|   |        |           |         | data from a user's system        |
|   |        |           |         | without the user knowing it.     |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    | N/A       |        | **Self Assessment.** The         |
| 4 |        |           |         | contractor must conduct an       |
|   |        |           |         | annual self assessment in        |
|   |        |           |         | accordance with annual DOI       |
|   |        |           |         | guidance on all information      |
|   |        |           |         | systems in production.           |
|   |        |           |         | Solicitations must either        |
|   |        |           |         | include the complete publication |
|   |        |           |         | or a reference to public         |
|   |        |           |         | facilities, such as a website or |
|   |        |           |         | office, where it may be          |
|   |        |           |         | accessed. Both hard copy and     |
|   |        |           |         | electronic copies of the         |
|   |        |           |         | assessment will be provided to   |
|   |        |           |         | the COR. The government will     |
|   |        |           |         | reserve the right to conduct     |
|   |        |           |         | such an assessment using         |
|   |        |           |         | government personnel or another  |
|   |        |           |         | contractor. The contractor will  |
|   |        |           |         | take appropriate and timely      |
|   |        |           |         | action (this can be specified in |
|   |        |           |         | the contract) to correct or      |
|   |        |           |         | mitigate any weaknesses          |
|   |        |           |         | discovered during such testing,  |
|   |        |           |         | generally at no additional cost. |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    |          |        | **Vulnerability Analysis** All   |
| 5 |        |           |         | systems must be scanned monthly  |
|   |        |           |         | with a vulnerability analysis    |
|   |        |           |         | tool that is compatible with the |
|   |        |           |         | software in use by the OCIO at   |
|   |        |           |         | the time (specify this in the    |
|   |        |           |         | solicitation). All "safe" or     |
|   |        |           |         | "non-destructive" checks must be |
|   |        |           |         | turned on. An electronic copy of |
|   |        |           |         | each report and session data     |
|   |        |           |         | will be provided to the COR.     |
|   |        |           |         |                                  |
|   |        |           |         | At least annually, all high and  |
|   |        |           |         | moderate risk impact systems and |
|   |        |           |         | systems accessible from the      |
|   |        |           |         | Internet must be independently   |
|   |        |           |         | penetration tested. Electronic   |
|   |        |           |         | and hard copy reports of         |
|   |        |           |         | penetration test results will be |
|   |        |           |         | provided to the COR.             |
|   |        |           |         |                                  |
|   |        |           |         | The government will reserve the  |
|   |        |           |         | right to conduct unannounced and |
|   |        |           |         | prearranged independent          |
|   |        |           |         | vulnerability scans using        |
|   |        |           |         | government personnel or another  |
|   |        |           |         | contractor.                      |
|   |        |           |         |                                  |
|   |        |           |         | The contractor will take         |
|   |        |           |         | appropriate and timely action    |
|   |        |           |         | (this can be specified in the    |
|   |        |           |         | contract) to correct or mitigate |
|   |        |           |         | any weaknesses discovered during |
|   |        |           |         | such testing, generally at no    |
|   |        |           |         | additional cost.                 |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    |          |        | **Logon Banner.** Contractor     |
| 6 |        |           |         | employees who access DOI         |
|   |        |           |         | information systems must         |
|   |        |           |         | acknowledge a                    |
|   |        |           |         | government-approved legal        |
|   |        |           |         | warning banner prior to logging  |
|   |        |           |         | on to the system. This includes  |
|   |        |           |         | contractor owned information     |
|   |        |           |         | systems hosting DOI data. The    |
|   |        |           |         | network warning banner           |
|   |        |           |         | communicates that there is no    |
|   |        |           |         | expectation of privacy in the    |
|   |        |           |         | authorized or unauthorized use   |
|   |        |           |         | of DOI information systems. The  |
|   |        |           |         | use of warning banners on DOI    |
|   |        |           |         | computers and networks provides  |
|   |        |           |         | legal notice to anyone accessing |
|   |        |           |         | them that they are using a U.S.  |
|   |        |           |         | Government system that is        |
|   |        |           |         | subject to monitoring. Users     |
|   |        |           |         | should also be notified of the   |
|   |        |           |         | possible sanctions, such as loss |
|   |        |           |         | of privileges or prosecution, if |
|   |        |           |         | they misuse or access the        |
|   |        |           |         | network without authorization.   |
|   |        |           |         | All DOI systems must display     |
|   |        |           |         | warning banners upon connection  |
|   |        |           |         | to such system. These banners    |
|   |        |           |         | will display a warning that      |
|   |        |           |         | states the system is for         |
|   |        |           |         | legitimate use only, is subject  |
|   |        |           |         | to monitoring, and carries no    |
|   |        |           |         | expectation of privacy. DOI      |
|   |        |           |         | networks and information systems |
|   |        |           |         | do not inherently provide users  |
|   |        |           |         | a right of privacy. As such, the |
|   |        |           |         | DOI reserves the right to        |
|   |        |           |         | monitor use in accordance with   |
|   |        |           |         | Information Security Program     |
|   |        |           |         | policies. System Owners must     |
|   |        |           |         | notify users of monitoring prior |
|   |        |           |         | to system access to avoid any    |
|   |        |           |         | question about an implied right  |
|   |        |           |         | to privacy on the system. The    |
|   |        |           |         | information contained in the     |
|   |        |           |         | banners is standard and must be  |
|   |        |           |         | approved by DOI's legal staff.   |
|   |        |           |         | All DOI computers, workstations, |
|   |        |           |         | laptops and other information    |
|   |        |           |         | resources will display a         |
|   |        |           |         | standard, DOI approved legal     |
|   |        |           |         | banner.                          |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    |          |        | **Security Controls.**           |
| 7 |        |           |         | Contractors will be required to  |
|   |        |           |         | ensure compliance with the       |
|   |        |           |         | security control requirements of |
|   |        |           |         | the current version of NIST SP   |
|   |        |           |         | 800-53, Rev.1, which are         |
|   |        |           |         | applicable to the security       |
|   |        |           |         | categorization of the data or    |
|   |        |           |         | system. FIPS 199 and the NIST SP |
|   |        |           |         | 800-60 will be used to determine |
|   |        |           |         | information types and security   |
|   |        |           |         | categorizations. Solicitations   |
|   |        |           |         | must include either the complete |
|   |        |           |         | publication or a reference to    |
|   |        |           |         | public facilities, such as a     |
|   |        |           |         | website or office, where they    |
|   |        |           |         | may be accessed.                 |
+---+--------+-----------+---------+----------------------------------+
| 1 | N/A    | N/A       |        | **Contingency Plan.** The        |
| 8 |        |           |         | contractor will submit a         |
|   |        |           |         | contingency plan in accordance   |
|   |        |           |         | with NIST SP 800-34 and the DOI  |
|   |        |           |         | Contingency Plan Guide.          |
|   |        |           |         | Solicitations must include       |
|   |        |           |         | either the complete publications |
|   |        |           |         | or a reference to public         |
|   |        |           |         | facilities, such as a website or |
|   |        |           |         | office, where they may be        |
|   |        |           |         | accessed. The plan must be       |
|   |        |           |         | approved by the COR. A copy of   |
|   |        |           |         | the annual test results will be  |
|   |        |           |         | provided to the COR.             |
+---+--------+-----------+---------+----------------------------------+

[]{#__RefHeading___Toc193514853 .anchor}Table 81: Guidelines for
Including Information Security Requirements in Contracts

##### Processing Performed at Contractor Facilities

The security requirements for processing DOI sensitive data at
non-government agencies are the same as for government agencies. The
location of the processing facilities does not impact the required
security provisions for protecting DOI information and systems.

## PS-8 -- Personnel Sanctions 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall employ a formal sanctions process for
personnel failing to comply with established information security
policies and procedures established by their Human Resources Office.

#### Policy Supplement(s):

PS-8(a)

Violations of IT Security policy may result in disciplinary action,
including dismissal and legal action against the offending employee(s),
contractors, or visitors, consistent with law and with DM 370,
Discipline and Adverse Actions, or contract terms as applicable.

# Risk Assessment (RA)

*Risk* measures the level of impact on agency operations (including
mission, functions, image, or reputation), agency assets, or individuals
resulting from the operation of an information system given the
potential impact of a threat and the likelihood of that threat
occurring. *Risk management* is the ongoing process of managing risks to
agency operations (including mission, functions, image, or reputation),
agency assets, or individuals resulting from the operation of an
information system. It includes *risk assessment*; the selection,
implementation, and assessment of cost-effective security controls; and
the formal authorization to operate the system. The process considers
effectiveness, efficiency, and constraints due to laws, directives,
policies, or regulations. National Institute of Standards and Technology
(NIST) defines risk assessment as the process of identifying risks to
agency operations (including mission, functions, image, or reputation),
agency assets, or individuals by determining the probability of
occurrence, the resulting impact, and additional security controls that
would mitigate this impact.

Bureaus and offices shall ensure that System Owners comply with the NIST
Special Publication 800-53, Rev.1, *Recommended Security Controls for
Federal Information Systems* controls listed in the following table for
risk assessment of all DOI IT general support systems and major
applications under their responsibility.

+--------+--------------------+-------------+--------+---------------+
|  Risk  |                    |             |        |               |
| Asse   |                    |             |        |               |
| ssment |                    |             |        |               |
+--------+--------------------+-------------+--------+---------------+
|        |                    | Control     |        |               |
|        |                    | Baselines   |        |               |
| C      | Control Name       |             |        |               |
| ontrol |                    |             |        |               |
| Number |                    |             |        |               |
+--------+--------------------+-------------+--------+---------------+
|        |                    | Low         | Mo     | High          |
|        |                    |             | derate |               |
+--------+--------------------+-------------+--------+---------------+
| RA-1   | Risk Assessment    | RA-1        | RA-1   | RA-1          |
|        | Policy and         |             |        |               |
|        | Procedures         |             |        |               |
+--------+--------------------+-------------+--------+---------------+
| RA-2   | Security           | RA-2        | RA-2   | RA-2          |
|        | Categorization     |             |        |               |
+--------+--------------------+-------------+--------+---------------+
| RA-3   | Risk Assessment    | RA-3        | RA-3   | RA-3          |
+--------+--------------------+-------------+--------+---------------+
| RA-4   | Risk Assessment    | RA-4        | RA-4   | RA-4          |
|        | Update             |             |        |               |
+--------+--------------------+-------------+--------+---------------+
| RA-5   | Vulnerability      | RA-5        | RA-5   | RA-5 (1) (2)  |
|        | Scanning           |             | (1)    |               |
|        |                    |             | (2)    |               |
+--------+--------------------+-------------+--------+---------------+

[]{#__RefHeading___Toc193514854 .anchor}Table 82: Risk Assessment
Controls

## RA-1 -- Risk Assessment Policy and Procedures

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically
review/update:

1.  Formal risk assessment policy that addresses purpose, scope, roles,
    responsibilities, and compliance; and

2.  Formal procedures to facilitate the implementation of the risk
    assessment policy and associated risk assessment controls.

### RA-1 DOI Risk Assessment Methodology

Bureaus and offices shall have a risk management process in place that
follows the methodology and reporting format defined by National
Institute of Standards and Technology (NIST) Special Publication 800-30,
*Risk Management Guide for Information Technology Systems*.

In addition, if the system uses electronic authentication methods to
provide remote access services, the risk assessment must include an
e-authentication risk assessment compliant with OMB Memorandum 04-04,
*E-Authentication Guidance*.

## RA-2 -- Security Categorization

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems and the
information processed, stored, or transmitted by the system are
categorized in accordance with FIPS 199, *Standards for Security
Categorization of Federal Information and Information Systems* and NIST
Special Publication 800-60, *Guide for Mapping Types of Information and
Information Systems to Security Categories*, *Volume I and Volume II*.

#### Policy Supplement(s):

RA-2(a)

Designated senior-level officials identified as AOs/DAAs within the
bureau or office shall review and approve the security categorizations.

#### Additional Policy Guidance:

Bureaus and offices should consider partitioning higher-impact
information systems into separate physical domains (or environments) and
restricting or prohibiting network access in accordance with an
assessment of risk.

### RA-2 Analyzing System and Information Security Category Impact Levels 

[]{#levels_and_types .anchor}

During the system risk assessment, the System Owner must determine the
sensitivity or reaction of the agency's mission to compromises of
confidentiality, integrity, and availability of the information stored
and processed by the system. This determination, along with the
likelihood of compromise occurring and the extent of protection required
by law, establishes the level of security adequate to protect the data
as required by OMB Circular A-130, Appendix III. The System Owner then
identifies the management, technical, and operational controls
appropriate to provide the required protection.

System owners shall:

1.  Understand and use the criteria contained in Federal Information
    Processing Standard (FIPS) 199, *Standards for Security
    Categorization of Federal Information and Information Systems*, and
    companion publication, NIST Special Publication 800-60, *Guide for
    Mapping Types of Information and Information Systems to Security
    Categories*, *Volume I and Volume II*;

2.  Establish and document each information type and the security
    category (SC) for each information type; and

3.  Establish the security categorization for the information system.

The Data Owners and System Owners must work together to ensure that
appropriate [controls](#controls) are in place and functioning to
provide an adequate level of security to the extent authorized by law.
Once the security categorization for the system is determined bureaus
and offices shall refer to this policy to develop acceptable control
baselines appropriate to the system's impact level.

### RA-2 Sensitive Information 

Bureaus and offices shall consider the sensitivity of information as a
critical categorization element for all risk assessments.

The Office of Management and Budget (OMB) Circular A-130, Appendix III,
*Security of Federal Automated Information Resources*, states that there
is a "presumption that all \[systems\] contain some sensitive
information." The 15 USC Sec. 278-g3[^12] provides the following
definition of the term *sensitive* information:

> *"...any information, the loss, misuse, or unauthorized access to or
> modification of which could adversely affect the national interest or
> the conduct of federal programs, or the privacy to which individuals
> are entitled under section 552a of Title 5, United States Code (the
> Privacy Act), but which has not been specifically authorized under
> criteria established by an Executive Order or an Act of Congress to be
> kept secret in the interest of national defense or foreign policy."*

Protecting *sensitive* information, including For Official Use Only
(FOUO), and information protected by the Privacy Act, which includes
PII, typically means ensuring the protection of one or more of the
following:

##### Co**n**fidentiality -- 

Disclosure of the information must be restricted to only those parties
allowed by the disclosure requirements of the Privacy Act (see DOI
Privacy Act regulations at 43 CFR 2.56 or the Privacy Act at 5 U.S.C.
552a(b)). Certain disclosure according to the regulations and laws are
limited to the purpose and use identified in the Privacy Act system of
records notice published in the Federal Register to ensure privacy of
personal information and non-publication of sensitive mission data.

##### Integrity -- 

The information must be protected from errors or unauthorized
modification.

##### Availability --  {#availability-1}

The information must be available within some given timeframe (i.e.,
protected against destruction).

Bureaus and offices shall ensure that the maintenance, protection and
disclosure of sensitive information shall be in accordance with
applicable laws, federal standards and guidance, and departmental
requirements. Bureaus and offices shall reference Information Protection
Measures, for DOI policy for the protection of sensitive information.

### RA-2 Personally Identifiable Information

Bureaus and offices shall consider the utilization of PII as a critical
categorization element for all risk assessments.

OMB Memorandum M-06-15 requires a review of the Department's policy and
procedures to ensure that adequate safeguards are in place. Any
weaknesses identified must be included in security plans of action and
milestones already required by FISMA.

1.  Being able to identify systems that maintain personally identifiable
    information within the organization is the first step in ensuring
    that appropriate requirements are in place for them. System managers
    responsible for the administration of these systems must apply the
    appropriate safeguards required in the checklist to the systems that
    house Personally Identifiable Information (PII).

2.  There may be some systems that maintain personally identifiable
    information that may not trigger the Privacy Act.

3.  Ensure that special attention is given to required training. The
    Office of the Chief Information Officer has developed three
    computer-based-training (CBT) modules on Cyber Security, Records
    Management and the Privacy Act which all employees and contractors
    are required to take this training. Please take steps to ensure that
    your organization is 100% compliant. Provide the percentage
    completion for your organization for the three CBTs in your
    memorandum.

4.  Report the date when all contracts that involve the contractor's
    handling of Privacy Act information will be reviewed to ensure that
    contracts include the required Privacy Act clauses required by the
    Federal Acquisition Regulations (FAR) and the Department of the
    Interior (DIAR) Acquisition regulations. (See FAR 52.224 1and
    Privacy Act Notification at FAR 24.104(a), supplemental information
    at DIAR 1452.224 1, and 43 CFR 2.53).

5.  Report the date when a review would be completed of contracts that
    generate records as a result of contractual obligations and that are
    properly identified and included in the agency's official
    recordkeeping system. Notify Bureau Records Officers of this.

6.  Report the date when MOUs, data sharing agreements, and other
    agreements will be reviewed to ensure that they address roles and
    responsibilities for implementing information management
    requirements (privacy, security, FOIA, records, etc.). Often these
    responsibilities are not included and are essential to ensure
    compliance with Government laws and guidelines.

Report that a review of bureau/office telework policy was done to ensure
it is consistent with that issued by Personnel Bulletin No. 05-02 on
February 18, 2005. Special attention should be given to sections 3.1 Q.
on "Security and Liability Issues"; 3.1.S. on "Privacy Act
Considerations"; 3.1. U. on "Recordkeeping Requirements"; and compliance
with items on records, privacy and security in the telework agreement.
Identify the date of when changes will be made to the bureau/office
telework policy to ensure they are consistent with the Personnel
Bulletin.

Per the September 8, 2006 memorandum, bureaus and offices are required
to ensure FIPS 140-2 validated encryption of all mobile media and
devices (e.g., removable media, portable/mobile devices, remote
workstations, etc.) containing agency data taken outside of the Agency's
secured physical perimeter (e.g., to a personal residence, on either
business or personal travel -- even if traveling to another controlled
facility, etc.), unless the data is determined to be non-sensitive, in
writing, by the Deputy Secretary or an individual designated in writing
by the Deputy Secretary.

As a mitigation to the risks associated with the potential loss or theft
of PII or Department sensitive information, bureaus and offices that
currently do not have an encryption solution for mobile devices (e.g.,
laptops and remote workstations/servers) are minimally required to take
the following actions until an Enterprise-wide encryption solution can
be procured:

-   implement the Encrypting File System (EFS), or equivalent, for
    Windows-based systems;

-   implement FileVault, or equivalent, for Macintosh-based systems; and

-   for other operating systems, bureaus and offices must identify and
    implement an appropriate solution to provide file-level encryption
    at a minimum.

##### Secondary Warning Banners

A standard secondary Message Banner for deployment on all remote access
points was developed by the Encryption Working Group (EWG) and has been
approved by the Solicitor's Office. Bureaus and offices are required to
have equivalent language to the following standard elements, or
incorporate those elements into their existing Rules of Behavior (RoB),
to address the protection of PII and sensitive data, Remote Access, and
mobile computing device usage. The Solicitor's Office has approved the
following standard RoB elements developed by the EWG after a thorough
review by the Human Resources Office and a representative subset of
government worker Unions:

> **WARNING - Before you download Department of the Interior (DOI) data
> to a computer or any other device capable of storing electronic data
> you must comply with DOI standards for data encryption and system
> security. You must also understand and agree to comply with DOI
> requirements for deleting the data. Contact your Bureau Chief
> Information Security Officer for specifications regarding these
> standards and requirements. Failure to comply may result in criminal,
> civil, and/or disciplinary action.**

Special Considerations for Remote Access - Access of agency resources
from a location not under the direct control of the ESN or {bureau or
office name} is considered "Remote Access". New technical solutions are
being implemented to secure and protect agency data, especially if it is
being carried outside of the ESN or {bureau or office name}'s physically
protected areas. With these new requirements also come new
responsibilities for user behavior regarding the protection of agency
data. Users must secure and protect agency data as follows:

Users must physically protect all hardware or software based tokens
entrusted to them for authentication or encryption purposes. (A token is
usually a physical device that an authorized user is given to provide
additional higher level security and to verify the user is who they say
they are when logging in to the network.)

-   **Users must encrypt all agency data stored on any equipment,
    including but not limited to computers, external hard drives, PDAs,
    and thumb/flash drives, anytime they are outside of {bureau or
    office name} protected facilities.**

-   **Users must ensure that all agency data downloaded using remote
    access is erased after 90 days or when it is no longer needed.**

-   **Users should refer to their Bureau Chief Information Security
    Officer for standards and approved methods for encrypting and
    deleting data.**

##### Special Considerations for Remote Access 

Access of agency resources from a location not under the direct control
of the ESN or {bureau or office name} is considered "Remote Access." New
technical solutions are being implemented to secure and protect agency
data, especially if it is being carried outside of the ESN or bureau or
office name's physically protected areas. With these new requirements
also come new responsibilities for user behavior regarding the
protection of agency data. Users must secure and protect agency data as
follows:

-   Users must physically protect all hardware or software based tokens
    entrusted to them for authentication or encryption purposes. (A
    token is usually a physical device that an authorized user is given
    to provide additional higher level security and to verify the user
    is who they say they are when logging in to the network.)

-   Users must encrypt all agency data stored on any equipment,
    including but not limited to computers, external hard drives, PDAs,
    and thumb/flash drives, anytime they are outside of {bureau or
    office name} protected facilities.

-   Users must ensure that all agency data downloaded using remote
    access is erased after 90 days or when it is no longer needed.

-   Users should refer to their Bureau Chief Information Security
    Officer for standards and approved methods for encrypting and
    deleting data."

Bureaus and offices not having implemented the requirements specified in
the previous memorandum by September 30, 2006 were to develop, maintain,
and revise as necessary Plans of Action and Milestones (POA&Ms). To
assist bureaus and offices, the Department's Cyber Security Division
(CSD) developed standard POA&M elements to be included in the
Department's POA&M, as well as POA&M template elements to be
incorporated by each bureau and office in their respective Program- or
system-level POA&Ms as each bureau deems most appropriate.

OMB memorandum M-06-16 requires determinations of non-sensitive data to
be in writing by the Deputy Secretary, or an individual designated in
writing by the Deputy Secretary, in order to waive the encryption
requirements on specific mobile devices. On August 3, 2006, the Deputy
Secretary delegated this authority to the Department CIO and restricted
further delegation of this authority. To enable the CIO to accurately
evaluate requests for determination of non-sensitive data in a system,
the "Request for Determination of Non-Sensitive Data" request template
shall be used. The signature of the Designated Approving/Accrediting
Authority (DAA) on the request shall be the senior management official,
within the requesting bureau or office, designated as the DAA
responsible for risk acceptance and accreditation of the Certification
and Accreditation (C&A) information system boundary with which the
mobile computing devices are associated.

## RA-3 -- Risk Assessment

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall conduct assessments of the risk and magnitude
of harm that could result from the unintentional and/or unauthorized
access, use, disclosure, disruption, modification, or destruction of
information and information systems that support the operations and
assets of the agency (including information and information systems
managed/operated by external parties).

#### Policy Supplement(s):

RA-3(a)

Risk assessments shall take into account vulnerabilities, threat
sources, and security controls planned or in place to determine the
resulting level of residual risk posed to bureau or office operations,
assets, or individuals based on the operation of the information system.

RA-3(b)

Risk assessments shall also take into account any risk posed to bureau
or office operations, assets, or individuals from external parties
(e.g., service providers, contractors operating information systems on
behalf of the organization, individuals accessing organizational
information systems, outsourcing entities).

RA-3(c)

In accordance with OMB policy and related E-authentication initiatives,
authentication of public users accessing federal information systems may
also be required to protect nonpublic or privacy-related information. As
such, bureaus and offices assessments of risk shall address public
access to federal information systems.

### RA-3 Risk Assessments Frequency

Bureaus and offices shall ensure that a complete risk assessment is
performed on all information systems at least every 3 years, or upon
significant change to the system. Bureaus and offices may acquire a
third-party to conduct the assessment.

### RA-3 Conducting the Risk Assessment

NIST Special Publication 800-30, *Risk Management Guide for Information
Technology Systems* provides guidance on conducting risk assessments
including threat, vulnerability, and impact assessments. The risk
assessment results identify and verify the controls in place, and
evaluate whether they provide adequate security for the information
system and reduce the level of risk acceptable to the Authorizing
Official. If risks are identified that are unacceptable to the
Authorizing Official, the risk assessment should identify additional
control needs, provide cost-effective recommendations for mitigation,
and determine resources to implement corrective action.

DOI [**does** **not**]{.underline} require that minor, readily
correctable weaknesses (e.g., on-the-spot corrections and those
completed prior to the operation and maintenance phase of a system) or
weaknesses considered by the Authorizing Official to be acceptable
residual risk be tracked by the System Owner on a Plan of Action and
Milestones (POA&M).

However, DOI **[does]{.underline}** require that weaknesses of a
significant nature and those not readily corrected -- for example, those
identified in the IT System Security Plan as "planned" and those
explicitly identified by the authorizing official in their accreditation
decision letter -- must be tracked on a system-level POA&M.

## RA-4 -- Risk Assessment Update

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall update risk assessments annually or whenever
there are significant changes to information systems, the facilities
where the system resides, or other conditions that may impact the
security or accreditation status of the system.

### RA-4 Significant Change

Significant change is defined as a change that alters, impacts, or
modifies the resulting security categorization of the information
system, initially expressed as:

**SC** information type = {(confidentiality, impact), (integrity,
impact), (availability, impact)},

where the acceptable values for potential impact are LOW, MODERATE,
HIGH, or NOT APPLICABLE.

Examples of significant changes to an information system that should be
reviewed for possible reaccreditation include but are not limited to:
(i) installation of a new or upgraded operating system, middleware
component, or application; (ii) modifications to system ports,
protocols, or services; (iii) installation of a new or upgraded hardware
platform or firmware component; or (iv) modifications to cryptographic
modules or services. Changes in laws, directives, policies, or
regulations, while not always directly related to the information
system, can also potentially affect the security of the system and
trigger a reaccreditation action.

## RA-5 -- Vulnerability Scanning

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall perform scans for vulnerabilities at least
every thirty days or when significant new vulnerabilities affecting the
system are identified and reported.

Bureaus and offices shall perform annual penetration testing of all High
and Moderate impact information systems. Only authorized personnel are
permitted to perform penetration testing. Any requirement for
penetration testing will be forwarded to the Bureau's IT Security
Operations Team for approval. Penetration testing assesses the system's
ability to withstand intentional attempts to circumvent system security
features by exploiting technical security vulnerabilities. Penetration
testing may include insider and outsider penetration attempts, both
physical and logical, based on common vulnerabilities for the technology
being used and the facility in which it is housed. Penetration testing
activities shall be performed in accordance with the NIST SP 800-42,
*Guideline on Network Security Testing*.

#### Mandatory Policy Enhancement(s):

  ------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                          APPLICABLITY   

                                                    MODERATE       HIGH

  \(1\) Bureaus and offices shall employ            X              X
  vulnerability scanning tools that include the                    
  capability to readily update the list of                         
  information system vulnerabilities scanned.                      

  \(2\) Bureaus and offices shall update the list   X              X
  of information system vulnerabilities **scanned                  
  monthly** or when significant new vulnerabilities                
  are identified and reported.                                     
  ------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514855 .anchor}Table 83: RA-5 Vulnerability
Scanning Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(3\) Bureaus and offices should consider          X              X
  employing vulnerability scanning procedures that                  
  can demonstrate the breadth and depth of scan                     
  coverage, including vulnerabilities checked and                   
  information system components scanned.                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514856 .anchor}Table 84: RA-5 Vulnerability
Scanning Recommended Policy Enhancement(s)

#### Policy Supplement(s):

RA-5(a)

Bureaus and offices shall ensure that selected personnel to perform
vulnerability scans are trained in the use and maintenance of
vulnerability scanning and penetration testing tools and techniques.

RA-5(b)

Information obtained from the vulnerability scanning process should be
freely shared with other bureaus and offices throughout the department
to help eliminate similar vulnerabilities in other information systems.

### RA-5 Internal Scanning Programs

Bureaus and offices shall develop internal scanning programs with
regular reporting schedules. Bureaus and offices shall scan all IP
addressable devices and services (including applications) included in
the information systems C&A boundary, including:

1.  Servers

2.  Workstations (PCs and PDAs, regardless of OS, device type, and
    interface)

3.  Databases

4.  Web Applications

5.  DNS Services

6.  Printers

7.  Firewalls

8.  Routers and Switches

### RA-5 Penetration Testing Guidelines

Penetration testing is security testing in which evaluators attempt to
circumvent the security features of a system based on their
understanding of the system design and implementation. The purpose of
penetration testing is to identify methods of gaining access to a system
by using common tools and techniques used by attackers. Penetration
testing should be performed after careful consideration, notification,
and planning.

Bureaus and offices are required to perform annual penetration testing
on Moderate and High impact information systems to uncover
vulnerabilities before they are exploited by attackers. Prior to the
beginning of any penetration test, bureaus and offices should file a
schedule of planned test activities with the DOI-CIRC and appropriate
bureau level operational staff and others, as appropriate, depending on
the scope of the scanning activities.

##### Penetration Testing Rules of Engagement

Bureaus and offices shall comply with the following rules of engagement
when performing internal penetration testing on information systems,
either by DOI personnel or an independent testing/audit team:

1.  Penetration testing shall be conducted using only reasonably
    available tools and should be based on the type of threat posed to
    the target. Bureaus shall refer to NIST Special Publication 800-42,
    *Guideline on Network Security Testing*, for penetration testing
    guidance and tools.

2.  A Rules of Engagement (RoE) must be developed in accordance with
    NIST SP 800-42 and approved by the BCISO prior to the start of
    penetration testing activities.

3.  System Owners, System Security Officers and BCISOs shall be notified
    prior to any internal scanning activities beginning.

4.  Testers from any external testing entities shall sign the
    appropriate RoE and non-disclosure agreements prior to beginning any
    scanning activities.

5.  Publicly available information may be provided to the testing team
    in advance.

6.  External entities shall not be allowed special access to facilities,
    work space or information systems.

7.  When possible, penetration testing shall be conducted during periods
    of low, to no, user activity.

8.  Penetration testing activities shall start with the least intrusive
    attempt methods and increase in intensity as the testing progresses.

9.  If penetration attempts are successful, bureaus and offices shall
    establish a secure shell encryption path or "tunnel" between the
    analysis point and the network under test to prevent exposure or
    exploitation by persons not involved with the testing process. The
    encrypted "tunnel" will be established prior to proceeding with any
    further testing.

10. Any data collected from testing shall be protected in accordance
    with DOI policy as determined by its data sensitivity
    categorization.

11. All test data, to include any logs, files, passwords must be
    protected and returned to the information system owner when testing
    is complete. If testing is being performed by an external entity,
    retention of this data should be prohibited by bureaus and offices.

12. A Penetration Test Report, detailing vulnerabilities identified
    during penetration testing, shall be provided to the System Owners
    and System Security Officers.

# System and Services Acquisition (SA)

Bureaus and offices shall comply with the NIST Special Publication
800-53, Rev.1, *Recommended Security Controls for Federal Information
Systems,* system and services acquisition controls listed in the
following table:

+----------+-----------------------+------------+------------+---------+
|  System  |                       |            |            |         |
| and      |                       |            |            |         |
| Services |                       |            |            |         |
| Acq      |                       |            |            |         |
| uisition |                       |            |            |         |
+----------+-----------------------+------------+------------+---------+
|          |                       | Control    |            |         |
|          |                       | Baselines  |            |         |
| Control  | Control Name          |            |            |         |
| Number   |                       |            |            |         |
+----------+-----------------------+------------+------------+---------+
|          |                       | Low        | Moderate   | High    |
+----------+-----------------------+------------+------------+---------+
| SA-1     | System and Services   | SA-1       | SA-1       | SA-1    |
|          | Acquisition Policy    |            |            |         |
|          | and Procedures        |            |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-2     | Allocation of         | SA-2       | SA-2       | SA-2    |
|          | Resources             |            |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-3     | Life Cycle Support    | SA-3       | SA-3       | SA-3    |
+----------+-----------------------+------------+------------+---------+
| SA-4     | Acquisitions          | SA-4       | SA-4 (1)   | SA-4    |
|          |                       |            |            | (1)     |
+----------+-----------------------+------------+------------+---------+
| SA-5     | Information System    | SA-5       | SA-5 (1)   | SA-5    |
|          | Documentation         |            |            | (1) (2) |
+----------+-----------------------+------------+------------+---------+
| SA-6     | Software Usage        | SA-6       | SA-6       | SA-6    |
|          | Restrictions          |            |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-7     | User Installed        | SA-7       | SA-7       | SA-7    |
|          | Software              |            |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-8     | Security Engineering  | Not        | SA-8       | SA-8    |
|          | Principles            | Selected   |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-9     | External Information  | SA-9       | SA-9       | SA-9    |
|          | System Services       |            |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-10    | Developer             | Not        | Not        | SA-10   |
|          | Configuration         | Selected   | Selected   |         |
|          | Management            |            |            |         |
+----------+-----------------------+------------+------------+---------+
| SA-11    | Developer Security    | Not        | SA-11      | SA-11   |
|          | Testing               | Selected   |            |         |
+----------+-----------------------+------------+------------+---------+

[]{#__RefHeading___Toc193514857 .anchor}Table 85: System and Services
Acquisition Controls

## SA-1 -- System and Services Acquisition Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, system and services acquisition policy that
    addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the system and services acquisition policy and associated system and
    services acquisition controls.

### SA-1 Acquisition of Security-Related Products and Services Considerations

BCISOs, System Owners, Contracting Officers, Contracting Officers
Representatives, and others involved in aspects of system security must
follow a methodology consistent with National Institute of Standards and
Technology (NIST) Special Publication 800-64, *Security Considerations
in the Information System Development Life Cycle* and the DOI *System
Development Life Cycle (SDLC) Security Integration Guide*. This
methodology ensures that IT security is addressed in the acquisition
process.

## SA-2 -- Allocation of Resources

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall determine, document, and allocate the
resources required to adequately protect information systems as part of
the department's capital planning and investment control process.

#### Policy Supplement(s):

SA-2(a)

Bureaus and offices shall include the determination of security
requirements for the information system in mission/business case
planning and establishes a discrete line item for information system
security in the organization's programming and budget documentation.

### SA-2 IT System Finding Considerations

The system life cycle requires consideration of IT security in the
budget request. All bureau and office CIOs must comply with the
Department's capital asset budget planning process and follow a
methodology consistent with NIST Special Publication 800-65,
*Integrating IT Security into the Capital Planning and Capital
Investment Control Process*. Office of Management and Budget (OMB)
Circular A-11, especially Part 7, as well as OMB memorandum *M-00-07,
Incorporating and Funding Security in Information Systems Investments*,
require that security be built into and funded as part of the system
architecture.

Bureau and office CIOs must make security\'s role explicit in IT
investments and capital programming. The funding must include all
products, procedures, and personnel (federal employees and contractors)
that are primarily dedicated to or used for provision of IT security for
the specific IT investment. Accordingly, investments in the development
of new or the continued operation of existing information systems, both
general support systems and major applications, proposed for funding in
the President\'s budget must:

1.  Be tied to the DOI IT architecture;

2.  Be well-planned;

3.  Manage risk;

4.  Protect privacy and confidentiality; and

5.  Account for departures from NIST guidance.

## SA-3 -- Life Cycle Support

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall manage all information systems using a system
development life cycle methodology that includes information security
considerations as documented in NIST SP 800-64, *Security Considerations
in the Information System Development Life Cycle*.

### SA-3 IT System Life Cycle Phases 

The formal process of securing an IT system must begin as soon as a
System Owner identifies requirements for an IT system. The System Owner,
with guidance and support of the BCISO, Bureau or office CIO, and other
security-focused authorities within the organization, can then begin
developing the System Security Plan and start integrating security,
through the required C&A activities, into all stages of the life cycle
of the DOI IT system. The life cycle consists of five (5) phases, which
are explained in the following table:

+----------------------+-----------------------+-----------------------+
| SDLC Phases          | Phase Characteristics | Support from Risk     |
|                      |                       |                       |
|                      |                       | Management Activities |
+----------------------+-----------------------+-----------------------+
| Phase 1---Initiation | The need for an IT    | Identified risks are  |
|                      | system is expressed   | used to               |
|                      | and the purpose and   |                       |
|                      | scope of the IT       | support the           |
|                      | system is documented  | development of the    |
|                      |                       | system requirements,  |
|                      |                       | including security    |
|                      |                       | requirements, and a   |
|                      |                       | security concept of   |
|                      |                       | operations (strategy) |
+----------------------+-----------------------+-----------------------+
| Phase                | The IT system is      | The risks identified  |
| 2---Development or   | designed,             | during this phase can |
|                      |                       | be used to support    |
| Acquisition          | purchased,            | the security analyses |
|                      | programmed,           | of the IT system that |
|                      |                       | may lead to           |
|                      | developed, or         | architecture and      |
|                      | otherwise             | design tradeoffs      |
|                      |                       | during system         |
|                      | constructed           | development           |
+----------------------+-----------------------+-----------------------+
| Phase                | The system security   | The risk management   |
| 3---Implementation   | features should be    | process supports the  |
|                      | configured, enabled,  | assessment of the     |
|                      | tested, and verified  | system implementation |
|                      |                       | against its           |
|                      |                       | requirements and      |
|                      |                       | within its            |
|                      |                       |                       |
|                      |                       | modeled operational   |
|                      |                       | environment.          |
|                      |                       | Decisions regarding   |
|                      |                       | risks identified must |
|                      |                       | be made prior to      |
|                      |                       | system operation      |
+----------------------+-----------------------+-----------------------+
| Phase 4---Operation  | The system performs   | Risk management       |
| or Maintenance       | its                   | activities are        |
|                      |                       | performed for         |
|                      | functions. Typically  | periodic system       |
|                      | the system is being   | reauthorization (or   |
|                      | modified on an        |                       |
|                      | ongoing basis through | reaccreditation) or   |
|                      | the addition of       | whenever major        |
|                      | hardware and software | changes are made to   |
|                      | and by changes to     | an IT system in its   |
|                      | organizational        | operational,          |
|                      | processes, policies,  | production            |
|                      | and procedures        | environment (e.g.,    |
|                      |                       | new system            |
|                      |                       | interfaces)           |
+----------------------+-----------------------+-----------------------+
| Phase 5---Disposal   | This phase may        | Risk management       |
|                      | involve the           | activities            |
|                      | disposition of        |                       |
|                      | information,          | are performed for     |
|                      | hardware, and         | system components     |
|                      | software. Activities  | that will be disposed |
|                      | may include moving,   | of or replaced to     |
|                      | archiving,            | ensure that the       |
|                      | discarding, or        | hardware and software |
|                      | destroying            | are properly disposed |
|                      | information and       | of, that residual     |
|                      | sanitizing the        | data is appropriately |
|                      | hardware and software | handled, and that     |
|                      |                       | system migration is   |
|                      |                       | conducted in a secure |
|                      |                       | and systematic manner |
+----------------------+-----------------------+-----------------------+

[]{#__RefHeading___Toc193514858 .anchor}Table 86: Integration of Risk
Management into the SDLC

## 

## SA-4 -- Acquisitions

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall include security requirements and/or security
specifications, either explicitly or by reference, in information system
acquisition contracts based on an assessment of risk and in accordance
with applicable federal laws, directives, policies, regulations, and
standards.

#### 

#### 

#### Mandatory Policy Enhancement(s):

  ------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                          APPLICABLITY   

                                                    MODERATE       HIGH

  \(1\) Bureaus and offices shall ensure that       X              X
  solicitation documents require appropriate                       
  documentation be provided describing the                         
  functional properties of the security controls                   
  employed within the information system with                      
  sufficient detail to permit analysis and testing                 
  of the controls. (including functional interfaces                
  among control components).                                       
  ------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514859 .anchor}Table 87: SA-4 -- Acquisitions
Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

SA-4(a)

Bureaus and offices shall ensure that solicitation documents (e.g.,
Requests for Proposals) for information systems and services include,
either explicitly or by reference, security requirements that describe:

1.  required security capabilities (security needs and, as necessary,
    specific security controls and other specific FISMA requirements)

2.  required design and development processes;

3.  required test and evaluation procedures; and

4.  required documentation.

SA-4(b)

Solicitation documents shall include requirements that permit updating
security controls as new threats/vulnerabilities are identified and as
new technologies are implemented.

SA-4(c)

The solicitation documents shall include requirements for appropriate
information system documentation. The documentation shall address user
and SA guidance and information regarding the implementation of the
security controls in the information system.

SA-4(d)

Bureaus and offices shall ensure information system documentation
includes security configuration settings and security implementation
guidance.

SA-4(e)

Bureaus and offices shall show preference for DOI enterprise products
and follow the guidance within NIST Special Publication 800-23,
*Guideline to Federal Organizations on Security Assurance and
Acquisition/Use of Tested/Evaluated Products* on the acquisition and use
of tested/evaluated information technology products.

### SA-4 Configuration Settings and Implementation Guidance

Information System documentation must include security configuration
settings and security implementation guidance. NIST Special Publication
800-70, *Security Configuration Checklists Program for IT Products:
Guidance for Checklists Users and Developers* provides guidance on
configuration settings for information technology products.

Bureaus and offices must comply with the requirements specified under
CA-1, *C&A Implementation Methodology*, regarding implementation of
baseline security configurations based on the NIST SP 800-53 controls,
applicable Security Technical Implementation Guides (STIGs), and
associated requirements specified within this policy handbook for all
major operating systems, database systems, web-based systems,
applications, and other types of configurable network devices and IT
resources.

Bureaus and offices shall ensure that acquisitions include requirements
for common security configurations in accordance with, and as specified
in, Part 39 of the Federal Acquisition Regulation (FAR) and OMB M-07-18,
*Ensuring New Acquisitions Include Common Security Configurations*.

### SA-4 Contractor Operations

FISMA section 3544(a)(1)(A)(ii) describes federal agency security
responsibilities as including "information systems used or operated by
an agency or by a contractor of an agency or other organization on
behalf of an agency." Section 3544(b) requires that each agency provide
information security for the information and "information systems that
support the operations and assets of the agency, including those
provided or managed by another agency, contractor, or other source."
That is, agency IT security programs apply to all organizations
(sources) which possess or use federal information -- or which operate,
use, or have access to federal information systems -- on behalf of a
federal agency. Such other organizations may include contractors,
grantees, State and local governments, industry partners, etc. In
addition, OMB Circular A-11 provides that equipment is "used" by an
agency whether the agency uses the equipment directly or it is used by a
contractor under a contract with the agency that (1) requires the use of
such equipment or (2) requires the use, to a significant extent, of such
equipment in the performance of a service or the furnishing of a
product.

### SA-4 Requirements for Contractor Operations

In consultation with BCISOs, System Owners, and others involved in
aspects of system security, Contracting Officers and Contracting
Officers Technical Representatives must:

1.  include specific language in contracts to ensure applicability of
    DOI IT Security Program Policies to all contract employees; and

2.  ensure compliance with all DOI IT Security for the information
    system.

In the acquisition cycle, they must follow a methodology consistent with
National Institute of Standards and Technology (NIST) Special
Publication 800-64, *Security Considerations in the Information System
Development Life* Cycle. This methodology ensures that IT security is
addressed in the acquisition process. Additionally, the DOI memorandum
Information Technology Security Requirements for Acquisition, issued
August 18, 2004, provides specific IT security requirements for IT
contracts and

The Capital Planning and Investment Control (CPIC) process requires
contractor oversight language to be included in the exhibit 300.

The following should be used as a template:

+----------------------------------+-----------------------------------+
| Security: Weaknesses &           |                                   |
| Contractor Procedures            |                                   |
+----------------------------------+-----------------------------------+
| Have any weaknesses, not yet     | Answer Yes or No as appropriate   |
| remediated, related to any of    |                                   |
| the systems part of or           |                                   |
| supporting this investment been  |                                   |
| identified by the agency or IG?  |                                   |
+----------------------------------+-----------------------------------+
| If \"yes,\" have those           | Answer Yes or No as appropriate   |
| weaknesses been incorporated     |                                   |
| into the agency\'s plan of       |                                   |
| action and milestone process?    |                                   |
+----------------------------------+-----------------------------------+
| Indicate whether an increase in  | Answer Yes or No as appropriate   |
| IT security funding is requested |                                   |
| to remediate IT security         |                                   |
| weaknesses?                      |                                   |
+----------------------------------+-----------------------------------+
| If \"yes,\" specify the amount,  |                                   |
| provide a general description of |                                   |
| the weakness, and explain how    |                                   |
| the funding request will         |                                   |
| remediate the weakness.          |                                   |
+----------------------------------+-----------------------------------+
|                                  |                                   |
+----------------------------------+-----------------------------------+
| How are contractor security      |                                   |
| procedures monitored, verified,  |                                   |
| and validated by the agency for  |                                   |
| the contractor systems above?    |                                   |
+----------------------------------+-----------------------------------+
| \<insert system acronym\>is      |                                   |
| housed at the \<insert the full  |                                   |
| name of the Bureau or Office or  |                                   |
| other appropriate full name and  |                                   |
| location of facility housing the |                                   |
| system\>, and it is \<describe   |                                   |
| who operates and maintains the   |                                   |
| system, e.g., operated and       |                                   |
| maintained by both Bureau (or    |                                   |
| Office) and contractor           |                                   |
| employees, operated and          |                                   |
| maintained by Bureau (or Office) |                                   |
| employees, operated and          |                                   |
| maintained by contractor         |                                   |
| employees, etc.\>. Contractors   |                                   |
| are trained, and held to the     |                                   |
| same security standards and      |                                   |
| measures as \<insert             |                                   |
| bureau/office acronym\>          |                                   |
| employees. All \<insert          |                                   |
| bureau/office acronym\>          |                                   |
| employees and contract staff are |                                   |
| required to complete an on-line  |                                   |
| security training class each     |                                   |
| year, including the rules of     |                                   |
| behavior and the consequences    |                                   |
| for violating the rules.\        |                                   |
| \                                |                                   |
| All \<insert system              |                                   |
| acronym\>contracts require       |                                   |
| compliance with security         |                                   |
| regulations, including Security  |                                   |
| Controls for Access to IT        |                                   |
| Systems and \<insert system      |                                   |
| acronym\> Standard Operating     |                                   |
| Procedures. Contractor           |                                   |
| personnel, who also receive OPM  |                                   |
| background checks, are           |                                   |
| responsible for understanding    |                                   |
| and complying with the Rules of  |                                   |
| Behavior defined in \<insert     |                                   |
| description of form and/or name  |                                   |
| of the Rules of Behavior, e.g.,  |                                   |
| form 1264-3, Individual Computer |                                   |
| User\'s Statement of             |                                   |
| Responsibility\>, \<insert       |                                   |
| system acronym\>-specific rules  |                                   |
| of behavior, and the need to     |                                   |
| protect the security and         |                                   |
| confidentiality of any system or |                                   |
| application access tokens or     |                                   |
| passwords. The signed \<insert   |                                   |
| description of form and/or name  |                                   |
| of the Rules of Behavior, e.g.,  |                                   |
| 1264-3 forms\> are maintained by |                                   |
| \<insert information regarding   |                                   |
| who maintains the forms, e.g.,   |                                   |
| the local IT Facility Chief      |                                   |
| Information Security Officer\>.\ |                                   |
| \                                |                                   |
| Contractor compliance with       |                                   |
| \<insert bureau/office acronym\> |                                   |
| security procedures are          |                                   |
| monitored through \<insert       |                                   |
| description of security          |                                   |
| procedures compliance monitoring |                                   |
| procedures, e.g., audit logs at  |                                   |
| the application and network      |                                   |
| level\>. \<insert system         |                                   |
| acronym\> user representatives   |                                   |
| regularly review user access     |                                   |
| accounts. Bureau Security also   |                                   |
| monitor inappropriate use of all |                                   |
| users in accordance with         |                                   |
| \<insert bureau/office acronym\> |                                   |
| policies and notifies supervisor |                                   |
| and personnel to take            |                                   |
| appropriate action.\             |                                   |
| \                                |                                   |
| Security procedures are verified |                                   |
| through Security Assessments     |                                   |
| performed annually on the        |                                   |
| applications. \<insert system    |                                   |
| acronym\> Security Assessment    |                                   |
| was performed \<insert dates     |                                   |
| during which self-assessments    |                                   |
| were performed and completed,    |                                   |
| e.g., July 24, 2006 - August 30, |                                   |
| 2006\> in accordance with FIPS   |                                   |
| 200 and NIST 800-53.\            |                                   |
| \                                |                                   |
| All procedures were validated by |                                   |
| an Independent Verification and  |                                   |
| Validation (IV&V) performed by   |                                   |
| \<insert name of                 |                                   |
| company/organization that        |                                   |
| performed the IV&V\> in \<insert |                                   |
| month and year in which IV&V was |                                   |
| completed, e.g., June 2006\>.    |                                   |
| The Security Officer is notified |                                   |
| of any problems or potential     |                                   |
| problems and included on the     |                                   |
| POAM and scheduled for           |                                   |
| mitigation.                      |                                   |
|                                  |                                   |
| Note: Provide any additional     |                                   |
| relevant details within the      |                                   |
| above narrative regarding        |                                   |
| contractor compliance oversight  |                                   |
| functions implemented by the     |                                   |
| bureau/office that provide       |                                   |
| oversight of contractor security |                                   |
| procedures through monitoring    |                                   |
| and independent verification and |                                   |
| validation by bureau/office      |                                   |
| government staff.                |                                   |
+----------------------------------+-----------------------------------+

[]{#__RefHeading___Toc193514772 .anchor}Figure 4: Weaknesses &
Contractor Procedures

## 

## SA-5 -- Information System Documentation

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall obtain, protect as required, and make
available to authorized personnel, adequate documentation for
information systems.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Information system documentation shall       X              X
  include, in addition to administrator and user                    
  guides, available vendor/manufacturer documents                   
  that describe the functional properties of the                    
  security controls employed within the information                 
  system with sufficient detail to permit analysis                  
  and testing of the controls.                                      

  \(2\) Information system documentation shall                      X
  include, in addition to administrator and user                    
  guides, vendor/manufacturer documents describing                  
  the design and implementation details of the                      
  security controls employed within the information                 
  system with sufficient detail to permit analysis                  
  and testing of the controls (including functional                 
  interfaces among control components).                             
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514860 .anchor}Table 88: SA-5 -- Information
System Documentation Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

SA-5(a)

Bureaus and offices shall ensure that documentation includes
administrator and user guides with information on:

1.  configuring, installing, and operating the information system; and

2.  effectively using the system's security features.

SA-5(b)

When adequate information system documentation is either unavailable or
non existent (e.g., due to the age of the system or lack of support from
the vendor/manufacturer), bureaus and offices shall document its
attempts to obtain such documentation and provide compensating security
controls, if needed.

### SA-5 System Documentation Minimum Requirements

System documentation contains descriptions of the system hardware,
software, policies, standards, procedures, and approvals related to the
system life cycle and formalize the system's security controls using
DOI's Information Technology Solutions Development Lifecycle Guide.[^13]
System Owners shall ensure that sufficient documentation exists to
provide an operating reference to effectively use software/hardware, and
formal security and operational procedures have been documented,
including the adequate completion of certification and accreditation
processes. Documentation must include but is not limited to all
documentation of the security planning, certification and accreditation
process, and configuration management of the hardware and software
associated with the system as assembled in the Security Accreditation
Package.

### SA-5 System Documentation Changes

Bureaus and offices shall ensure that mechanisms to control changes to
system security documentation address revisions to all system security
planning documentation (such as, security plans and contingency plans).
The System Owner will ensure that a table of changes describing the
brief nature of significant changes requiring revision to the document.

## SA-6 -- Software Usage Restrictions

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall comply with DOI software usage restrictions.
Where possible, all requests for software and software upgrades shall be
submitted to the bureau/office Chief Information Officer (CIO) or their
designee. All software and software upgrades not acquired by the
bureau/office CIO shall be documented and identified to the
bureau/office CIO or their designee, who will verify that the
bureau/office has an appropriate license for the use of such software.
All acquisitions of hardware that include bundled software shall be
documented and identified to the bureau/office CIO or their designee,
who will verify that the bureau/office has an appropriate license for
the use of such bundled software.

#### Policy Supplement(s):

SA-6(a)

Bureaus and offices shall ensure that software and associated
documentation is used in accordance with contract agreements and
copyright laws. The bureau/office, under the supervision of the
bureau/office CIO, shall establish and maintain a recordkeeping system
for original software licenses, certificates of authenticity, purchase
invoices, completed registration cards, original software media (e.g.,
diskettes or CD-ROMs), user information, and assessment information. The
bureau/office shall maintain this information in secure location(s)
designated by the bureau/office CIO and consider the use of software
management computer programs to automate such recordkeeping. The
bureau/office recordkeeping systems shall ensure that software is
properly inventoried, noting the authorized number of users and/or site
locations. The bureau/office shall conduct on a periodic basis, but not
less than annually, a software management review and inventory to
include, but not limited to, (i) an assessment of its software
management procedures and practices; and (ii) an inventory of installed
software and related license agreements, purchase invoices and other
documentation evidencing licensed software use. The bureau/office CIO
shall supervise such assessment and inventory with assistance, as
needed, from Interior's Office of Inspector General (OIG), designated
employees and/or outside consultants. The bureau/office CIO or
designated employees shall destroy all copies of unauthorized software
for which the bureau/office lacks the appropriate license.
Alternatively, the bureau/office CIO may obtain the license(s) necessary
to maintain such software on bureau/office computers.

SA-6(b)

Bureaus and offices shall employ tracking systems to control copying and
distribution for software and associated documentation that is protected
by quantity licenses.

SA-6(c)

Bureaus and offices shall control and document the use of publicly
accessible peer-to-peer file sharing technology to ensure that this
capability is not used for the unauthorized distribution, display,
performance, or reproduction of copyrighted work.

SA-6(d)

Development software shall not be installed on systems connected to the
production environment.

### SA-6 Software Use Policy and Provisions for Copyrighted Software

Employees shall comply with the following software use policy:

-   [Prohibition against Unlicensed Software Use]{.underline}. No
    employee or contractor shall:

    -   Install, reproduce, distribute, transmit or otherwise use
        software for which the bureau/office lacks the appropriate
        license, unless such software is properly licensed to the
        employee and used in accordance with bureau/office policy and
        the applicable license. If an employee or contractor becomes
        aware of the reproduction, distribution or use of unauthorized
        software in the bureau/office, they should promptly notify their
        supervisor and the bureau/office CIO's designated office.

    -   Install, reproduce or use any software upgrade on a computer
        that does not already have resident on it the original version
        of the software.

    -   Loan, distribute or transmit bureau/office software to any
        third-party, unless the employee is expressly authorized in
        writing to do so by their supervisor, with the written and
        signed approval of the bureau/office CIO's designated reviewing
        and approving office, and consistent with any additional
        bureau/office specific policies and the applicable license.

-   [Authorization to Use Bureau/Office Software on Home
    Computers]{.underline}. The licenses for some bureau/office software
    permit employees of the bureau/office to make a copy of the software
    for home use. In such event, employees may make a copy of
    bureau/office software for home use only if they demonstrate a need
    to conduct bureau/office business from their homes and receive
    express written authorization from their supervisor and with the
    written and signed approval of the bureau/office CIO or their
    designee. Under no circumstances, however, may an employee use
    bureau/office software for purposes other than the business of the
    bureau/office.

-   [Downloading of Software from the Internet or Other Sources onto
    Bureau/Office Computers]{.underline}. A variety of software is
    available on the Internet. Some of this software, called
    \"freeware\" or \"shareware,\" is available free of charge for
    limited uses and may be downloaded by an employee or contractor with
    the prior express written approval of their supervisor and with the
    written and signed approval of the bureau/office CIO or their
    designee. Other software available on the Internet and from other
    electronic sources, however, requires the user to obtain a license
    for its use, sometimes for a fee. No employee or contractor shall
    download licensed software to their workstation without the prior
    express written authorization and signed approval of their
    supervisor and the bureau/office CIO or their designee.

-   [Enforcement]{.underline}. The bureau/office CIO shall supervise
    periodic reviews and assessments to evaluate the effectiveness of
    the software management policy. As part of this process, the
    bureau/office CIO or their designee may ask employees and/or
    contractors to complete a Software User Survey. This Survey should
    be used to determine the bureau\'s/office's existing and future use
    and need of particular software programs. Employees and contractors
    must cooperate with all assessments and Software User Surveys.

-   An employee or contractor may be held responsible for the existence
    of any software on their workstation for which the bureau/office
    lacks the appropriate licenses

All DOI employees must use and distribute commercial software and other
intellectual property in accordance with copyright laws and licensing
agreements. BCISOs with the support of bureau or office heads, will
communicate the following software copyright rules of behavior guidance
to all DOI employees:

1.  Install only software authorized by the System Owner.

2.  Follow all provisions of the licensing agreements issued with the
    software and register organizational (governmental) ownership.

3.  Do not make any illegal copies of copyrighted software \[piracy\].
    Normally the license will allow a single copy to be made for
    archival purposes. If the license is for multiple users, do not
    exceed the authorized number of copies.

4.  Maintain written records of software installed on each system and
    ensure that a license or other proof of government ownership is on
    file for each piece of software.

5.  Store licenses, software manuals, and procurement documentation in a
    secure location (e.g., closed file cabinet, etc.) and consistent
    with any applicable bureau/office specific policies.

6.  When upgrades to software are purchased, dispose of the old version
    in accordance with the licensing agreement to avoid a potential
    violation. Upgraded software is considered a continuation of the
    original license, not an additional license. However, if licensing
    instructions require use of original disks then the disposal of
    older versions may/may not be recommended. A filing system should be
    employed to keep original and upgrades disks together.

7.  If a copy of any software is detected that may not be copied or used
    consistent with the license associated with that software, then the
    System Owner and/or the system support staff should be notified
    immediately so that appropriate action can be taken.

8.  If resources are protected by copyright or patent, they may only be
    used in a manner consistent with such copyright or patent
    \[piracy\].

##### Piracy Reporting Metrics

#### This policy supersedes:

-   OCIO Memorandum "Software Piracy Performance Metrics" issued on June
    29, 2006

Bureaus and offices must develop, monitor, and track performance metrics
related to the effectiveness of software piracy prevention controls
that, at a minimum, include the following:

> **Performance Standards - Summary Matrix**

+---------+------------------+-----------+---------+----+-----------+
| > *     | > **Performance  | > **Pe    | >       | >  | **Method  |
| *Task** | > Metric**       | rformance |  **Perf |  * | Of        |
|         |                  | > Metric  | ormance | *M | Surve     |
|         |                  | > In      | >       | ax | illance** |
|         |                  | dicator** |  Metric | >  |           |
|         |                  |           | > Sta   |  E |           |
|         |                  |           | ndard** | rr |           |
|         |                  |           |         | or |           |
|         |                  |           |         | >  |           |
|         |                  |           |         | Ra |           |
|         |                  |           |         | te |           |
|         |                  |           |         | ** |           |
+---------+------------------+-----------+---------+----+-----------+
| > S     | > Percent (%) of | >         | >       | >  | Annual    |
| oftware | > users that     | Completed |  **100% | No | check of  |
| >       | > received       | > in a    | >       | ne | training  |
|  Piracy | > annual         | > timely  | users** |    | pa        |
| > Requi | > refresher      | > manner  | >       |    | rticipant |
| rements | > training       | > **(BY   | receive |    | logs **&  |
| > *     | > (number        | > END OF  | > re    |    | REPORT TO |
| *ANNUAL | >                | > EACH    | fresher |    | Bure      |
| > Tra   |  required/number | > FY)**   | > t     |    | au/Office |
| ining - | > completed)     |           | raining |    | CIO**     |
| > Refr  |                  |           |         |    |           |
| esher** |                  |           |         |    |           |
+---------+------------------+-----------+---------+----+-----------+
| > S     | > Percent (%) of | >         | >       | >  | Monthly   |
| oftware | > new hires that | Completed |  **100% | 5% | check of  |
| >       | > received       | > in a    | > of    |    | training  |
|  Piracy | > initial        | > timely  | > New   |    | pa        |
| > Requi | > training       | > manner  | >       |    | rticipant |
| rements | > within 30 days | >         | Hires** |    | logs **&  |
| > **Tra | > of EOD (number | **(WITHIN | >       |    | REPORT TO |
| ining - | >                | > 30-DAYS | trained |    | Bure      |
| > New   |  required/number | > OF      | >       |    | au/Office |
| >       | > completed)     | > EOD)**  |  within |    | *CISO***  |
| Hires** |                  |           | >       |    |           |
|         |                  |           | 30-days |    |           |
|         |                  |           | > of    |    |           |
|         |                  |           | > the   |    |           |
|         |                  |           | > date  |    |           |
|         |                  |           | > of    |    |           |
|         |                  |           | > hire  |    |           |
+---------+------------------+-----------+---------+----+-----------+
| > S     | > Percent (%) of | >         | >       | >  | Monthly   |
| oftware | > users with     | Completed |  **100% | No | check of  |
| >       | > administrative | > in a    | >       | ne | training  |
|  Piracy | > rights         | > timely  | users** |    | pa        |
| > Requi | > sufficient to  | > manner  | > with  |    | rticipant |
| rements | > be able to     | > **(BY   | >       |    | logs **&  |
| > *     | > install        | > END OF  | Adminis |    | REPORT TO |
| *ANNUAL | > software that  | > EACH    | trative |    | Bure      |
| > T     | > received       | > FY)**   | >       |    | au/Office |
| raining | > annual         |           |  Rights |    | CIO**     |
| > -**   | > training       |           | >       |    |           |
| >       | > (number        |           | receive |    |           |
| **Users | >                |           | > re    |    |           |
| > with  |  required/number |           | fresher |    |           |
| >       | > completed)     |           | > t     |    |           |
| Adminis |                  |           | raining |    |           |
| trative |                  |           |         |    |           |
| > R     |                  |           |         |    |           |
| ights** |                  |           |         |    |           |
+---------+------------------+-----------+---------+----+-----------+
| > S     | > Percent (%) of | > E       | > 100%  | >  | Monthly   |
| oftware | > users          | valuation | > staff | No | piracy    |
| >       | > evaluated to   | > *       | > in    | ne | directive |
|  Piracy | > be in          | *(SEMI-AN | > com   |    | c         |
| > Di    | > compliance     | NUALLY)** | pliance |    | ompliance |
| rective | > with           |           |         |    | i         |
| > **Com | > established    |           |         |    | nspection |
| pliance | > software       |           |         |    | report    |
| > Inspe | > piracy policy  |           |         |    | **&       |
| ction** | > (number        |           |         |    | REPORT TO |
|         | > required to be |           |         |    | Bure      |
|         | > in             |           |         |    | au/Office |
|         | > c              |           |         |    | *CISO***  |
|         | ompliance/number |           |         |    |           |
|         | > determined to  |           |         |    |           |
|         | > be in          |           |         |    |           |
|         | > compliance)    |           |         |    |           |
+---------+------------------+-----------+---------+----+-----------+
| > S     | > Percent (%) of | >         | > 100%  | >  | Monthly   |
| oftware | > inspected and  | Completed | > of    | No | software  |
| >       | > audited        | > in a    | >       | ne | piracy    |
|  Piracy | > information    | > timely  | systems |    | system    |
| > *     | > systems        | > manner  | > in    |    | audit     |
| *System | > determined to  | >         | spected |    | report    |
| >       | > be in          | > **(QUA  | > and   |    | **&       |
| Audit** | > compliance     | RTERLY)** | >       |    | REPORT TO |
|         | > with           |           | audited |    | Bure      |
|         | > established    |           | > with  |    | au/Office |
|         | > software       |           | > 100%  |    | *CISO***  |
|         | > piracy policy  |           | > in    |    |           |
|         | > (number        |           | > com   |    |           |
|         | > required to be |           | pliance |    |           |
|         | > in inspected,  |           |         |    |           |
|         | > audited, and   |           |         |    |           |
|         | > in             |           |         |    |           |
|         | > c              |           |         |    |           |
|         | ompliance/number |           |         |    |           |
|         | > determined to  |           |         |    |           |
|         | > be in          |           |         |    |           |
|         | > compliance)    |           |         |    |           |
+---------+------------------+-----------+---------+----+-----------+
| >       | > Percent (%) of | >         | > 100%  | >  | Annual    |
| **Contr | > Contractors    | Corporate | > Cont  | No | s         |
| actor** | > determined to  | > Asset   | ractors | ne | tatements |
| > Co    | > be in          | >         | > in    |    | of        |
| rporate | > compliance     |  Software | > com   |    | assurance |
| > Asset | > with           | > Piracy  | pliance |    | logs **&  |
| > S     | > established    | >         |         |    | REPORT TO |
| oftware | > software       | Directive |         |    | Bure      |
| >       | > piracy policy  | > C       |         |    | au/Office |
|  Piracy | > (number        | ompliance |         |    | CIO**     |
| > Di    | > required to be | >         |         |    |           |
| rective | > in             | Assurance |         |    |           |
| >       | > c              | >         |         |    |           |
|  **Assu | ompliance/number | statement |         |    |           |
| rance** | > determined to  | > **(BY   |         |    |           |
|         | > be in          | > END OF  |         |    |           |
|         | > compliance)    | > EACH    |         |    |           |
|         |                  | > FY)**   |         |    |           |
+---------+------------------+-----------+---------+----+-----------+

Bureaus and offices must provide annual reports that address, at a
minimum, the most current performance metrics to the Cyber Security
Division (CSD) within the Department's OCIO by the end of the first
quarter of each fiscal year, and at other times upon request.

## 

## 

## SA-7 -- User Installed Software 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall enforce explicit rules governing the
downloading and installation of software by users. Bureaus and offices
shall ensure users with elevated privileges have adequate knowledge,
skills, and abilities to prevent them from introducing unacceptable
additional risk(s). Bureaus and offices shall restrict privileges for
users to only the minimum necessary rights and permissions necessary to
fulfill their assigned roles and responsibilities.

#### Policy Supplement(s):

SA-7(a)

Bureaus and offices shall restrict the ability to download and install
software to users with elevated privileges. In certain instances,
bureaus and offices may allow users that have been identified as users
who have a special need for specific software; and that software resides
on their bureau/office approved list of software, to download and
install the specific software to their assign computer.

SA-7(b)

Bureaus and offices shall identify what types of software downloads and
installations are permitted (e.g., updates and security patches to
existing software) and what types of downloads and installations are
prohibited (e.g., software that is free only for personal, not
government, use).

#### Additional Policy Guidance:

The unauthorized installation of Instant Messaging (IM), Internet Relay
Chat (IRC), Web Conferencing, and Peer-to-Peer (P2P) software is
prohibited on all information systems.

## SA-8 -- Security Engineering Principles 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High Impact
information systems are designed and implemented using security
engineering principles as recommended by NIST Special Publication
800-27A, *Engineering Principles for Information Technology Security (A
Baseline for Achieving Security) Revision A*.

#### 

#### Policy Supplement(s):

SA-8(a)

For legacy information systems, bureaus and offices shall apply security
engineering principles to system upgrades and modifications, to the
extent feasible, given the current state of the hardware, software, and
firmware components within the system.

#### Additional Policy Guidance:

The application of security engineering principles is primarily targeted
at new development information systems or systems undergoing major
upgrades and is integrated into the system development life cycle.

## SA-9 -- External Information System Services

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Require providers of external information system services to employ
    adequate security controls in accordance with applicable federal
    laws, directives, policies, regulations, standards, guidance, and
    established service-level agreements; and

2.  Monitor security control compliance.

#### Policy Supplement(s):

SA-9(a)

An external information system service constitutes a service that is
implemented outside of the accreditation boundary of the bureau or
office information system (i.e., a service that is used by, but not a
part of, the information system).

SA-9(b)

Bureau and office Authorizing Officials must require that an appropriate
chain of trust be established with external service providers when
dealing with the many issues associated with information system
security.

SA-9(c)

For services external to the bureau or office, a chain of trust requires
that the bureau or office establish and retain a level of confidence
that each participating service provider in the potentially complex
consumer-provider relationship provides adequate protection for the
services rendered.

SA-9(d)

Where a sufficient level of trust cannot be established in the external
services and/or service providers, bureaus and offices shall employ
compensating security controls or accept the greater degree of risk to
its operations and assets, or to individuals.

SA-9(e)

Bureaus and offices shall ensure that external information system
services documentation includes government, service provider, and
end-user security roles and responsibilities, and any service-level
agreements.

SA-9(f)

Bureaus and offices shall ensure that service-level agreements define
the expectations of performance for each required security control,
describe measurable outcomes, and identify remedies and response
requirements for any identified instance of non-compliance.

#### Additional Policy Guidance:

Relationships with external service providers are established in a
variety of ways, for example, through joint ventures, business
partnerships, outsourcing arrangements (i.e., through contracts,
interagency agreements, lines of business arrangements), licensing
agreements, and/or supply chain exchanges.

The responsibility for adequately mitigating risks to bureau and office
operations and assets, and to individuals, arising from the use of
external information system services remains with the authorizing
official.

## SA-10 -- Developer Configuration Management 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that information system developers
create and implement a configuration management plan that controls
changes to the system during development and upgrades that tracks
security flaws, requires authorization of changes, and provides
documentation of the plan and its implementation for High-impact
information systems.

### SA-10 Configuration Management Provisions for System Developers

Bureaus and offices shall ensure that information system developers
create and implement a configuration management plan that:

1.  controls changes to the system during development,

2.  tracks security flaws,

3.  requires authorization of changes, and

4.  provides documentation of the plan and its implementation.

## SA-11 -- Developer Security Testing 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that information system developers
create a security test and evaluation plan, implement the plan, and
document the results.

#### Policy Supplement(s):

SA-11(a)

Bureaus and offices shall utilize developmental security test results to
the greatest extent feasible after verification of the results,
recognizing that these results are impacted whenever there have been
security relevant modifications to the information system subsequent to
developer testing.

#### Additional Policy Guidance:

Developmental security test results may be used in support of the
security certification and accreditation process for the delivered
information system.

[]{#__RefHeading___Toc193514574 .anchor}**System and Communications
Protection (SC)**

Bureaus and offices shall comply with the NIST Special Publication
800-53, Rev.1, *Recommended Security Controls for Federal Information
Systems,* system and communications protection controls listed in the
following table:

+------+--------------------------------------+---------+-------+------+
|  Sy  |                                      |         |       |      |
| stem |                                      |         |       |      |
| and  |                                      |         |       |      |
| Co   |                                      |         |       |      |
| mmun |                                      |         |       |      |
| icat |                                      |         |       |      |
| ions |                                      |         |       |      |
| Pr   |                                      |         |       |      |
| otec |                                      |         |       |      |
| tion |                                      |         |       |      |
+------+--------------------------------------+---------+-------+------+
|      |                                      | Control |       |      |
|      |                                      | Ba      |       |      |
| Con  | Control Name                         | selines |       |      |
| trol |                                      |         |       |      |
| Nu   |                                      |         |       |      |
| mber |                                      |         |       |      |
+------+--------------------------------------+---------+-------+------+
|      |                                      | Low     | Mod   | High |
|      |                                      |         | erate |      |
+------+--------------------------------------+---------+-------+------+
| SC-1 | System and Communications Protection | SC-1    | SC-1  | SC-1 |
|      | Policy and Procedures                |         |       |      |
+------+--------------------------------------+---------+-------+------+
| SC-2 | Application Partitioning             | Not     | SC-2  | SC-2 |
|      |                                      | S       |       |      |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| SC-3 | Security Function Isolation          | Not     | Not   | SC-3 |
|      |                                      | S       | Sel   |      |
|      |                                      | elected | ected |      |
+------+--------------------------------------+---------+-------+------+
| SC-4 | Information Remnants                 | Not     | SC-4  | SC-4 |
|      |                                      | S       |       |      |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| SC-5 | Denial of Service Protection         | SC-5    | SC-5  | SC-5 |
+------+--------------------------------------+---------+-------+------+
| SC-6 | Resource Priority                    | Not     | Not   | Not  |
|      |                                      | S       | Sel   | Sele |
|      |                                      | elected | ected | cted |
+------+--------------------------------------+---------+-------+------+
| SC-7 | Boundary Protection                  | SC-7    | SC-7  | SC-7 |
|      |                                      |         | (1)   | (1)  |
|      |                                      |         | (2)   | (2)  |
|      |                                      |         | (3)   | (3)  |
|      |                                      |         | (4)   | (4)  |
|      |                                      |         | (5)   | (5)  |
|      |                                      |         | (6)   | (6)  |
+------+--------------------------------------+---------+-------+------+
| SC-8 | Transmission Integrity               | Not     | SC-8  | SC-8 |
|      |                                      | S       | (1)   | (1)  |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| SC-9 | Transmission Confidentiality         | Not     | SC-9  | SC-9 |
|      |                                      | S       | (1)   | (1)  |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Network Disconnect                   | Not     | SC-10 | S    |
| C-10 |                                      | S       |       | C-10 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Trusted Path                         | Not     | Not   | Not  |
| C-11 |                                      | S       | Sel   | Sele |
|      |                                      | elected | ected | cted |
+------+--------------------------------------+---------+-------+------+
| S    | Cryptographic Key Establishment and  | Not     | SC-12 | S    |
| C-12 | Management                           | S       |       | C-12 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Use of Validated Cryptography        | SC-13   | SC-13 | S    |
| C-13 |                                      |         |       | C-13 |
+------+--------------------------------------+---------+-------+------+
| S    | Public Access Protections            | SC-14   | SC-14 | S    |
| C-14 |                                      |         |       | C-14 |
+------+--------------------------------------+---------+-------+------+
| S    | Collaborative Computing              | Not     | SC-15 | S    |
| C-15 |                                      | S       |       | C-15 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Transmission of Security Parameters  | Not     | Not   | Not  |
| C-16 |                                      | S       | Sel   | Sele |
|      |                                      | elected | ected | cted |
+------+--------------------------------------+---------+-------+------+
| S    | Public Key Infrastructure            | Not     | SC-17 | S    |
| C-17 | Certificates                         | S       |       | C-17 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Mobile Code                          | Not     | SC-18 | S    |
| C-18 |                                      | S       |       | C-18 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Voice Over Internet Protocol         | Not     | SC-19 | S    |
| C-19 |                                      | S       |       | C-19 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Secure Name /Address Resolution      | Not     | SC-20 | S    |
| C-20 | Service (Authoritative Source)       | S       |       | C-20 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Secure Name /Address Resolution      | Not     | Not   | S    |
| C-21 | Service (Recursive or Caching        | S       | Sel   | C-21 |
|      | Resolver)                            | elected | ected |      |
+------+--------------------------------------+---------+-------+------+
| S    | Architecture and Provisioning for    | Not     | SC-22 | S    |
| C-22 | Name/Address Resolution Service      | S       |       | C-22 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+
| S    | Session Authenticity                 | Not     | SC-23 | S    |
| C-23 |                                      | S       |       | C-23 |
|      |                                      | elected |       |      |
+------+--------------------------------------+---------+-------+------+

[]{#__RefHeading___Toc193514861 .anchor}Table 89: System and
Communications Protection Controls

## SC-1 -- System and Communications Protection Policy and Procedures 

#### Applicability:

Bureaus and Offices

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, system and communications protection policy that
    addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the system and communications protection policy and associated
    system and communications protection controls.

## SC-2 -- Application Partitioning 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems separate user functionality (including user
interface services) from information system management functionality.

#### Policy Supplement(s):

SC-2(a)

Bureaus and offices shall ensure that information systems physically or
logically separate user interface services (e.g., public web pages) from
information storage and management services (e.g., database management).

SC-2(b)

Separation may be accomplished through the use of different computers,
different central processing units, different instances of the operating
system, different network addresses, combinations of these methods, or
other methods as appropriate.

##  

## SC-3 -- Security Function Isolation 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that High-impact information systems
isolate security functions from non-security functions.

#### Policy Supplement(s):

SC-3(a)

Bureaus and offices shall ensure that information systems isolate
security functions from non-security functions by means of partitions,
domains, etc., including control of access to and integrity of, the
hardware, software, and firmware that perform those security functions.

SC-3(b)

Bureaus and offices shall ensure that information systems maintain a
separate execution domain (e.g., address space) for each executing
process.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  requiring information systems to employ underlying                
  hardware separation mechanisms to facilitate                      
  security function isolation.                                      

  \(2\) Bureaus and offices should consider                         X
  requiring information systems to isolate critical                 
  security functions (i.e., functions enforcing                     
  access and information flow control) from both                    
  non-security functions and from other security                    
  functions.                                                        

  \(3\) Bureaus and offices should consider                         X
  requiring information systems to minimize the                     
  number of non-security functions included within                  
  the isolation boundary containing security                        
  functions.                                                        

  \(4\) Bureaus and offices should consider                         X
  implementing information system security functions                
  as largely independent modules that avoid                         
  unnecessary interactions between modules.                         

  \(5\) Bureaus and offices should consider                         X
  implementing information system security functions                
  as a layered structure, minimizing interactions                   
  between layers of the design and avoiding any                     
  dependence by lower layers on the functionality or                
  correctness of higher layers.                                     
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514862 .anchor}Table 90: SC-3 -- Security
Function Isolation Recommended Policy Enhancement(s)

## SC-4 -- Information Remnants 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems prevent unauthorized and unintended information
transfer via shared system resources.

#### Additional Policy Guidance:

Control of information system remnants, sometimes referred to as "object
reuse", or "data remnant", prevents information, including encrypted
representations of information, produced by the actions of a prior
user/role (or the actions of a process acting on behalf of a prior
user/role) from being available to any current user/role (or current
process) that obtains access to a shared system resource (e.g.,
registers, main memory, secondary storage) after that resource has been
released back to the information system.

Bureaus and offices shall log all computer-readable data extracts from
databases holding sensitive information (including PII) and verify each
extract including sensitive data has been erased within 90 days or the
necessity that its use is still required (re-verification of continuing
usage shall occur within every 30 days thereafter).

## SC-5 -- Denial of Service Protection 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure all information systems protect against
or limit the effects of the following types of denial of service
attacks: all flaw-based, SYN flood, ICMP flood, UDP flood, teardrop,
application-level flood, nuke and SQL injection attacks.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider          X              X
  configuring information systems to restrict the                   
  ability of users to launch denial of service                      
  attacks against other information systems or                      
  networks.                                                         

  \(2\) Bureaus and offices should consider          X              X
  configuring information systems to manage excess                  
  capacity, bandwidth, or other redundancy to limit                 
  the effects of information flooding types of                      
  denial of service attacks.                                        
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514863 .anchor}Table 91: SC-5 -- Denial of
Service Protection Recommended Policy Enhancement(s)

## SC-6 -- Resource Priority 

#### Applicability:

Optional for All Information Systems

Bureaus and offices shall ensure that information systems limit the use
of resources by priority.

## SC-7 -- Boundary Protection 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems monitor
and control communications at the external boundary of the information
system and at key internal boundaries within the system.

#### Policy Supplement(s):

SC-7(a)

Bureaus and offices shall ensure that any connections to the Internet,
or other external networks or information systems, occur through managed
interfaces consisting of appropriate boundary protection devices (e.g.,
proxies, gateways, routers, firewalls, encrypted tunnels) arranged in an
effective architecture (e.g., routers protecting firewalls and
application gateways residing on a protected sub-network commonly
referred to as a demilitarized zone or DMZ).

SC-7(b)

Bureaus and offices shall ensure that information system boundary
protections at any designated alternate processing sites provide the
same levels of protection as that of the primary site.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall physically         X              X
  allocate publicly accessible information system                   
  components (e.g., public web servers) to separate                 
  sub-networks with separate, physical network                      
  interfaces.                                                       

  \(2\) Bureaus and offices shall prevent public     X              X
  access into internal networks except as                           
  appropriately mitigated.                                          

  \(3\) Bureaus and offices shall limit the number   X              X
  of access points to the information system to                     
  allow for better monitoring of inbound and                        
  outbound network traffic.                                         

  \(4\) Bureaus and offices shall implement a        X              X
  managed interface (boundary protection devices in                 
  an effective security architecture) with any                      
  external telecommunication service, implementing                  
  controls appropriate to the required protection of                
  the confidentiality and integrity of the                          
  information being transmitted.                                    

  \(5\) Bureaus and offices shall ensure that        X              X
  information systems deny network traffic by                       
  default and allows network traffic by exception                   
  (i.e., deny all, permit by exception).                            

  \(6\) Bureaus and offices shall prevent the        X              X
  unauthorized release of information outside of                    
  information system boundaries or any unauthorized                 
  communication through information system                          
  boundaries when there is an operational failure of                
  the boundary protection mechanisms.                               
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514864 .anchor}Table 92: SC-7 -- Boundary
Protection Mandatory Policy Enhancement(s)

#### Additional Policy Guidance:

As part of a defense-in-depth protection strategy, bureaus and offices
should consider partitioning higher impact information systems into
separate physical domains (or environments) and applying the concepts of
managed interfaces described above to restrict or prohibit network
access in accordance with an organizational assessment of risk. Security
categorization (FIPS 199 and NIST SP 800-60) should be used to guide the
selection of appropriate candidates for domain partitioning.

Bureaus and offices should carefully consider the intrinsically shared
nature of commercial telecommunications services in the implementation
of security controls associated with the use of such services.
Commercial telecommunications services are commonly based on network
components and consolidated management systems shared by all attached
commercial customers, and may include third-party provided access lines
and other service elements. Consequently, such interconnecting
transmission services may represent sources of increased risk despite
contract security provisions. Therefore, when this situation occurs, the
bureaus and offices should either implement appropriate compensating
security controls or explicitly accept the additional risk.

## SC-8 -- Transmission Integrity

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems protect the integrity of transmitted information.

#### 

#### 

#### 

#### 

#### Policy Supplement(s):

SC-8(a)

When it is infeasible or impractical to obtain the necessary security
controls and assurances of control effectiveness through appropriate
contracting vehicles, bureaus and offices shall either implement
appropriate compensating security controls or explicitly accepts the
additional risk.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ             X              X
  cryptographic mechanisms to prevent unauthorized                  
  disclosure of sensitive information during                        
  transmission unless otherwise protected by                        
  alternative physical measures (e.g., protective                   
  distribution systems).                                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514865 .anchor}Table 93: SC-8 -- Transmission
Integrity Mandatory Policy Enhancement(s)

## SC-9 -- Transmission Confidentiality 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems protect the confidentiality of transmitted
information.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ             X              X
  cryptographic mechanisms to prevent unauthorized                  
  disclosure of sensitive information during                        
  transmission unless otherwise protected by                        
  alternative physical measures (e.g., protective                   
  distribution systems).                                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514866 .anchor}Table 94: SC-9 -- Transmission
Confidentiality Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

SC-9(a)

When it is infeasible or impractical to obtain the necessary security
controls and assurances of control effectiveness through appropriate
contracting vehicles, bureaus and offices shall either implement
appropriate compensating security controls or explicitly accept the
additional risk.

## SC-10 -- Network Disconnect 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems terminate network connections at the end of a
session or after no more than 30 minutes of inactivity.

## SC-11 -- Trusted Path 

#### Applicability:

Optional for All Information Systems

Bureaus and offices shall ensure that information systems establish a
trusted communications path between the user and the security functions
of the system.

## SC-12 -- Cryptographic Key Establishment and Management 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall establish and manage cryptographic keys using
automated mechanisms with supporting procedures or manual procedures
when cryptography is required and employed within Moderate and
High-impact information systems.

## SC-13 -- Use of Validated Cryptography 

#### Applicability:

All Information Systems

#### Policy Statement:

When cryptography is required and employed within Moderate and High
impact information systems, bureaus and offices shall comply with
applicable federal laws, directives, policies, regulations, standards,
and guidance, including FIPS 140-2, *Security requirements for
Cryptographic Modules* (as amended) which requires the system to perform
all cryptographic operations (including key generation) using FIPS 140-2
validated cryptographic modules operating in approved modes of
operation.

## 

## 

## SC-14 -- Public Access Protections 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure all information systems protect the
integrity and availability of publicly available information and
applications.

## SC-15 -- Collaborative Computing 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems prohibit remote activation of collaborative
computing mechanisms (e.g., video and audio conferencing) and provides
an explicit indication of use to the local users (e.g., use of camera or
microphone).

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  requiring information systems to provide a                        
  physical disconnect of cameras and microphones in                 
  a manner that supports ease of use.                               
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514867 .anchor}Table 95: SC-15 Collaborative
Computing Recommended Policy Enhancement(s)

### SC-15 Instant Messaging (IM), Internet Relay Chat (IRC), Web Conferencing, and Peer-to-Peer (P2P) Usage

Authorized use, installation, or activation of IM, IRC, web
conferencing, P2P, and Shares at the desktop shall comply with the
following provisions, other than expressly authorized:

1.  Ensure all information systems prohibit the unauthorized use,
    installation, or activation of IM, IRC, web conferencing, and P2P
    software.

2.  Authorized use, installation, or activation of IM, IRC, web
    conferencing, and P2P shall only be granted by the information
    system's Designated Approving/Accrediting Authority (DAA), other
    than expressly authorized as documented in the Emergency
    Authorizations section of this policy.

3.  Authorization requests to be submitted to and approved by the
    respective DAA prior to any use;

4.  Authorization artifacts shall be recorded in the System Security
    Plan (SSP) and Risk Assessment (RA);

5.  Authorization requests to be submitted to and approved by the DAAs
    for all associated interconnected systems, where said application
    and service traffic traverses the interconnection boundary, prior to
    any use;

6.  Authorizations shall be recorded in the appropriate interconnection
    security agreements;

7.  Authorization artifacts shall also be recorded in the SSP and RA of
    all associated interconnected systems;

8.  The SSPs and RAs to collectively:

9.  Describe all security controls required for authorization;

10. Identify the risks to the information and information system(s); and

11. Include the DAA's authorization(s) and statements acknowledging and
    accepting the risks.

12. The DAA level of authorization to account for all authorized users
    through general user lists (e.g., roles, divisions).

13. Users shall be authenticated against a DOI trusted user list (e.g.,
    Active Directory)

14. Use is restricted to intranets, i.e., closed DOI environments,
    except as specifically noted below:

15. Public Internet use is permitted only by authorized users meeting
    the following qualifications, while not violating a Court Order:

16. Working with or having recognized disabilities (speech, hearing, or
    sight); or

17. Conducting necessary official business where no other forms of
    communication are sufficient and only when all other provisions are
    met.

18. Furthermore, any transmission of Sensitive but Unclassified (For
    Official Use Only) information over the public Internet shall use
    authorized end-to-end encryption algorithms (FIPS 140-2).

Bureaus and offices shall:

1.  Standardize on IM, IRC, web conferencing, and P2P applications and
    services based on approved technology in the Technical Reference
    Model.

2.  Account for all authorized users.

3.  Implement technical controls to restrict use to only authorized
    users.

4.  Implement appropriate management, operational, and technical
    controls to ensure appropriate capture and retention of:

    a.  Federal records as defined in 44 U.S.C. 3301; and specifically

        i.  electronic communications that relate to the:

            1.  American Indian trust reform, including High-Level
                Implementation Plan or any of its subprojects;

            2.  Cobell litigation; or

            3.  Administration of Individual Indian Money accounts.

5.  Implement capabilities within their configuration management process
    to detect and remove unauthorized IM, IRC, web conferencing, and P2P
    software.

Bureaus, offices and the ESN shall:

1.  Implement technical controls to prevent IM file attachments from
    traversing across their managed Internet gateways.

2.  Apply technical controls that provide a fail-safe mechanism to
    disable IM through all Internet gateways within 30 minutes of an
    order from the Departmental Chief Information Officer.

3.  Notify affected bureaus and offices of IM threats that require
    activation of IM disabling controls.

### SC-15 Emergency Authorizations 

Emergency Authorizations and exceptions to the provisions of IM, IRC,
web conferencing, and P2P use may be granted by the Departmental Chief
Information Officer, when found necessary to prepare for or address
situations where other means of communication are not sufficient or may
be unreliable. Only the Departmental CIO may delegate emergency
authorization or accept risk associated with emergency conditions.

## SC-16 -- Transmission of Security Parameters

#### Applicability:

Optional for All Information Systems

Bureaus and offices shall ensure information systems reliably associate
security parameters (e.g., security labels and markings) with
information exchanged between information systems.

#### Additional Policy Guidance:

Security parameters may be explicitly or implicitly associated with the
information contained within the information system.

## SC-17 -- Public key Infrastructure Certificates 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall develop and implement a certificate policy and
certification practice statement for the issuance of public key
certificates used in Moderate and High-impact information systems.

#### Policy Supplement(s):

SC-17(a)

The certificate policy and certification practice statement may
reference in whole or in part the certificate policy and certification
practice statement of the certificate issuer.

SC-17(b)

Registration to receive a public key certificate shall include
authorization by a supervisor or a responsible official \[System
Owner\], and shall be done by a secure process that verifies the
identity of the certificate holder and ensures that the certificate is
issued to the intended party.

## SC-18 -- Mobile Code 

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Establish usage restrictions and implementation guidance for mobile
    code technologies based on the potential to cause damage to Moderate
    and High-impact information systems if used maliciously; and

2.  Authorize, monitor, and control the use of mobile code within
    Moderate and High-impact information systems.

#### Policy Supplement(s):

SC-18(a)

Usage restrictions and implementation guidance shall apply to both the
selection and use of mobile code installed on bureau or office servers
and mobile code downloaded and executed on individual workstations.

SC-18(b)

Control procedures shall include procedures to prevent the development,
acquisition, or introduction of unacceptable mobile code within
information systems.

#### Additional Policy Guidance:

Mobile code technologies include, for example, Java, JavaScript,
ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and
VBScript.

### SC-18 Mobile Code Implementation 

Bureaus and offices implementing mobile code shall ensure compliance
with NIST Special Publication 800-19, *Mobile Agent Security*, and NIST
Special Publication 800-28, *Guidelines on Active Content and Mobile
Code*, to ensure adequate controls have been considered. This
methodology requires information System Owners to assess the risk of
harm to IT systems from allowing malicious mobile code, such as JAVA
script, to run on its systems. The mobile code and mobile agent
computing paradigm pose several privacy and security concerns, but
applications are currently being developed by industry, government, and
academia for use in such areas as telecommunications systems, personal
digital assistants, information management, parallel processing, and
computer simulation. Security issues include: authentication,
identification, secure messaging, certification, trusted third-parties,
non-repudiation, and resource control. Mobile agent frameworks must be
able to counter new threats as agent hosts must be protected from
malicious agents, agents must be protected from malicious hosts, and
agents must be protected from malicious agents. The National Institute
of Standards and Technology currently has a project under way to
evaluate security countermeasures to attacks from malicious mobile code.

## SC-19 -- Voice Over Internet Protocol

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall:

1.  Establish usage restrictions and implementation guidance for Voice
    over Internet Protocol (VoIP) technologies based on the potential to
    cause damage to the Moderate and High-impact information systems if
    used maliciously; and

2.  Authorize, monitor, and control the use of VoIP within Moderate and
    High-impact information systems.

3.  Implement VoIP in compliance with NIST Special Publication 800-58,
    Security Considerations for Voice Over IP Systems.

## SC-20 -- Secure Name/Address Resolution Service (Authoritative Source)

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems (i.e., authoritative domain name system (DNS)
servers) that provides name/address resolution service provides
additional artifacts (i.e., digital signatures and cryptographic keys)
along with the authoritative DNS resource records it returns in response
to resolution queries.

#### Policy Supplement(s):

SC-20(a)

Bureaus and offices shall comply with the guidance provided in NIST
Special Publication 800-81, Secure Domain Name System (DNS) Deployment
Guide for secure domain name system deployment.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  requiring information systems, when operating as                  
  part of a distributed, hierarchical namespace, to                 
  provide the means (e.g., delegation signor                        
  resource records) to indicate the security status                 
  of child subspaces and (if the child supports                     
  secure resolution services) enable verification of                
  a chain of trust among parent and child domains.                  
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514868 .anchor}Table 96: SC-20 -- Secure
Name/Address Resolution Service (Authoritative Source) Recommended
Policy Enhancement(s)

#### Additional Policy Guidance:

This requirement enables remote clients to obtain origin authentication
and integrity verification assurances for the name/address resolution
information obtained through the service.

## SC-21 -- Security Name/Address Resolution Service (Recursive or Caching Resolver)

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that High-impact information systems
(i.e., resolving or caching name server) that provide name/address
resolution service for local clients perform data origin authentication
and data integrity verification on the resolution responses it receives
from authoritative domain name system (DNS) servers when requested by
client systems.

#### Policy Supplement(s):

SC-21(a)

Bureaus and offices shall comply with the guidance provided in NIST
Special Publication 800-81, Secure Domain Name System (DNS) Deployment
Guide for secure domain name system deployment.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  requiring information systems to perform data                     
  origin authentication and data integrity                          
  verification on all resolution responses whether                  
  or not local DNS clients (i.e., stub resolvers)                   
  explicitly request this function.                                 
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514869 .anchor}Table 97: SC-21 -- Security
Name/Address Resolution Service (Recursive or Caching Resolver)
Recommended Policy Enhancement(s)

## SC-22 -- Architecture and Provisioning for Name/Address Resolution Service

#### Applicability:

Moderate and High Impact Information Systems

#### 

#### 

#### 

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems that collectively provide name/address resolution
service for an organization are fault tolerant and implement role
separation.

#### Policy Supplement(s):

SC-22(a)

If any bureau or office information technology resources are divided
into those resources belonging to internal networks and those resources
belonging to external networks, then authoritative DNS servers with two
roles (internal and external) shall be established.

SC-22(b)

The DNS server with the internal role shall provide name/address
resolution information pertaining to both internal and external
information technology resources while the DNS server with the external
role shall only provide name/address resolution information pertaining
to external information technology resources.

SC-22(c)

Bureaus and offices shall also specify a list of clients who can access
the authoritative DNS server of a particular role.

#### Additional Policy Guidance:

To eliminate single points of failure and to enhance redundancy, there
are typically at least two authoritative domain name system (DNS)
servers, one configured as primary and the other as secondary.
Additionally, the two servers are commonly located in two different
network subnets and geographically separated (i.e., not located in the
same physical facility).

## SC-23 -- Session Authenticity

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems provide mechanisms to protect the authenticity of
communications sessions.

#### 

#### 

#### Additional Policy Guidance:

This requirement focuses on communications protection at the session,
versus packet, level. The intent of this requirement is to implement
session-level protection where needed (e.g., in service-oriented
architectures providing web-based services). The Department of the
Interior requires the use of TLS versus SSL to ensure the protection of
federal information and to comply with FIPS 140-2 requirements.

# System and Information Integrity (SI) 

Integrity controls protect data from accidental or malicious alteration
or destruction and to provide assurance to the user the information
meets expectations about its quality and reliability. Bureaus and
offices shall comply with the NIST Special Publication 800-53, Rev.1,
*Recommended Security Controls for Federal Information Systems,* system
and information integrity controls listed in the following table:

+--------+-------------------------+-----------+-----------+----------+
|        |                         |           |           |          |
| System |                         |           |           |          |
| and    |                         |           |           |          |
| Infor  |                         |           |           |          |
| mation |                         |           |           |          |
| Int    |                         |           |           |          |
| egrity |                         |           |           |          |
+--------+-------------------------+-----------+-----------+----------+
|        |                         | Control   |           |          |
|        |                         | Baselines |           |          |
| C      | Control Name            |           |           |          |
| ontrol |                         |           |           |          |
| Number |                         |           |           |          |
+--------+-------------------------+-----------+-----------+----------+
|        |                         | Low       | Moderate  | High     |
+--------+-------------------------+-----------+-----------+----------+
| SI-1   | System and Information  | SI-1      | SI-1      | SI-1     |
|        | Integrity Policy and    |           |           |          |
|        | Procedures              |           |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-2   | Flaw Remediation        | SI-2      | SI-2 (1)  | SI-2 (1) |
|        |                         |           | (2)       | (2)      |
+--------+-------------------------+-----------+-----------+----------+
| SI-3   | Malicious Code          | SI-3      | SI-3 (1)  | SI-3 (1) |
|        | Protection              |           | (2)       | (2)      |
+--------+-------------------------+-----------+-----------+----------+
| SI-4   | Information System      | Not       | SI-4      | SI-4 (2) |
|        | Monitoring Tools and    | Selected  | (2)(4)    | (4) (5)  |
|        | Techniques              |           |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-5   | Security Alerts and     | SI-5      | SI-5      | SI-5 (1) |
|        | Advisories              |           |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-6   | Security Functionality  | Not       | Not       | SI-6     |
|        | Verification            | Selected  | Selected  |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-7   | Software and            | Not       | Not       | SI-7 (1) |
|        | Information Integrity   | Selected  | Selected  | (2)      |
+--------+-------------------------+-----------+-----------+----------+
| SI-8   | Spam Protection         | Not       | SI-8      | SI-8 (1) |
|        |                         | Selected  |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-9   | Information Input       | Not       | SI-9      | SI-9     |
|        | Restrictions            | Selected  |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-10  | Information Accuracy,   | Not       | SI-10     | SI-10    |
|        | Completeness, Validity  | Selected  |           |          |
|        | and Authenticity        |           |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-11  | Error Handling          | Not       | SI-11     | SI-11    |
|        |                         | Selected  |           |          |
+--------+-------------------------+-----------+-----------+----------+
| SI-12  | Information Output      | Not       | SI-12     | SI-12    |
|        | Handling and Retention  | Selected  |           |          |
+--------+-------------------------+-----------+-----------+----------+

[]{#__RefHeading___Toc193514870 .anchor}Table 98: System and Information
Integrity Controls

## SI-1 -- System and Information Integrity Policy and Procedures 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall develop, disseminate, and periodically review
and update:

1.  Formal, documented, system and information integrity policy that
    addresses purpose, scope, roles, responsibilities, management
    commitment, coordination among organizational entities, and
    compliance; and

2.  Formal, documented procedures to facilitate the implementation of
    the system and information integrity policy and associated system
    and information integrity controls.

## SI-2 -- Flaw Remediation

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall identify, report, and correct all information
system flaws.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall centrally manage   X              X
  the flaw remediation process and install updates                  
  automatically.                                                    

  \(2\) Bureaus and offices shall employ automated   X              X
  mechanisms to periodically and upon demand                        
  determine the state of information system                         
  components with regard to flaw remediation                        
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514871 .anchor}Table 99: SI-2 -- Flaw
Remediation Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

SI-2(a)

Bureau and office BCISO's shall identify any information system
containing software affected by recently announced software flaws (and
potential vulnerabilities resulting from those flaws) through frequent
vulnerability scanning, a comprehensive patch management program, and an
asset management program.

SI-2(b)

Bureaus and offices (or the software developer/vendor in the case of
software developed and maintained by a vendor/contractor) shall promptly
install newly released security relevant patches, service packs, and hot
fixes, and tests patches, service packs, and hot fixes for effectiveness
and potential side effects on information systems before installation
within in a production environment.

SI-2(c)

Bureaus and offices shall ensure that flaws discovered during security
assessments, continuous monitoring, incident response activities, or
information system error handling are also addressed expeditiously.

SI-2(d)

Bureaus and offices shall incorporate flaw remediation into
configuration management as an emergency change.

## SI-3 -- Malicious Code Protection 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that all information systems implement
malicious code protection that includes the capability for automatic
updates.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall centrally manage   X              X
  malicious code protection mechanisms                              

  \(2\) Bureaus and offices shall ensure that        X              X
  information systems automatically update malicious                
  code protection mechanisms.                                       
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514872 .anchor}Table 100: SI-3 -- Malicious
Code Protection Mandatory Policy Enhancement(s)

#### Policy Supplement(s):

SI-3(a)

Bureaus and offices shall employ malicious code protection mechanisms at
critical information system entry and exit points (e.g., firewalls,
electronic mail servers, web servers, proxy servers, remote-access
servers) and at workstations, servers, or mobile computing devices on
the network.

SI-3(b)

Bureaus and offices shall use malicious code protection mechanisms to
detect and eradicate malicious code (e.g., viruses, worms, Trojan
horses, spyware) transported:

1.  by electronic mail, electronic mail attachments, Internet accesses,
    removable media (e.g., USB devices, diskettes or compact disks), or
    other common means; or

2.  by exploiting information system vulnerabilities.

SI-3(c)

Bureaus and offices shall update malicious code protection mechanisms
(including the latest virus definitions) whenever new releases are
available in accordance with applicable bureau or office configuration
management policy and procedures.

## SI-4 -- Information System Monitoring Tools and Techniques

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall employ tools and techniques to monitor events
on Moderate and High-impact information systems, detect attacks, and
provide identification of unauthorized use of the systems.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(2\) Bureaus and offices shall employ automated   X              X
  tools to support near-real-time analysis of                       
  events.                                                           

  \(4\) Bureaus and offices shall ensure information X              X
  systems monitor inbound and outbound                              
  communications for unusual or unauthorized                        
  activities or conditions (e.g., the presence of                   
  malicious code, the unauthorized export of data,                  
  or signaling to an external information system).                  

  \(5\) Bureaus and offices shall ensure information                X
  systems provide a real-time alert when any                        
  indications of compromise or potential compromise                 
  occur.                                                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514873 .anchor}Table 101: SI-4 -- Information
System Monitoring Tools and Techniques Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider          X              X
  interconnecting and configuring individual                        
  intrusion detection tools into a system-wide                      
  intrusion detection system using common protocols.                

  \(3\) Bureaus and offices should consider                         X
  employing automated tools to integrate intrusion                  
  detection tools into access control and flow                      
  control mechanisms for rapid response to attacks                  
  by enabling reconfiguration of these mechanisms in                
  support of attack isolation and elimination.                      
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514874 .anchor}Table 102: SI-4 -- Information
System Monitoring Tools and Techniques Recommended Policy Enhancement(s)

## 

## SI-5 -- Security Alerts and Advisories 

#### Applicability:

All Information Systems

#### Policy Statement:

Bureaus and offices shall receive information system security
alerts/advisories on a regular basis, issue alerts/advisories to
appropriate personnel, and take appropriate actions in response.

Bureaus and offices shall monitor security and vulnerability alerts,
notices and advisories from DOI-CIRC, US-CERT[^14] (including monitoring
information provided through the G-FIRST Portal[^15]), and the NIST
Computer Security Resource Center (CSRC) NIST National Vulnerability
Database (NVD[^16]) website to ensure awareness of all newly discovered
and relevant vulnerabilities.

#### Policy Supplement(s):

SI-5(a)

Bureaus and offices shall document the types of actions to be taken in
response to security alerts/advisories.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall employ automated                  X
  mechanisms to make security alert and advisory                    
  information available throughout the organization                 
  as needed.                                                        
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514875 .anchor}Table 103: SI-5 -- Security
Alerts and Advisories Mandatory Policy Enhancement(s)

#### Additional Policy Guidance:

Bureaus and offices should also maintain contact with special interest
groups (e.g., information security forums) that:

-   facilitate sharing of security-related information (e.g., threats,
    vulnerabilities, and latest security technologies);

-   provide access to advice from security professionals; and

-   improve knowledge of security best practices.

## 

## SI-6 -- Security Functionality Verification 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that High-impact information systems
are configured to verify the correct operation of security functions:

1.  upon system startup and restart;

2.  upon command by user with appropriate privileges;

3.  periodically, at least weekly and;

4.  configured to notify the SA when anomalies are discovered.

#### Policy Supplement(s):

SI-6(a)

The need to verify security functionality applies to all security
functions.

SI-6(b)

For those security functions that are not able to execute automated
self-tests, bureaus and offices shall either implement compensating
security controls or explicitly accept and document the risk of not
performing the verification as required.

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices should consider                         X
  employing automated mechanisms to provide                         
  notification of failed automated security tests.                  

  \(2\) Bureaus and offices should consider                         X
  employing automated mechanisms to support                         
  management of distributed security testing.                       
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514876 .anchor}Table 104: SI-6 -- Security
Functionality Verification Recommended Policy Enhancement(s)

## 

## 

## 

## 

## 

## SI-7 -- Software and Information Integrity 

#### Applicability:

High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that High-impact information systems
are configured to detect and protect against unauthorized changes to
software and information.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall reassess the                      X
  integrity of software and information by                          
  performing monthly integrity scans of the system.                 

  \(2\) Bureaus and offices shall employ automated                  X
  tools that provide notification to appropriate                    
  individuals upon discovering discrepancies during                 
  integrity verification.                                           
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514877 .anchor}Table 105: SI-7 -- Software and
Information Integrity Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(3\) Bureaus and offices should consider          X              X
  employing centrally managed integrity verification                
  tools.                                                            
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514878 .anchor}Table 106: SI-7 -- Software and
Information Integrity Recommended Policy Enhancement(s)

***Policy Supplement(s***)

SI-7(a)

Bureaus and offices shall employ integrity verification applications on
High-impact information systems to look for evidence of information
tampering, errors, and omissions.

SI-7(b)

Bureaus and offices should use good software engineering practices with
regard to commercial off-the-shelf integrity mechanisms (e.g., parity
checks, cyclical redundancy checks, and cryptographic hashes) and use
tools to automatically monitor the integrity of information systems and
the applications they host.

## 

## 

## SI-8 -- Spam Protection

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure Moderate and High-impact information
systems implement spam protection.

#### Mandatory Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  MANDATORY ENHANCEMENT(S)                           APPLICABLITY   

                                                     MODERATE       HIGH

  \(1\) Bureaus and offices shall centrally manage                  X
  spam protection mechanisms.                                       
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514879 .anchor}Table 107: SI-8 -- Spam
Protection Mandatory Policy Enhancement(s)

#### Recommended Policy Enhancement(s):

  -------------------------------------------------- -------------- ---------
  RECOMMENDED ENHANCEMENT(S)                         APPLICABLITY   

                                                     MODERATE       HIGH

  \(2\) Bureaus and offices should consider                         X
  configuring information systems to automatically                  
  update spam protection mechanisms.                                
  -------------------------------------------------- -------------- ---------

[]{#__RefHeading___Toc193514880 .anchor}Table 108: SI-8 -- Spam
Protection

#### Policy Supplement(s):

SI-8(a)

Bureaus and offices shall employ spam protection mechanisms at critical
information system entry points (e.g., firewalls, electronic mail
servers, remote-access servers) and at workstations, servers, or mobile
computing devices on the network.

SI-8(b)

Bureaus and offices shall use spam protection mechanisms to detect and
take appropriate action on unsolicited messages transported by
electronic mail, electronic mail attachments, Internet accesses, or
other common means.

## 

## 

## 

## 

## SI-9 -- Information Input Restrictions

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall restrict the capability to input information
to Moderate and High-impact information systems to authorized personnel.

#### Additional Policy Guidance:

Restrictions on personnel authorized to input data to Moderate and
High-impact information systems may extend beyond the typical access
controls employed by the system and include limitations based on
specific operational/project responsibilities.

## SI-10 -- Information Input Accuracy, Completeness, Validity and Authenticity

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems check data for accuracy, completeness, validity, and
authenticity.

#### Policy Supplement(s):

SI-10(a)

Bureaus and offices shall ensure that checks for accuracy, completeness,
validity, and authenticity of information are accomplished as close to
the point of origin as possible.

SI-10(b)

Bureaus and offices shall ensure that rules for checking the valid
syntax of information system inputs (e.g., character set, length,
numerical range, acceptable values) are in place to verify that inputs
match specified definitions for format and content.

SI-10(c)

Bureaus and offices shall ensure that information system inputs passed
to interpreters are prescreened to prevent the content from being
unintentionally interpreted as commands.

SI-10(d)

The extent to which information systems are able to check the accuracy,
completeness, validity, and authenticity of information shall be guided
by bureau or office policies and operational requirements.

## SI-11 -- Error Handling

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall ensure that Moderate and High-impact
information systems identify and handle error conditions in an
expeditious manner without providing information that could be exploited
by adversaries.

#### Policy Supplement(s):

SI-11(a)

Bureaus and offices shall carefully consider the structure and content
of error messages.

SI-11(b)

Bureaus and offices shall ensure that error messages are revealed only
to authorized personnel.

SI-11(c)

Error messages generated by information systems shall provide timely and
useful information without revealing potentially harmful information
that could be used by adversaries.

SI-11(d)

Bureaus and offices shall ensure that sensitive information (e.g.,
account numbers, social security numbers, and credit card numbers) is
not listed in error logs or associated administrative messages.

SI-11(e)

The extent to which the information system is able to identify and
handle error conditions shall be guided by bureau or office policies and
operational requirements.

## 

## 

## 

## 

## SI-12 -- Information Output Handling and Retention

#### Applicability:

Moderate and High Impact Information Systems

#### Policy Statement:

Bureaus and offices shall handle and retain output from all information
systems in accordance with applicable laws, directives, policies,
regulations, standards, and operational requirements, to include DOI
Records Retention Policies

# Standards 

# ACCEPTABLE USE SECURITY STANDARD

## Mandatory Standard Guidelines 

This standard establishes the acceptable use of information systems that
support the Department of the Interior (Interior). This includes the use
of information systems, Internet access, and electronic mail (e-mail).
Using Interior information resources for inappropriate, unauthorized, or
unlawful activities can seriously undermine the ability of our bureau
missions to ensure confidentiality, integrity, and availability. Users
shall make every effort to employ Interior information resources in an
appropriate and acceptable manner, according to the guidelines defined
in this standard.

## Standard Detail

#### Official Business 

The Interior provides information resources for the purpose of
transacting official business. Official business may be defined as any
information processing that is required to perform associated work
responsibilities.

Official business includes, but is not limited to, the performance of
Interior work- related duties in position descriptions, professional
training, and tasks directed via contracts and support activities
related to contract tasking. However, OCIO authorizes limited personal
use provided this use involves minimal expense to the Government and
does not interfere with official business.

##### Rules of Behavior 

Rules of behavior guidelines for the use of Interior information systems
include, but are not limited to, the following:

1.  Users shall protect their UserIDs and passwords from disclosure in
    accordance with the ***Authorization and Access Control Security
    Standard*** or its replacement.

2.  Users shall ensure that password resets are performed securely in
    accordance with the ***Authorization and Access Control Security
    Standard*** or its replacement.

3.  Users shall change their password if compromised, i.e., someone else
    knows their password. Users shall immediately notify their
    supervisor or security administrator for all suspected or confirmed
    password compromises. Passwords will be changed in accordance with
    the ***Authorization and Access Control Security Standard*** or its
    replacement.

4.  Users shall not program their login or password into automatic
    script routines or programs in accordance with ***Authorization and
    Access Control Security Standard*** or its replacement.

5.  Users shall log off, sign off, or lock the computer system when
    going to lunch or a break, or any time they leave their computer or
    terminal.

6.  Users shall retrieve all hard-copy printouts in a timely manner. If
    the originator or receiver of a printout cannot be determined,
    dispose of it accordingly.

7.  Users shall inform their supervisor about all sensitive applications
    or data that will be placed on a system and on any equipment
    processing sensitive information, so that appropriate security
    measures can be implemented.

8.  Users must not use Interior computers or licensed software for
    personal use beyond those set by the limited personal use
    Standard. - ***Acceptable Use Security Standard***

9.  Users shall not use personal equipment or software for official
    business or to access, process, store, and/or transmit and
    Personally Identifiable Information (PII) or any other sensitive
    agency information.

10. Users will not install or use unauthorized software on Interior
    equipment to include the use of freeware, shareware, or
    public-domain software.

11. Users shall comply with local office standard on the use of
    antivirus software in accordance with ***Virus Protection Security
    Standard*** or its replacement.

12. Users shall observe all software license agreements and will not
    violate federal copyright laws.

13. Users will not make illegal or unauthorized copies of any
    copyrighted material. This includes (but is not limited to) text,
    graphics, photos, videos, music, clipart, etc.

14. Users will not move equipment or exchange system components without
    their manager's or supervisor's approval.

15. Interior computer equipment shall be physically protected from
    hazards such as liquids, food, staples, and paper clips. Refer to
    ***Physical Access Security Standard***, or its replacement, for
    additional information.

16. Users shall properly protect and label magnetic media in accordance
    with ***Data Management Security Standard*** or its replacement.

17. Users must not disclose any dial-in telephone numbers or procedures
    that permit system access from a remote location. Refer to
    ***Network Access Security Standard***, or its replacement, for
    additional information.

18. Users shall not disclose or discuss any Interior information,
    whether sensitive or non-sensitive, with unauthorized individuals.
    The Privacy Act of 1974, 5 U.S.C. 552a, prohibits such disclosure.
    Refer to ***Information Classification Security Standard***, or its
    replacement, for additional information.

19. Users shall be cognizant of the nature of security incidents and
    must promptly report them to their supervisor in accordance with
    Incident Identification, Declaration, Reporting, and Handling
    Security Standard or its replacement. Examples include, but are not
    limited to, unauthorized disclosure of information, computer
    viruses, theft of equipment, software, or information, inappropriate
    use, and deliberate alteration or destruction of data or equipment.

##### Personal Use 

Appropriate Use - Limited personal use of Interior information systems
is permitted if it is determined that such use:

1.  Does not adversely affect the performance of official duties

2.  Are of reasonable duration and frequency

3.  Activities can be conducted securely and create little impact on
    Interior IT assets or co-workers.

4.  Does not put Federal Government Information systems to uses that
    would reflect adversely on the Interior, to include activities that
    are illegal, inappropriate, or offensive to fellow employees,
    partners, contractors or the public.

##### Inappropriate Use 

Inappropriate personal use of Interior information systems include, but
are not limited to:

1.  Any personal use that could cause negligible congestion, delay, or
    disruption of service to any Government system or equipment, to
    include:

2.  Use of any personal remote access device while connected to any
    Interior LAN to include the use of modems, cellular modems, PDAs,
    etc.

3.  Playing online electronic games (see ***Acceptable Use Security
    Standard*** ).

4.  Use of "Push" technology on the Internet and other continuous data
    streams, i.e., streaming video/music/radio broadcasts, and ticker
    tape banners such as stock quotes, weather, etc., that would degrade
    the performance of the entire network

5.  Creating, copying, transmitting, or retranslating chain letters or
    other unauthorized mass mailings

6.  Unauthorized use of instant messaging to include AOL Instant
    Messenger, Yahoo Instant Messenger, ICQ, Microsoft, etc.

7.  Use of peer-to-peer file sharing applications such as Gnutella,
    KaZaA, Musiccity.com, BearShare, LimeWire, XoloX, Auto galaxy,
    Direct Connect, ToadNoad, WinMx, Napigator, Morpheus, CuteMx, Scour
    Exchange, FreeNetfile, eDonkey, and iMesh

8.  Activities that are illegal, inappropriate, or offensive to fellow
    employees, partners, contractors or the public

9.  Creating, downloading, viewing, storing, copying, or transmitting;
    sexually explicit or sexually oriented materials, material related
    to illegal gambling, illegal weapons, terrorist activities, and any
    other illegal activities otherwise prohibited

10. Use of Interior information systems for commercial profit-making
    activities in support of other outside employment or business
    activities

11. Engaging in any outside fundraising activity, endorsing any product
    or service, participating in any lobbying activity, or engaging in
    any prohibited partisan political activity

12. Use for posting Interior information to external newsgroups,
    bulletin boards, or other public forums without authority

13. The unauthorized acquisition, use, reproduction, transmission, and
    distribution of computer software or other material protected by
    national or international copyright laws, trademarks, or other
    intellectual property rights

14. Representing one's self as someone else

15. Soliciting Government employees or providing information about or
    lists of Interior employees to others outside the Government without
    authorization

16. Any personal use that Interferes with the employee's job, the jobs
    of other employees, or the operation of the Internet gateways

17. Any type of personal solicitation

18. Modifying Government office equipment for non-Government purposes,
    including loading personal software or making configuration changes

19. Intentionally or negligently causing the propagation of viruses,
    Trojan horses, or other malicious software

20. Installing any unauthorized hardware or software that allows remote
    access to their computers, servers, or network e.g. Go2MyPC,
    pcAnywhere, Modem with RAS, etc.

21. Allowing any unauthorized individual to access and/or use any
    Government system or equipment (e.g., another family member, friend,
    etc.)

##### E-Mail Use 

#### Appropriate E-Mail Use 

Appropriate e-mail use includes, but is not limited to:

1.  Limited personal use of the Interior e-mail system during an
    employee's non- work time, such as break times and lunch periods

2.  Any message containing information exchanged by employees for the
    purpose of accomplishing government business

3.  Use of the Interior e-mail system by authorized users that does not
    interfere with official business nor reflect adversely on the
    Interior

4.  E-mail message forwarding, to only another appropriate authorized
    DOI email account within the DOI controlled e-mail environment, or
    some other secure method shall be employed when an addressee is
    unavailable to receive mail that is required to move business
    processes ***Acceptable Use Security Standard***

5.  The use of Notepad to open e-mail attached files ending with the
    extensions .vb, .vbe, .vbs, .wsc, .wsh, .wsf, .pif, .scr, .reg, .js,
    and jse to limit the spread of various VBScript viruses and worms

6.  Access to the Interior e-mail system by users when they are not at
    their duty station site, or at another installed site, shall only
    occur through the secured Interior dial-up or VPN access points

7.  Transmitting sensitive information that is encrypted and password
    protected to include, but not limited to, the following:

    a.  Proprietary Interior and Interior information

    b.  U.S. Government credit card numbers

    c.  Designated For Official Use Only (FOUO), Sensitive But
        Unclassified (SBU), or Sensitive Security Information (SSI)
        information

    d.  Risk assessments, audit findings, or any other documentation
        containing known Interior information system vulnerabilities

    e.  Privacy Act data

    f.  Interior network access information to include, but not limited
        to, IP addresses and local/remote workstation IP addresses, port
        numbers, dial-in access numbers, or associated system passwords
        used for gaining entry to networks

In transmitting sensitive agency information to another authorized
individual, the originator must ensure that the recipient will comply
with the requirements of DOI IT security policies to further safeguard
the information consistent with the requirements of this policy handbook
and only using government-owned or contractor approved equipment (use of
personally-owned equipment is prohibited).

##### Inappropriate E-Mail Use 

Inappropriate e-mail use includes, but is not limited to:

1.  Sharing a UserID and password to obtain access to another user's
    mail for any purpose

2.  Opening attached file extensions on Interior e-mail servers to
    include .ade, .adp, .bas, .bat, .chm, .cmd, .com, .cpl, .crt, .exe,
    .hta, .ins, .isp, .lnk, .mda, .mde, .mdz, mp3, .msc, .msi, .msp,
    .mst, ocx, .pcd, .pif, .reg, .sct, and .shs

3.  Using a personal Internet Service Provider (ISP) to gain access to
    the Interior e-mail system or for any other system operation or
    service without an approved and authenticated VPN connection
    utilizing FIPS 140-2 encryption.

4.  Using wireless service providers outside of Interior approved
    Federal facilities is forbidden unless the whole of the E-Mail
    session is encrypted.

5.  Transmission of any unencrypted and non-password protected sensitive
    information.

E-mail privileges will be removed immediately if other than acceptable
or appropriate use is discovered.

##### Internet Use 

Appropriate Internet use includes, but is not limited to:

1.  Limited personal use of the Internet during an employee's
    non-worktime

2.  Communications and exchange of data between state and local
    governments, private sector organizations, and educational and
    research institutions, both in the United States and abroad

3.  Development of Internet Web-based projects as established by
    business need

4.  Sharing of information without compromising Interior secured data

5.  Exchange of any inter-Agency non-sensitive data in support of
    departmental mission, Interior missions, or other official purposes

6.  Distribution and collection of information related to official
    program delivery.

7.  Transmitting U.S. Government credit card numbers for legitimate
    official business, i.e., booking air, car, or hotel information at a
    secured website for purposes of official Government travel
    ***Acceptable Use Security Standard***

##### Inappropriate Internet Use

Inappropriate Internet use includes, but is not limited to:

1.  Purposely visiting adult entertainment, pornographic, and gambling
    websites

2.  Downloading, copying, sharing, or sending software, music, videos,
    movies, or pictures (whether purchased or not purchased) that are
    not job related as use of these constitutes copyright violations and
    is a non-business use of limited network bandwidth

3.  Peer-to-peer software and file sharing products not expressly
    identified for authorized use may not be used on or through Interior
    servers and workstations

4.  Subscribing to 'list servers', 'use groups', or 'bulletin boards'
    that do not align to authorized business needs

5.  Personal use of streaming video, music and radio, as it consumes
    bandwidth and could cause congestion, delay, or disruption of
    service due to bandwidth constraints. see *Audit Security Standard.*

# AUDIT SECURITY STANDARD

## Mandatory Standard Guidelines 

This standard establishes the Security Auditing program for information
systems (hardware, software, and networks) supporting the Interior and
its partners. This standard describes security audit methods required to
ensure the confidentiality, integrity, and availability of Interior
information resources. Security auditing shall be used to detect or
investigate actual or attempted security violations in any Interior
information system by recording security relevant events as they occur.
Security auditors, with assistance from OCIO administrator staff, Office
of the Inspector General (OIG), and other Human Resources (HR) approved
personnel, may monitor users or system activities and ensure conformance
to Interior Security Policies.

## Standard Detail

Interior Security Auditing will be performed in a two-part process that
includes the Security Audit and the Security Audit Follow-Up.

### Security Audit 

-   Security audits shall be conducted on a defined frequency to ensure
    compliance with established security standard, guidelines, and
    procedures, and to determine the minimum set of controls required to
    reduce risk to an acceptable level.

-   Audit steps shall include defining the audit scope and objectives,
    planning the audit, collecting audit data, performing audit tests,
    reporting for audit results, protecting audit data and tools, making
    enhancements, and follow-up.

-   Security audits for the installation and/or enhancements to a new or
    existing information system shall be performed prior to
    implementation to ensure conformance to security policies and
    procedures.

-   Security audits for existing systems shall be conducted on a defined
    basis by either manual or computerized processes using automated
    tools to detect security loopholes or vulnerabilities.

-   Security audits shall include general control reviews, system
    reviews, and penetration testing.

-   Random audits shall be performed using arbitrary inspections to
    ensure adherence to Interior security policies and procedures.

Annual assessments of the security of Interior information systems shall
be performed using guidelines established in the ***[Interior Security
Procedures Manual, Audit Security Procedures (Nov 2007)]{.underline}***
or its replacement. These assessments will include a review of the
resource's audit functions and activities.

If a security issue is identified during the weekly audit review or
through other means, the incident shall be reported in accordance with
Incident Identification, Declaration, Reporting, and Handling Security
Standard or its replacement. Consistent with their responsibilities for
oversight of proper use of Interior information systems, the Interior
Chief Information Security Officer, the Interior CIO, or any Interior
Bureau Chief Information Security Officer may audit any Interior
information system at any time.

At a minimum, security audits shall be performed as necessary for backup
controls, system and transaction controls, data library procedures,
systems development standards, physical security of information systems,
contingency plans, and database management.

When possible all audit logs should be reviewed on a daily basis. At a
minimum Audit Logs of information systems shall be reviewed on a weekly
basis. Established reporting mechanisms shall be used to convey the
results of the weekly audit. Audit logs shall be archived on a weekly
basis and shall be retained until deemed unnecessary. Audit logs no
longer needed may be disposed of as defined in ***[Media Sanitization
and Disposal Security Standard]{.underline}*** or its replacement.

Interior information systems shall incorporate capabilities to log
resource use with all logged activities identified by date and time of
occurrence. Logs of activities related to the use of information systems
shall be protected at the same level of the information being processed
by the resource and released only to authorized individuals.

Audit reports shall contain sufficient information to enable the review
staff, with no previous connection with the audit, to ascertain the
evidence that supports the auditors' significant conclusions and
judgments.

### Security Audit Follow-Up 

The effective implementation of audit recommendations is a major benefit
of security auditing. When a security auditor provides a recommendation,
management is responsible for placing it into practice. If management
has made the decision to not implement a recommendation for moderate and
high-risks, they may accept the associated security risk. **[This
acceptance of the risk must be documented and signed by the appropriate
level of management.]{.underline}**

The two major areas of concern with regard to recommendations made in
the security risk assessment and audit include:

-   Effective and qualified recommendations presented by security
    auditors

-   Monitoring and follow-up of security audit results by management.

## Notice of Finding and Recommendations

Ensure independent third-party reviews or audits are performed at least
quarterly to verify that passwords for such accounts have been changed
within the required intervals.

Ensure independent third-party reviews or audits are performed, to the
extent practicable, to verify that passwords for accounts are changed
more frequently, if needed (i.e., when there are changes to employment
status or assigned duties, roles, or responsibilities of individuals
having knowledge or access to account passwords.)

[]{#__RefHeading___Toc193514624 .anchor}**AUTHORIZATION and ACCESS
CONTROL SECURITY STANDARD**

## Mandatory Standard Guidelines 

This policy establishes standards for managing user accounts, non-user
accounts, and administrative accounts with access to information systems
(hardware, software, and networks) supporting the Department of the
Interior. The purpose of this standard is to ensure that necessary
authorization and access controls are in place for controlling the
actions, functions, applications, and operations of legitimate users.
The aim is to protect the confidentiality, integrity, and availability
of all Interior information resources.

## Standard Detail

### Authorization and Access Guidelines 

The Bureau Chief Information Security Officer (BCISO) has authorization
to restrict access to system objects such as files, directories,
devices, databases, and programs, based on user identity, least
privilege, and a need-to-know. All access to Interior information
systems shall be limited to only the resources that a user needs to
complete or facilitate official duties. Need-to-know may be modified
based on temporary assignments or projects with modifications requested
or initiated by the manager of the information system.

Access control mechanisms shall, either by explicit user (manager)
action or documented default, provide that objects are protected from
unauthorized access. These controls shall be capable of including or
excluding access to the granularity of a single user.

Access permission to an object by users not already possessing
permission to access sensitive information shall be granted only by the
assigned manager. Access control includes the construction of Access
Control Lists (ACL) or modification of system/object parameters. ACLs
shall be documented by the system administrator, updated each time there
is a change in an object's accessibility, and deleted when no longer
needed.

### User Account and Password Guidelines 

Procedures for the administration of user passwords are located in
***[Administrative Guidance for User Passwords.]{.underline}***

#### Account Management 

All authorizations to access and use Interior information systems will
be granted based on official business need. All managers of Interior
information resources will ensure access to information is properly
authorized and granted with correct access levels and least privileges
applied. Each user access will be identified to an individual and will
not be shared. If a process cannot be specifically tied to an
individual, then the password lifetime will be issued for the period of
the session.

All user accounts must be unique and traceable to the assigned user. All
Interior participant organizations will take appropriate measures to
protect the privacy of user information associated with user accounts.
The use of group accounts and group passwords is not permitted unless
specifically approved by the system owner.

Each Interior participant organization manages user account access for
Interior systems within their area of responsibility. Interior
guidelines for account setup and management must be applied consistently
to be effective. The following Authorization and Authentication Control
Security Standard guidelines shall be adhered to when establishing or
modifying a non-administrative account:

1.  The creation of a user account must be initiated through a request
    form and be authorized by pertinent levels of management.

2.  Modification to an existing account, i.e., to increase
    responsibility, must be initiated through a request form and
    authorized by pertinent levels of management.

3.  Records of processed and denied requests for the creation and/or
    modification of user accounts must be kept for auditing purposes.
    Records will be retained for one year, unless otherwise specified by
    Interior.

4.  Granting access levels to resources shall be based on the principle
    of least privilege, job responsibilities, and separation of duties.

5.  Accounts will be disabled after an identified period of inactivity.

6.  All requests for temporary user accounts shall provide an expiration
    date to be applied at the time the account is created.

7.  Management access to user accounts will be limited to business
    purposes only, such as during an emergency or contingency situation,
    cases of extended user absence, or user abuse of Interior
    information resources.

8.  Personnel transferring from one area of responsibility to another
    shall have their access accounts modified to reflect their new job
    responsibilities.

9.  Each Interior participant organization will create procedures to
    immediately cancel account access and physical access for users
    whose relationship with the Interior has concluded, either on
    friendly or unfriendly terms.

10. User account sessions will time-out in the event of inactivity. This
    includes user connections to the Internet or to specific
    applications.

11. User account access points for remote computing devices shall be
    configured using necessary identification and authentication
    technologies to meet security levels of physically connected
    computers. Refer to ***Network Access Security Standard*** or its
    replacement.

12. All new information systems acquired or developed by Interior and
    bureaus to support program requirements will incorporate access
    controls to properly protect the Interior information systems.

13. Temporary access to resources categorized as sensitive (i.e.,
    SBU/SSI) will be set with expiration dates where possible.

##### Account Guidelines 

1.  Interior information systems must require that each user have a
    unique identifier and to be successfully authenticate to gain
    access.

2.  Interior information systems must not allow anonymous, guest, or
    shared account access unless authorized by the BCISO.

3.  UserID configuration will be established based on the requirements
    of the information system.

4.  The naming convention for accounts must be standardized per system.

5.  Users shall not have different account IDs on the same system, i.e.,
    one user account per user per system, unless authorized by the
    BCISO; users with administrative privileges may have a second
    account specifically for the purpose of system administration.

6.  The system shall disable a user's account following consecutive
    failed login attempts. Once disabled, the account must be locked
    from access and scheduled to reset automatically or by administrator
    intervention.

7.  The system must invoke an automatic password-protected screen saver
    and provide users with the ability to invoke a password-protected
    screen saver on demand.

##### Password Guidelines 

1.  Each Interior participant organization will implement appropriate
    password procedures and technology to enforce this standard.

2.  Strong passwords shall be selected that are not the same or reverse
    as their UserID, are not the user\'s name or initials, and are not
    words commonly found in a dictionary.

3.  Personal information (e.g. telephone numbers, names of family
    members, pets, etc.) shall not be used as passwords.

4.  The Interior mandatory minimum password length of at least 12
    alphanumeric characters with a mixture of letters, numbers and
    special characters will be established.

5.  Passwords shall not include vendor/manufacturer-supplied passwords,
    names (i.e., system user names, family names, words spelled forward
    or backward), addresses or birthdays, or common character sequences
    (i.e., 3456, ghijk, 2468). Vendor and/or manufacturer-supplied
    default passwords, such as "SYSTEM", "Password", "Default", "USER",
    "Demo", or "TEST", shall be replaced immediately upon implementation
    of a new system.

6.  Passwords shall not be shared.

7.  In the event a password is used for administration or to facilitate
    testing, it shall be changed immediately upon completion of the test
    effort.

8.  Known or suspected compromises of passwords shall be immediately
    reported to a supervisor, manager, help desk, or appropriate
    security representative.

9.  Passwords are strictly prohibited from being written down and stored
    in (list finders, desk drawers, and etc.) and taped to desks, walls,
    or terminals.

10. Passwords and user IDs shall not be stored in an unsecured computer
    file. This is especially important for laptop, notebook, and
    handheld computers since they are easy targets for theft.

#### Administrative and Non-User Account and Password Guidelines 

Non-user accounts include system service and application-required
accounts, and accounts that will be used to run administrative system
services as well as regularly scheduled "jobs" or tasks. Most services
will use SYSTEM/LOCAL accounts unless a domain level account is
required.

In addition to the guidelines for non-administrative accounts and
passwords, system administrators, system owners, and system developers
shall also follow the standard in the sections below for administrative
and non-user accounts.

##### 

##### Administrative Account Management 

1.  Administrative accounts shall only be used for discriminate purposes
    to ensure that each administrative user is accountable for their
    actions by ensuring specific events can be associated with an
    authenticated UserID (i.e., non- repudiation). Login under generic
    system and administrative accounts is prohibited.

2.  Administrative accounts shall be limited and access controlled in
    accordance with Departmentally-established need-to-know concepts.

##### Administrative Password Guidelines 

1.  Each Interior information system shall have a unique administrative
    password and the system must prompt for a change of the
    administrative password at least once every 60 days.

2.  Administrative passwords must not be passed in clear text across an
    internal Interior network or an external network.

3.  System administrators will change the administrative password when
    they revoke an administrative user's account.

4.  Prior to a system being put into production, default or temporary
    passwords used in testing shall be changed and documented.

5.  Careful precautions shall be exercised by system administrators to
    prevent loss and/or compromise of administrative passwords. Each
    Interior organization must enact procedures for the secure archival
    and retrieval of administrative passwords in cases of emergency.
    These guidelines are as follows:

6.  A copy of the current administrative password for each system shall
    be archived in a physically secure location that prevents undetected
    and unauthorized access to the password (i.e., stored in an
    operational electronic-media or physical safe).

7.  The BCISO shall maintain control of the administrative password
    archive. This archived password is for emergency use only. The BCISO
    must authorize and track access to the archived password under
    emergency procedures. The administrative password shall be changed
    immediately after emergency access to the archived password has been
    made. While ultimately accountable, the BCISO may delegate this
    authority to other responsible parties for reasons of practicality.

##### Non-User Account Management 

1.  Non-user accounts will be granted the appropriate security options
    to support the process on the server, workstation, or laptop where
    the service is operational.

2.  Non-user accounts, though they may be members of a domain
    administration level group, will never be granted domain
    administration authority, unless authorized as exception for IT
    Security assessments such as an authorized vulnerability assessment
    tool, and tracked by the BCISO.

3.  Non-user accounts will never be directly accessible by users.

4.  Non-user accounts will have descriptive text that minimally explains
    the purpose of the account and where it is used.

5.  Non-user accounts within the Interior environment will have
    descriptive text in the Active Directory (AD) that minimally
    explains the purpose of the account, and where it is used.

6.  The true identification of the account will be maintained in a
    secured document outside of the environment.

7.  The creation of a non-user account requires use of the Change
    Management (CM) process for any account requested.

8.  Non-user accounts contained within the Interior environment that are
    not defined via current documentation or were not created as part of
    the CM process are subject to removal or being disabled.

9.  Non-User Password Guidelines

10. Passwords for non-user accounts will not have expiration dates
    enforced through technical means so as to prevent potential adverse
    impact to operations. However, processes and procedures should be in
    place to ensure that such accounts have passwords changed at least
    once every 60 days.

11. Passwords for non-user accounts will be computer generated.

12. Passwords for non-user accounts will be a minimum 12 characters in
    length.

13. Non-user passwords must contain the same 3 levels of minimum
    complexity as any other type of account.

##### Periodic Validation of User Access and Account Privileges 

1.  System owners and system administrators are responsible for
    performing a review of access authorization listings at least
    quarterly to determine whether they remain appropriate. This applies
    to operating systems and applications.

2.  System owners and system administrators are responsible for
    requesting weekly and monthly updates on user employment status from
    the Human Resources Department to ensure access and account
    privileges are valid.

3.  System administrators shall immediately remove or change access when
    users are terminated or transferred.

4.  A current list of authorized system users and their associated
    access authorizations shall be maintained by all system
    administrators in a readily-accessible database that is
    password-protected and stored on a secure server. The password used
    for access to this information is to be kept under locked storage
    and managed by the BCISO. The BCISO may delegate these duties when
    applicable, but is accountable for all password information
    protected in this manner.

5.  System administrators shall identify accounts that have been
    inactive more than 30 days. System Administrators shall disable
    accounts that that have been inactive for 90 days. Administrators
    must delete the account if the user is no longer employed,
    contracted by, or engaged in an active volunteer or partnership
    relationship with Interior or if the user no longer has a valid
    business need to access the system.

6.  Access authorizations shall be documented on standard forms and
    maintained on file; approved by the appropriate level of management;
    and securely transferred to local security administrators.

##### Administrative Guidance for User Passwords 

1.  Passwords shall not be distributed through non-encrypted electronic
    mail, voice-mail, or left on answering machines.

2.  Passwords used for dial-up authentication shall be changed at a
    minimum of every 60 days.

3.  Passwords for all systems, applications or processes shall be
    changed every 60 days for non-administrative users.

4.  The use of automatic logon software to circumvent password entry
    shall not be allowed, except with specific approval from the BCISO,
    for special tasks such as automated backups.

5.  Passwords for servers, mainframes, telecommunications devices, i.e.,
    routers and switches, and devices used for IT security functions,
    i.e., firewalls, intrusion detection, and audit logging, shall be
    encrypted when stored electronically.

6.  Passwords shall be encrypted when transmitted across a local area
    network, wide area network, or the Internet.

7.  Passwords used to access Internet or remote systems shall be
    different from passwords used to access internal systems and
    applications.

8.  Passwords for access to individual workstations (such as passwords
    for screen savers) shall be encrypted when stored electronically.

9.  The system shall provide users with a warning before their password
    expires.

10. The system must require new users to change their temporary/default
    password after the first use of their account and/or after the
    password has been reset to a temporary/default password.

11. If using automated login scripts for system access, the script shall
    not contain the user's login password with the exception of non-user
    access.

12. Compromised passwords shall be disabled immediately upon detection
    and a new password issued.

13. Before placing a system into a production environment, system
    administrators must change all default passwords and all passwords
    that were used in the development environment.

# CONTINGENCY and DISASTER RECOVERY SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes that Information Technology (IT) Contingency
and Disaster Recovery Plans shall be developed and maintained for the
Interior. This process includes contingency and disaster recovery
planning for information systems supporting Interior operational and
business activities. These plans will be tested periodically to ensure
they reflect current operating conditions and address current threats.

The following Federal guidelines require Interior information systems to
have plans for contingencies and disaster recovery in determination of
the proper actions to accomplish in the event of a disaster:

-   OMB Circular A-130, Appendix III requires agencies have the ability
    to recover and provide service sufficient to meet the minimal needs
    of users.

-   NIST Publication 800-34, Contingency Planning Guide for Information
    Technology Systems, provides guidance that is used to establish the
    Interior Information Survivability Program.

These contingency and disaster recovery plans require the involvement of
all Interior users to ensure an effective response to contingencies and
disasters; it must incorporate the physical and logistical limitations
of the Interior operating locations; and will be aligned with existing
Interior standard.

## Standard Detail

#### Contingency and Disaster Recovery Planning 

#### IT Contingency and Disaster Recovery Plans 

The Interior shall develop IT contingency and disaster recovery plans to
meet the needs of critical operations and essential functions during any
emergency or situation that may disrupt normal operations. These plans
shall describe the actions to be taken before, during, and after events
that disrupt critical information systems operations. The contingency
and disaster recovery plans should be reviewed for accuracy and
completeness at least annually as well as upon significant changes to
any element of the plan, system, or resources used for recovery
procedures. Testing should occur at least annually or when significant
changes are made to the information system or the disaster recovery
plan.

##### IT Contingency Plan -- 

An IT contingency plan is the same as the continuity of support plan
required by OMB Circular A-130. This plan provides procedures and
capabilities for recovering a critical application or general support
system following a minor or serious disruptive event.

##### Disaster Recovery Plan -- 

A disaster recovery plan provides detailed procedures for recovering
operability of the target system, application, or computer facility at
an alternate location. It is the responsibility of Interior, including
large offices and field service offices, to develop, test, implement,
and maintain IT contingency and disaster recovery plans for all mission
critical systems in support of critical business functions. All
contingency and disaster recovery plans must be well written, routinely
reviewed, tested, and updated to provide for reasonable continuity of
information systems support in the event of a disaster. Contingency and
disaster recovery measures shall be identified and integrated into all
phases of the System Development Life Cycle (SDLC).

Prioritization of Recovery Activities and their supporting information
systems at each location will be prioritized by Interior management to
determine the criticality of each system and the order of restoration
during a contingency or disaster situation. Mission critical operational
systems and their components will be established and maintained for each
site. This list will be part of the contingency plan. Prioritization
will address the categorization of information systems including
hardware, software, and networks.

##### Contingency Response Team 

Each contingency plan will establish a contingency response team and
will assign staff to functional contingency and disaster recovery teams
in accordance with the needs of the facility. Each staff member must
know the activities assigned to them under the contingency and disaster
recovery plan.

Contingency team members may not necessarily be the same resources as
assigned to the Incident Response Team (IRT). A checklist for each team
position that assigns responsibility for the tasks each team member will
be completed during a contingency or disaster. Personnel assigned to the
contingency response team, as well as those responsible for specific
systems, will be trained.

##### Contingency Plan Testing 

The contingency plan will be tested at least annually. The testing
process will be organized to examine all plan elements and related
operational procedures at least once annually. Where possible, testing
will be integrated with the testing of other site response plans. After
action reports will include lessons learned from the testing,
deficiencies noted during the testing, and a plan to remedy those
deficiencies. The Interior CIO will ensure funding is included in the
annual budget to support the contingency testing program.

#### Alternate Operating Capability 

Each Interior operating location will have a designated alternate
location for establishing temporary control of information resources
during a contingency or disaster. Normally such a site will be
geographically removed from the immediate disaster location, if
possible.

##### System Redundancy 

System owners will determine and implement a cost-effective means for
providing redundant operations at all locations affected. This includes
maintaining suitable spares or replacement equipment for all mission
critical systems.

##### 

##### Information Back Up and Recovery

The Interior will establish operations procedures for creating,
maintaining, and storing information backup media to support contingency
response and disaster recovery activities at each operating location.
Each location's procedures for data backup will include a schedule for
daily, weekly, and monthly backups. Each facility shall establish media
control procedures that include steps for the preparation of media for
reuse, or destruction. Additionally, each facility will prepare an
information backup plan that ensures information is saved according to
its priority for recovery.

##### Information Retention and Archive Backup

Backup media should be retained on-site for operational use until no
longer required. Backup media will be periodically reviewed, and if
appropriate, archived to comply with guidance from the National Archives
and Records Administration. The facility's IT manager shall review all
backup media to identify archival data. Archival data will be removed
for disposition and storage. Backup media, which is not scheduled for
archiving, will be prepared for reuse or destroyed if appropriate. IT
managers may forward their backup media to the program headquarters for
storage if space limitations preclude onsite storage.

##### Off-Site Storage of Backup Material 

Backup media will be stored at a suitable off-site location. For
locations where commercial off-site storage is not practicable, the
system owner or IT manager will designate an appropriate facility to
serve as the off-site storage of backup media. A suitable facility
(commercial or non-commercial) is one within reasonable distance, but
not likely to be immediately threatened by the contingency or disaster.

# DATA MANAGEMENT SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard collectively applies to all data assets that exist in
Interior processing environments. Other than public data, all data and
processing resources are only accessible on a need to know basis to
specifically identified, authenticated, and authorized entities. This
embodies the principle of least privilege, which specifies that
individuals only be granted permission for actions necessary to perform
their jobs.

Access control mechanisms shall be utilized to ensure that only
authorized users can access data to which they have been granted
explicit access rights.

Data shall be protected in all of its forms, on all media, during all
phases of its life cycle, from unauthorized or inappropriate access,
use, modification, disclosure, or destruction. Data is considered a
primary asset and shall be protected in a manner commensurate to its
value. Data security is necessary because data processing represents a
concentration of valuable assets in the form of information.

## Standard Detail

##### Data Security 

Interior data security and privacy shall focus on controlling
unauthorized access to information. Data security shall be derived from
three principles: confidentiality, integrity, and availability. These
three principles emphasize the need for security to function properly in
the Interior processing environment.

In the context of this standard, the following provides the overall
concepts and security principles for which all users are responsible. It
is the responsibility of the Bureau Chief Information Security Officer
(BCISO) to define the specific mechanisms necessary to support these
principles.

##### Accountability 

All network, system, and application events shall be attributable to a
specific and unique individual. A responsible individual must be
assigned to every event using an identification service. An
authentication service shall provide verification of this assignment and
an audit service will trace any event, reconstructing the time, place,
and circumstances surrounding it. In this context, identification refers
to a security service that recognizes a claim of identity by comparing a
UserID offered with stored security information.

##### Authorization 

All network, system, and application events shall only result from
allowable actions through access control mechanisms. Permission may be
derived directly from an individual\'s identity or from a job
classification or administrative privilege based on that individual\'s
identity.

Limiting actions to those properly authorized protects the
confidentiality and integrity of data within the Interior processing
environment. In this context, access control refers to a security
service that allows or denies a user request based on privilege, group
information, or context.

##### Availability  {#availability-2}

All permitted activity shall operate with reliability. Users must be
able to retrieve the correct data necessary to perform such events. All
activity results shall be completed unless the activity is totally
aborted. Activity results must not depend on unforeseen aspects of other
simultaneous events. The security services themselves shall be
documented and easily administered. In this context, reliability refers
to a security service that guarantees data has not been altered,
deleted, repeated, or rearranged during transmission, storage,
processing, or recovery.

##### Data Usage 

Each user shall ensure that Interior and Agency data assets under their
direction or control are properly labeled and safeguarded according to
their sensitivity, proprietary nature, and criticality.

Users of data assets are personally responsible for complying with all
Interior standards. All users will be held accountable for the accuracy,
integrity, and confidentiality of the information to which they have
access. Data shall only be used in a manner consistent with applicable
and relevant policies and standards.

##### Data Ownership

The owner of data is responsible for classifying their data in
accordance with Federal guidelines. If an owner cannot be determined for
a data asset, the Interior or BCISO shall act as its custodian. The
BCISO is responsible for developing, implementing, and maintaining
procedures for identifying all data assets and associated owners. The
owner of all customer data is the individual owner that generates or is
assigned ownership of that data.

##### Data Media Marking 

Marking of hard copy output and magnetic media must reflect the
sensitivity of the information. Appropriate markings must be applied,
i.e., For Official Use Only (FOUO), Sensitive But Unclassified (SBU), or
Sensitive Security Information (SSI). Refer to **Information
Classification Security Standard** or its replacement.

1.  Magnetic media must be marked as sensitive (SBU/SSI) unless it is
    determined to not contain sensitive information. Backup disks/tapes
    must be marked as FOUO.

2.  Graphic media, such as photographs, films, tapes, disks or slides
    must be marked "For Official Use Only" or "FOUO" in a manner that
    ensures that a recipient or viewer is aware of the status of the
    information therein.

3.  FOUO material transmitted outside the Interior requires application
    of an expanded marking to explain the significance of the FOUO
    marking.

4.  Permanently bound volumes need to be marked only on the outside of
    the front and back covers, title page, and first and last pages.
    Volumes stapled by office-type hand or electric staples are not
    considered permanently bound.

##### Data Protection 

External data (hard copy or magnetic media) shall be continually
protected at the same level that is afforded to it while using Interior
information systems. Data administrators should also refer to their
organization's local security standard operating procedures.
Additionally, administrators must ensure that no unauthorized imported
data, whether imported electronically or by diskette, is installed on
Interior resources.

Interior data will be resident on various media. This media will consist
of floppy diskettes, removable and non-removable hard disks, tapes,
CD-ROMs, DVD-ROMS, thumb drives, and other media. Interior operations
require all storage media to be marked according to the highest
sensitivity (i.e., FOUO) handled by the system. This **Data Management
Security Standard** includes master document copies, archives, and
backup files when they are removed for repair/exchange or simply
provided secure storage.

##### Data Sharing 

Data shall be shared between interconnected systems based on written
Interconnection Security Agreements (ISA) based on processes and
procedures defined in NIST SP 800-47, Security Guide for Interconnecting
Information Technology Systems, or its replacement.

##### Data Transmission 

Where necessary, data transmitted shall be secured via cryptographic
procedures. This may include the use of confidentiality, integrity, and
availability mechanisms.

##### Data Storage 

Data stored shall be secured via cryptographic mechanisms. This may
include the use of confidentiality, integrity, and availability
mechanisms.

##### Data Disposal 

The BCISO's shall develop and implement procedures to ensure the proper
disposal of various types of data. These procedures shall be made
available to all users with access to data that requires special
disposal techniques. The Interior processing environment is comprised of
program and system application data, computer systems, and network
resources. For additional information, see **Media Sanitization and
Disposal Security Standard** or its replacement.

##### Data Content 

This standard does not mandate or endorse particular data content.
Rather, the business decision process used to evaluate the inclusion or
exclusion of particular data content shall consider those items listed
below. Considerations for evaluating data content include:

1.  Legal and regulatory obligations in the locales in which the
    Interior operates.

2.  Confidentiality, availability, and integrity of data ensured to the
    satisfaction of customers and legal authorities.

3.  Content is in alignment with our business goals and objectives.

4.  Customer accessibility to specific data content on the basis of
    requirement and/or demand.

5.  Data Classification

Data classification is necessary to enable the allocation of resources
to the protection of data assets as well as determining the potential
loss or damage from the corruption, loss, or disclosure of data. The
BCISO is responsible for evaluating the data classification schema and
reconciling it with new data types as they enter usage.

#  

# FIREWALL MANAGEMENT SECURITY STANDARD 

## Mandatory Standard Guidelines 

This section will be revised in a subsequent release. The Network
Perimeter Security Standard remains in effect until this section is
promulgated.

# GOVERNMENT-OWNED COMPUTERS AND PED SECURITY STANDARD 

## Mandatory Standard Guidelines 

Government-owned computers and Portable Electronic Devices (PED) shall
be pre- configured with all necessary security measures in accordance
with NIST Guidance for the system to be accessed by Interior Federal
employees, contractors, subcontractors, or partners.

Government-owned computers and Government-owned Personal Electronic
Devices (PED) may be used to house Sensitive But Unclassified (SBU) and
Sensitive Security Information (SSI) data only when required for
official duties. This information shall be encrypted during storage to
protect against unauthorized disclosure. When a computer or PED is no
longer required for official business, the SBU/SSI data shall be removed
immediately.

For information on the use of Wireless Technology, refer to **Network
Access Security Standard** or its replacement.

## Standard Detail

#### Classification of Government-Owned Computers 

Government-owned computers are classified into two types. These are as
follows:

1.  Primary Workstation Computers -- These computers are generally
    assigned to just one user. They are often stand-alone systems or
    laptops that are plugged into a docking station or port replicator
    when at a fixed location. However, the laptops can be pulled out and
    used for travel or used at locations where disconnected from the
    network.

2.  Travel or Shared Computers -- These computers are seldom connected
    to the network for significant periods of time and may go for long
    periods of time without any connection to the network. They may be
    dedicated to a single user or shared by many users.

Despite these variances, all Government-owned computers must adhere to
the guidelines outlined in this security standard.

#### Government-Owned Computer Security 

##### Virus Protection and Software Patches 

Government-owned computers must be adequately protected by current
antivirus software and must be consistently configured to ensure
security against known vulnerabilities in operating systems and
application software. Refer to **Patch Management Security Standard**
and **Virus Protection Security Standard**, or their replacements, for
additional information.

##### 

##### Personal Usage 

The Off-site usage of Government-owned computers, whether the use is at
home or at other locations, is restricted to business purposes. However,
Interior authorizes limited personal use, provided the use involves
minimal expense to the Government and does not interfere with official
business. Refer to **Acceptable Use Security Standard**, or its
replacement, for additional details on personal use of Interior computer
equipment.

##### Physical and General Security Practices 

Computers are subject to all Interior security policies and procedures.
This includes, but is not limited to, virus protection, physical access,
passwords, screensavers, and data cleansing.

1.  Users shall be liable for damages incurred if found negligent of not
    properly following established security regulations in properly
    securing Government equipment in accordance with this standard.

2.  Thefts shall be reported immediately to local law enforcement and
    the Bureau Chief Information Security Officer (BCISO). The BCISO
    shall immediately suspend access privileges to prevent network
    hacking.

3.  Users will make sure that adequate precautions are exercised to
    ensure that computers are physically secure at all times. Security
    practices include, but are not limited to the following:

4.  Computers or laptops shall not be left unattended in public places.
    These typically include aircraft, airports, cars, hotels,
    restaurants, or non-Government office buildings.

5.  Computers or laptops shall not be used in public if sensitive data
    is displayed on the screen that may be viewed by others.

6.  Laptop users shall not announce to anyone that they have a
    Government-owned computer in their possession.

7.  Users are required to use laptop computer security locks (if
    provided) to protect Government equipment from theft. These locks
    shall be properly utilized to provide the utmost protection.

8.  Laptop computers that are not secured in a docking station shall be
    shut down and stored out of sight when a user is away from the
    office perimeter or meeting space.

9.  Laptops being used as a primary workstation shall be fastened to a
    desk using a locking device such as a docking station.

10. Users shall attempt to minimize the amount of time the laptop
    computer is out of their control to deter mix-ups or theft during
    security screening at airports, train stations, and Federal or
    non-Government office buildings.

11. Laptop computer users shall cushion the laptop, i.e., storing the
    computer in a computer carrying case, to prevent damage while in
    travel.

12. While on an aircraft, the laptop computer shall be stored in the
    best possible location, that being under the seat in front of the
    user, or in an overhead compartment that is visible from the user's
    seat.

13. Laptop computers and other mobile devices due to there mobility
    require additional security measures and personal responsibility due
    diligence. Laptop computers and mobile devices should be physically
    secured when possible if in other than a DOI or Bureau facility that
    is a controlled access area. Additional security measures are
    appropriate such as locking the meeting room, locking cable or in a
    hotel room safe. When traveling on commercial airlines or commercial
    vehicles the laptop of mobile device shall accompany the traveler as
    a hand carry item. If in a rental car the laptop or mobile device
    must be stored in such a fashion that it is completely hidden from
    view in the car trunk upon leaving the car unattended.

14. Users must never leave their laptop computer and other mobile
    devices in open view in a parked car. Every effort should be made to
    conceal them from sight to include storing the devices under the
    seat or in the locked trunk of the car.

15. Personal accountability and due diligence to avoid practices that
    could inadvertently damage mobile computing resources; users should
    avoid eating, drinking, or smoking within a close proximity to the
    mobile computing resource.

16. An ID label or return-to-owner notice should be attached to the
    underside of a laptop computer using only the official Interior
    business address.

17. If a non-Government, third-party ISP network is utilized (outside of
    Federal facilities), then the following must be enabled to protect
    the computer and its contents:

    a.  Personal firewall enabled and properly configured

    b.  Antivirus definitions will be updated

    c.  Encrypted VPN (non-split tunneled) must be used to provide
        secure access to Interior network resources

##### Government-Owned Portable Electronic Devices (PED) 

A Portable Electronic Devices (PED) is any electronic device that is
capable of receiving, storing, or transmitting information and does not
require a permanent link to Federal networks. Handheld devices such as
Personal Digital Assistants (PDA) permit users to synchronize databases
using either hardwired or wireless means and provides access to network
services such as e-mail, Web browsing, and Internet access. PEDs
include, but are not limited to, cellular phones including picture and
movie-enabled phones, pagers, text messaging devices, and wireless
e-mail devices such as Blackberries, hand-held scanners, PDAs (i.e.,
Palm or Windows Mobile Devices), voice recorders, and flash memory.

For use of Wireless Technology refer to the Network Access Security
Standard or its replacement.

##### Virus Protection and Software Patches 

Government-owned PEDs must be adequately protected by current antivirus
software and must be consistently configured to ensure security against
known vulnerabilities in operating systems and application software.
Refer to **Patch Management Security Standard**, and **Virus Protection
Security Standard**, or their replacement, for additional information.

#### Personal Usage 

The Off-site usage of Government-owned PEDs, whether the use is at home
or at other locations, is restricted to business purposes only. However,
Interior authorizes limited personal use provided the use involves
minimal expense to the Government and does not interfere with official
business. Refer to **Acceptable Use Security Standard**, or its
replacement, for additional details on personal use of Interior
computers.

Use of Non-Government owned Portable Electronic Devices (PED) is
prohibited in the Interior information resource environment.

##### Access Control 

Refer to **Authorization and Access Control Security Standard**, or its
replacement, for additional details on access control for Interior
computers.

##### Physical and General Security Practices 

1.  All PEDs, flash memory devices, and wireless devices will be
    provided by the Government unless approved, and documented by the
    BCISO.

2.  PEDs are subject to all Interior security policies and procedures.
    This includes, but is not limited to, virus protection, physical
    access, passwords, screensavers, and data cleansing.

3.  Security for PEDs will be coordinated and managed by the BCISO.

4.  PEDs shall be screened by the BCISO, or designated representative,
    at least quarterly for appropriate configurations, viruses,
    antivirus protection, and patch level will be updated, as required.

5.  Thefts shall be reported immediately to local law enforcement and
    the BCISO. The BCISO shall immediately suspend access privileges to
    prevent network hacking.

6.  The BCISO retains the right to delete or purge data on a PED in
    cases of suspected compromise.

7.  Unless a property transfer has been authorized, PEDs will be
    surrendered to the user's supervisor or manager immediately upon
    transfer, reassignment, resignation, or retirement from Federal
    service.

8.  Users shall be liable for damages incurred if found negligent of not
    properly following established security regulations in properly
    securing Government equipment in accordance to this standard.

9.  Standardized configurations will be established for all PEDs to
    include operating system software, firmware, and authorized
    applications.

10. Encryption techniques, including digital
    certificates/PKI/Biometrics, that conform to Interior and NIST
    requirements, shall be used for Infrared and wireless transmissions,
    and for data storage on PEDs.

11. Users will make sure that adequate security precautions are
    exercised to ensure that flash memory used in laptops or PEDs is
    protected.

12. Strict physical security standards for PEDs shall be implemented to
    include requirements to hand carry PEDs during travel, powering off
    devices not in use, tracking and tagging of PEDs, and contact
    information in case device is lost or stolen.

13. PED modems will remain disabled at all times.

14. Where applicable, Virtual Private Network (VPN) technology is
    required for the use of PEDs and split tunneling profiles will be
    disabled.

15. Modifications will not be made in official system configurations,
    operating systems, antivirus software, or remote access arrangements
    except those made by the BCISO or designated representative.

16. In absence of electronic verification or auditing, physical
    inventories of PEDs will be performed on an annual basis. During the
    inventory, storage of information will be checked to confirm that
    only required information is maintained and that Sensitive But
    Unclassified (SBU) data is encrypted.

17. PEDs will be kept patched and updated according to bureau,
    departmental, or manufacturer guidelines. PEDs will be returned to
    the responsible Information Technology or IT Security office as
    requested for system updates or accountability reasons.

18. Encryption techniques will be used for infrared and wireless
    transmissions of Sensitive But Unclassified (SBU) information or for
    storage of SBU data.

19. Unauthorized software and unauthorized copyrighted or illegal
    material will not be loaded or stored on PEDs.

20. Users shall exercise caution in discussions of sensitive information
    using wireless technology to prevent inadvertent disclosure of SBU
    information use or violations of the Privacy Act.

21. Floppy disks, CD-ROMs, and Flash Memory will not be used to download
    SBU information or data unless that data is protected by
    cryptographic measures.

22. Government-owned PEDS may not be synchronized to personally owned
    computers.

23. Personally owned PEDS shall not be synchronized to Government-owned
    computers.

# INFORMATION CLASSIFICATION SECURITY STANDARD

## Mandatory Standard Guidelines 

This standard establishes the requirement for the classification,
protection, and management of sensitive data stored and processed on
information systems supporting the Interior.

Sensitive But Unclassified (SBU) information shall be properly handled,
stored and protected from the risk and magnitude of loss or harm that
could result from inadvertent or deliberate disclosure, alteration or
destruction. SBU information also includes Sensitive Security
Information (SSI). However the SBU category contains information that is
not security related but is still sensitive in terms of its risk of
exposure.

For Official Use Only (FOUO) identifies information that is exempt from
mandatory release under the provision of the Freedom of Information Act
(FOIA). For Official Use Only (FOUO) is a document designation, not a
classification. This designation is used to identify information or
material which, although unclassified, may not be appropriate for public
release.

## Standard Detail

##### Sensitive But Unclassified (SBU) Information Protection

Sensitive But Unclassified (SBU) information shall be properly handled,
stored and protected from the risk and magnitude of loss or harm that
could result from inadvertent or deliberate disclosure, alteration or
destruction. SBU information also includes Sensitive Security
Information (SSI). However the SBU category contains information that is
not security related but is still sensitive in terms of its risk of
exposure.

All Interior offices will analyze their information to determine
appropriate levels of concern for their data in accordance with OMB
A-130 and NIST Special Publication 800-37.

SBU/SSI information with a high level of concern should not be discussed
or transmitted via telephones, pagers, cell phones, fax, or other
wireless devices as these are not secure and the risk of interception of
the transmission is great. The use of other than secure telephonic
devices to discuss SBU/SSI information shall only be permitted where the
degree of risk is understood and accepted.

1.  Bureaus shall analyze all information available or to be published
    on public Web pages to ensure that SBU/SSI information is not made
    available except on a need-to-know basis.

2.  SBU/SSI shall be processed and stored only on systems that meet
    Cyber Security guidance requirements for controlled access
    protection.

3.  Bureaus shall shred SBU/SSI documents of high-level concern in lieu
    of disposal in trash to prevent unauthorized disclosure.

4.  Government-owned mobile systems, laptops, and Personal Electronic
    Devices (PED) may be used to house SBU/SSI data only when required
    for official duties. This information shall be encrypted during
    storage to protect against unauthorized disclosure. When a mobile
    system or PED is no longer required for official business, the
    SBU/SSI data shall be removed with software to overwrite the
    sensitive information in accordance with Interior regulations.

5.  Care shall be taken by Bureaus to avoid leaving SBU/SSI information
    readily available at workstations or on personal computer screens.
    SBU/SSI data with a high level of concern will be stored on a floppy
    disk or zip drive in a locking desk drawer, file cabinet, or locked
    office. SBU/SSI information should be printed on laserjet printers
    (if available).

6.  Access to SBU/SSI will be provided to employees and contractors with
    a need-to-know basis. When SBU/SSI data must be shared with
    contractors and entities outside of the Interior, a Non-Disclosure
    Agreement form shall be executed by the system owner or Bureau Chief
    Information Security Officer (BCISO) prior to granting access to the
    data in order to preclude possible organizational or personal
    conflicts.

7.  All Statements of Work (SOW) shall be marked in a conspicuous manner
    with the following notice: "Sensitive But Unclassified/Sensitive
    Security Information -- Disseminate on a Need-To-Know Basis Only" in
    accordance with Interior regulations. Electronic messages shall be
    marked with this notice as well.

8.  All FOIA requests for SBU/SSI will be processed in accordance with
    Interior regulations and the Attorney General's memorandum.

##### For Official Use Only (FOUO) Information Protection 

For Official Use Only (FOUO) is a document designation that is used to
identify information or material which, although unclassified, may not
be appropriate for public release. There is no national standard
governing use of the FOUO designation. FOUO information is unclassified
sensitive information that is or may be exempt from public release under
the FOIA.

The Interior shall define what information shall be protected as FOUO
and how this protected information shall be handled. FOUO information
may be disseminated as necessary in the conduct of official business.
FOUO information may also be released to officials in other departments
and agencies in performance of a valid government function.

Unclassified documents and material containing FOUO information shall be
marked as follows:

1.  Documents will be marked FOR OFFICIAL USE ONLY at the bottom of the
    front cover (if available), the title page (if available), the first
    page, and the outside of the back cover (if available).

2.  Pages of the document that contain FOUO information shall be marked
    FOR OFFICIAL USE ONLY at the bottom.

3.  Each paragraph containing FOUO information shall be marked with the
    abbreviation FOUO in parentheses at the beginning of the FOUO
    portion.

4.  Material other than paper documents (i.e., slides, computer media,
    films, etc.) shall bear markings which alert the holder or viewer
    that the material contains FOUO information.

FOUO information shall be safeguarded as follows:

1.  FOUO information should be handled in a manner that provides
    reasonable assurance that unauthorized persons do not gain access.

2.  During working hours, reasonable steps should be taken to minimize
    risk of access by unauthorized personnel. After working hours, FOUO
    may be stored as a minimum in a locked desk, file cabinet, bookcase,
    locked room, or similar place.

3.  FOUO documents and material may be transmitted via first class mail,
    parcel post, or, for bulk shipments, via fourth class mail.

4.  Fax or e-mail transmission of FOUO information (voice, data, or
    facsimile) should be made via encrypted communications systems
    whenever practical. FOUO information may be put on an Internet web
    site only if access to the site is limited to a specific target
    audience and the information is encrypted.

5.  FOUO documents may be destroyed by shredding or tearing into pieces
    and discarding the pieces in a regular trash container unless
    circumstances recommend a need for more careful protection.

6.  All Interior offices, employees, and contractors will identify and
    provide adequate security protection for all SBU/SSI information.
    This information will be encrypted when electronically transmitted
    to prevent unauthorized disclosure of sensitive information to
    users.

7.  Each bureau will provide a report on an annual basis that identifies
    all SBU information.

##### Encryption Plan 

In accordance with the Office of Management and Budget Guidance on Data
Availability and Encryption, each implementation shall include an
encryption plan. Required components in the Interior encryption plan
include:

1.  A configuration layout showing complete end-to-end details of the
    telecommunication or computer systems encryption points.

2.  The type of encryption to be used.

3.  The source of key generation and insertion for symmetrical
    encryption methods.

4.  The cryptographic period required, that is, the amount of time
    before a session key should be updated.

5.  The system procedures for key loading, key generation, key
    protection and distribution, key recovery, and key destruction.

6.  Each bureau shall have key recovery procedures to recover encrypted
    sensitive information when the data is stored electronically.

##### Encryption Standard 

Interior offices shall implement encryption algorithms that are endorsed
by NIST and the U.S. Department of the Interior on those computing
systems that process and store sensitive information. These requirements
include internal and external information systems that process and store
sensitive information within the Interior infrastructure and by other
parties on behalf of Bureaus.

1.  Any bureau that cannot implement the requirements of the standard
    shall require an approval for system operation by the Interior CIO
    and CISO. IATO's will be considered for implementation timeframes
    only. However, all SBU/SSI information shall be encrypted -- no
    exceptions will be considered for this requirement.

2.  All Interior telecommunication and network encryption systems shall
    have an encryption plan approved by the Interior BCISO.

3.  Sufficient redundancy and capacity needs to be incorporated into
    departmental or Interior mission critical and essential
    communication systems to prevent transmission of SBU/SSI information
    in clear text.

4.  SBU/SSI will be processed and stored as per Interior Cyber Security
    guidance on C2-like Controlled Access Protection.

5.  All Bureaus and offices shall exercise control over all keys
    utilized in encrypted transmissions.

6.  All encrypted protocols shall deploy either the Triple Data
    Encryption Algorithm (TDEA), also known as Triple DES or the
    Advanced Encryption Standard approved by NIST. Encryption products
    used to protect sensitive information shall conform to the NIST
    Cryptographic Module Validation Program validated listing. All
    encryption implementations will conform to the Level 2 Security
    requirements as specified in FIPS 140-2 unless otherwise identified
    in this standard.

7.  Secure Shell (SSH) may be deployed solely for the remote
    administration of sensitive systems.

8.  The TLS specification may be deployed to provide secured access to
    sensitive information on Web servers. When TLS is used to protect
    Interior sensitive information, the latest version shall be used.

9.  Virtual Private Networks (VPN) shall be deployed in environments
    where data-link layer encryption would not be a practical solution
    to maintain and operate. VPN technology using IPSEC encryption
    allows it to be implemented independent from a particular link layer
    communications technology (i.e., HDLC, Frame Relay, FDDI, Ethernet,
    Gigabit Ethernet, ATM, etc.). As such, this standard strongly
    encourages the use of VPN technology to secure departmental and
    Interior sensitive communications.

10. Data-Link (symmetrical) Encryption shall be used in environments
    where VPN management would not be a reasonable and/or warranted.

11. In addition to these requirements, information from Privacy Act
    systems of records will be handled according to DOI Privacy Act
    regulations 43 CFR 2.45 -- 2.79 and the appropriate system of
    records notice.

12. Pretty Good Privacy (PGP) may be used to protect sensitive
    information transmitted via e-mail using a minimum key size of 2048.
    Public key information may be maintained on public or internal PGP
    key servers.

13. Public Key Infrastructure (PKI) implementations are suitable for all
    environments and shall follow Cyber Security's Interim Guidance on
    the Use of Public Key Infrastructure (PKI) Technology in the
    Interior, CS-008.

# INTRUSION DETECTION MANAGEMENT SECURITY STANDARD

## Mandatory Standard Guidelines 

This standard establishes the requirement for the use of Intrusion
Detection Systems (IDS) on information resource supporting the Interior
Office of the Chief Information Officer (Interior). The Change Control
Board (CCB) shall give written approval to the configuration of the IDS
prior to any activity. All sensor-to-console communications shall be
encrypted to prevent interception or changes being made.

The Interior shall use intrusion detection sensors to monitor all
network traffic at major gateways. The scope of intrusion detection
shall be expanded to include new equipment or subnets as they are added
to the primary network. Electronic updates to intrusion detection
signature files shall be received and applied in an automated fashion as
to ensure the IDS system can be kept current with the latest attack
signatures. All updates must be tested prior to updating the production
system.

IDS Administrators and Bureau Chief Information Security Officers
(BCISOs) shall report any security breach, successful attack, or
violation of this standard to the DOI-CIRC.

## Standard Detail

##### IDS Access 

1.  Access to IDS management consoles, operating systems, sub-systems,
    and signature files shall be limited to IDS Administrator personnel.
    For security reasons, no exceptions to this rule shall be permitted.
    All IDS user credentials shall comply with ***[Authorization and
    Access Control Security Standard]{.underline}*** or its replacement.

2.  Administrator accounts are any accounts with read/write access to
    the IDS configuration. These accounts shall be user specific and
    access shall only be permitted from workstations intended for this
    function. This type of account shall only be issued to IDS
    Administrators.

3.  The administrator account is the original administrative account of
    the IDS. This account shall be renamed where possible and will be
    used on a limited need-to-know basis. Only IDS administrative
    personnel are permitted to have knowledge of this type of password
    and shall comply with **Authorization and Access Control Security
    Standard** or its replacement.

##### IDS Configuration Standards 

1.  IDS documentation, specifically all configuration standards used to
    control usability, efficiency, and security of the overall IDS
    environment, shall be maintained and secured from non-secured
    resources.

2.  This documentation shall be strictly adhered to when designing,
    implementing, or managing IDS configurations.

##### 

##### 

##### IDS Physical Security 

All IDS systems and sensors shall be physically secured in accordance
with Physical Access Security Standard or its replacement.

##### IDS Logs 

1.  The IDS Administrator shall monitor and view IDS log files on a
    daily basis using the IDS central console. The IDS Administrator
    shall submit a monthly report to the Agency BCISO detailing the
    month's activities.

2.  All IDS logs are to be written to drives external to the IDS. IDS
    logs shall be managed in a manner that maintains their integrity and
    authenticity. These logs are to be stored or archived for a minimum
    of six months.

3.  Request for access to IDS logs shall be made directly to the IDS
    Administrators with final approval to be determined by the security
    staff in the event that the Information Security Staff and the IDS
    Administrator are synonymous.

4.  In the event of increased activity, monitoring and reporting
    activity shall be adjusted as needed.

##### IDS Implementation 

A request for implementation of new IDS system and sensor
implementations shall be submitted to the CCB. This request shall
include all configuration and standard settings along with other system
information. After obtaining CCB and BCISO approval, authorized
personnel can proceed with the IDS implementation. Any changes from the
original design made during the installation will need to be submitted
via a change request.

##### Change Request 

Change requests for any modifications to the IDS system, configuration,
sensors, or rules shall be submitted in writing to the CCB for review.
All change requests shall include the reason and timeframe for the
request as well as all risks, threats, and known issues associated with
this change. Following approval by CCB, IDS Administrators may proceed
with the IDS changes.

# MEDIA SANITIZATION and DISPOSAL SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes the requirement for the secure and appropriate
disposal of Information Technology (IT) equipment, devices, network
components, operating systems, application software, and storage media
belonging to the Interior to prevent unauthorized use or misuse of
Federal Government information. All IT equipment shall be properly
sanitized prior to disposal or release, and sanitization procedures
shall be properly documented to prevent unauthorized release of
sensitive and/or confidential information that may be stored on that
equipment and other electronic media according to NIST SP 800-88
"Guidelines for Media Sanitization" & in Appendix E.

## Standard Detail

##### Sanitization of IT Equipment and Electronic Media

The sale, transfer, or disposal of computers, computer peripherals, and
computer software or other Interior devices may create information
security risks including potential violations of software license
agreements and the unauthorized release of sensitive information. Due to
these risks, all Interior computers containing sensitive data shall have
their hard drives securely erased.

##### Sanitization of Hard Drives 

Sanitization must be performed on hard drives to ensure all information
is removed in a manner that gives assurance that the information cannot
be recovered. Three acceptable methods to be used for the sanitization
of hard drives include:

1.  Overwriting

2.  Degaussing

3.  Physical Destruction

##### Sanitization methods shall depend upon the operability of the hard drive: 

Operable hard drives that will be reused must be overwritten prior to
disposition. If operable hard drives are to be removed from service
completely, they must be physically destroyed or degaussed.

Hard drives that are inoperable or those that have reached the end of
their useful life must be physically destroyed or degaussed.

Clearing data (deleting files) is not an acceptable method of sanitizing
Interior hard disk storage media as this process does not prevent data
from being recovered by technical means.

##### Overwriting Specifications 

Overwriting is the approved sanitization method for Interior hard disk
drives as it effectively renders data unrecoverable. The entire hard
disk shall be overwritten with a repetitive group of characters. Writing
repetitive characters over the surface of the disk will destroy data
previously left on the hard disk.

All software products and applications used for the overwriting process
must be able to overwrite the entire hard drive, independent of any BIOS
or firmware capacity limitation that the system may have, making it
impossible to recover any meaningful data. When extremely sensitive
information is present on a hard drive, the overwrite procedure must be
completed at a minimum of seven times. After sanitizing a hard disk, the
bureau / office will attach a statement to the unit certifying that it
was sanitized.

##### Degaussing Specifications 

Degaussing is a process used to erase magnetic media on hard drives,
rendering them useless. The degaussing method shall only be used when
the hard drive is inoperable and will not be used for further service.
However, as the use of a degausser does not guarantee that all data on
the hard drive will be destroyed; degaussing efforts should be audited
periodically to detect equipment or procedure failures.

##### Physical Destruction 

Hard drives must be destroyed when they are defective or cannot be
repaired or sanitized for reuse. Physical destruction must be
accomplished to an extent that precludes any possible further use of the
hard drive.

##### Sanitization of Other Computer Media 

Risks for the potential disclosure of sensitive data on media other than
computer hard drives shall be sanitized accordingly. Particular
attention shall be paid to floppy disks, tapes, CD-ROMs, DVD-ROMs, and
optical disks. Unlike magnetic media sanitization, clearing is an
acceptable method of sanitizing memory components before release.

Memory components are categorized as either volatile or nonvolatile.
Volatile memory components do not retain data after removal of all
electrical power sources, i.e. Static Random Access Memory (SRAM) and
Dynamic Random Access Memory (DRAM). Nonvolatile memory components do
retain data when all power sources are discontinued. These memory
components include Read Only Memory (ROM), Programmable ROM (PROM), or
Erasable PROM (EPROM) and their variants.

Memory components that have been programmed at the vendor\'s commercial
manufacturing facility and are considered unalterable in the field may
be released.

##### Disposal of Interior Equipment 

Following the proper sanitization of Interior computer equipment, these
components may be disposed of in the appropriate format listed below:

1.  Donation to educational institutions and educational nonprofit
    organizations under authority of Public Law (PL) 102-245 may be used
    with any quantity of units.

2.  Regular excess procedures if the quantity of units is ten or less.

3.  Exchange sale through GSA may be used for large accumulations of
    equipment.

4.  If the location quantity is three or less units, donation to public
    bodies (i.e., Federal Agencies, public libraries, Indian Tribes) is
    authorized.

# NETWORK ACCESS SECURITY STANDARD

## Mandatory Standard Guidelines 

This standard establishes requirements for the secure access and
transmission of data on all Interior Office of the Chief Information
Officer (Interior) networks to prevent unauthorized use or misuse of
Federal Government information. The following guidelines shall be
followed:

1.  All servers, network devices, or appliances hosting information or
    resources accessed from the Internet shall be placed in a
    Demilitarized Zone (DMZ) network segment which is separated from the
    Internet and separated from the Interior network by a firewall.

2.  All Internet Service Providers (ISP) shall be approved by the Change
    Control Board (CCB) prior to installation.

3.  Firewalls and Intrusion Detection Systems (IDS) and router-based
    Access Control Lists (ACL) shall be used to control, restrict, and
    monitor all network traffic to and from the Interior networks.

4.  All network traffic between Interior locations shall be transported
    on dedicated Interior owned circuits or through a Virtual Private
    Network (VPN) connection meeting encryption levels set by Interior
    Security Policies.

5.  No Interior-owned computers at Interior offices shall have Internet
    connectivity other than the connectivity provided by the Interior.

## Standard Detail

#### Warning Banners 

The following Warning Banner will appear prior to system/network logon
in order to provide fair notice on proper use to those attempting to
access Interior systems and networks. The following warning message
provides the minimum wording to be included in a warning banner. The
Interior Office of the Solicitor and the Department of Justice (DOJ)
Computer Crimes and Intellectual Properties Section have approved the
wording. It is adapted from guidance provided by the National Institute
of Standards and Technology (NIST), and meets the minimum requirement
for warning banners as required in General Support System or Major
Application system security plans.

NON -- TRUST SYSTEMS

+-----------------------------------------------------------------------+
| TITLE: WARNING TO USERS OF THIS SYSTEM                                |
+-----------------------------------------------------------------------+
| This computer system, including all related equipment, networks, and  |
| network devices (including Internet access), is provided by the       |
| Department of the Interior (DOI) in accordance with the agency policy |
| for official use and limited personal use.                            |
|                                                                       |
| All agency computer systems may be monitored for all lawful purposes, |
| including but not limited to, ensuring that use is authorized, for    |
| management of the system, to facilitate protection against            |
| unauthorized access, and to verify security procedures, survivability |
| and operational security. Any information on this computer system may |
| be examined, recorded, copied and used for authorized purposes at any |
| time.                                                                 |
|                                                                       |
| All information, including personal information, placed or sent over  |
| this system may be monitored, and users of this system are reminded   |
| that such monitoring does occur. Therefore, there should be no        |
| expectation of privacy with respect to use of this system.            |
|                                                                       |
| By logging into this agency computer system, you acknowledge and      |
| consent to the monitoring of this system. Evidence of your use,       |
| authorized or unauthorized, collected during monitoring may be used   |
| for civil, criminal, administrative, or other adverse action.         |
| Unauthorized or illegal use may subject you to prosecution.           |
+-----------------------------------------------------------------------+

TRUST SYSTEMS

+-----------------------------------------------------------------------+
| TITLE: WARNING TO USERS OF THIS SYSTEM                                |
+-----------------------------------------------------------------------+
| This computer system, including all related equipment, networks, and  |
| network devices, is provided by the Department of the Interior (DOI)  |
| in accordance with the agency policy for official use and limited     |
| personal use. This system may not be connected to the Internet, in    |
| any way, unless specifically authorized by the Office of the          |
| Secretary.                                                            |
|                                                                       |
| All agency computer systems may be monitored for all lawful purposes, |
| including but not limited to, ensuring that use is authorized, for    |
| management of the system, to facilitate protection against            |
| unauthorized access, and to verify security procedures, survivability |
| and operational security. Any information on this computer system may |
| be examined, recorded, copied and used for authorized purposes at any |
| time.                                                                 |
|                                                                       |
| All information, including personal information, placed or sent over  |
| this system may be monitored, and users of this system are reminded   |
| that such monitoring does occur. Therefore, there should be no        |
| expectation of privacy with respect to use of this system.            |
|                                                                       |
| By logging into this agency computer system, you acknowledge and      |
| consent to the monitoring of this system. Evidence of your use,       |
| authorized or unauthorized, collected during monitoring may be used   |
| for civil, criminal, administrative, or other adverse action.         |
| Unauthorized or illegal use may subject you to prosecution.           |
+-----------------------------------------------------------------------+

##### Remote Access 

1.  Client side or personal firewalls shall be installed and configured
    on each computer used to remotely access Interior networks or
    applications.

2.  Government-owned computer equipment, software, and communications
    are required for remote connection to an Interior network or
    computer system.

3.  Remote access privileges to any Interior modem pool shall follow
    existing Interior remote access and approval

4.  The Bureau Chief Information Security Officer (BCISO) shall control
    and monitor remote access usage by individual users.

5.  Government-owned laptops must be adequately protected by current
    antivirus software and must be consistently configured to ensure
    security against known vulnerabilities in operating systems and
    application software. Refer to **Patch Management Security
    Standard**, and **Virus Protection Security Standard**, or their
    replacements, for additional information.

6.  All remote access connections shall comply with **Authorization and
    Access Control Security Standard** or its replacement.

7.  All remote servers, workstations, laptops, and Portable Electronic
    Devices (PED) shall be equipped with antivirus software that is kept
    current with the latest virus signatures.

8.  Reconfiguration of equipment used for remote access into the
    Interior network is not permitted for any reason or purpose.

9.  All security incidents or violation of this standard shall be
    reported in accordance with Incident Identification, Declaration,
    Reporting, and Handling Security Standard or its replacement.

10. Unless Active Directory credentials are used passwords used for
    dial-up authentication shall be changed at a minimum of every 30
    days

##### Dial-Up Access 

1.  Circuits used by Interior telecommunications personnel for direct
    connectivity and/or emergency purposes are permitted. The
    telecommunications staff shall maintain a listing of
    telecommunication lines, their location, and purpose. Updated
    listings shall be provided to the Bureau Chief Information Security
    Officer (BCISO) as changes are made. Access to use these emergency
    lines shall be tightly controlled.

2.  Routers for dedicated ISDN lines configured for access to the
    Interior network shall meet minimum authentication requirements of
    Challenge-Handshake Authentication Protocol (CHAP).

3.  All installations and use of modems or dial-up solutions shall first
    obtain written approval from the BCISO.

4.  Passwords used for dial-up authentication shall be changed at a
    minimum of every 60 days.

##### Internet Access 

1.  All network connections established with internal, restricted, or
    private Interior networks from the Internet shall be protected by a
    Virtual Private Network (VPN).

2.  All VPN solutions shall use encryption and authentication schemes
    that comply with the Interior Security Standard Manual or its
    replacement.

3.  A list of currently used ports shall be maintained and kept current
    by the network administrator.

4.  Only those protocols and ports required to perform remote functions
    are to be permitted by the firewall.

5.  Distributed file sharing (i.e., Windows SMB file shares, SAMBA file
    shares, Network File Systems) shall only be used by remote
    users/sites when connected through secured access, i.e., VPN access,
    authenticated dial-up connection, dedicated secure line, etc.

6.  BCISOs shall periodically scan remotely connected systems for
    security vulnerabilities.

##### 

##### 

##### Other Interior or Partner Connections 

1.  Connections between third-parties that require access to non-public
    Interior resources fall under this standard section, regardless of
    whether a Telco circuit (such as frame relay or ISDN) or VPN
    technology is used for the connection.

2.  All new extranet connectivity shall go through a security review
    with the BCISO. These reviews shall ensure that all access matches
    the business requirements in the best possible method, and that the
    principle of least access is followed.

3.  Sponsoring organizations that wish to establish connectivity to a
    third-party shall file a new site request with the
    telecommunications group. The telecommunications group shall engage
    the security office to address security issues inherent in the
    project. The sponsoring organization shall provide full and complete
    information as to the nature of the proposed access to the
    telecommunications group and the security office, as requested.

4.  All connectivity established shall be based on the principle of
    least access in accordance with the approved business requirements
    and security review. In no case shall the Interior rely upon the
    third-party to protect networks or resources.

5.  All changes in access shall be accompanied by a valid business
    justification and are subject to a security review. The sponsoring
    organization is responsible for notifying the telecommunications
    group and/or the security office when there is a significant
    material change to their previously provided information so that
    security and connectivity evolve accordingly.

6.  When access is no longer required, the sponsoring organization shall
    notify the telecommunications group responsible for that
    connectivity, which shall then terminate the access. This may mean a
    modification of existing permissions up to terminating the circuit,
    as appropriate.

7.  The telecommunications group shall conduct an audit of the
    respective extranet connections on an annual basis to ensure that
    all existing connections are still needed and that the access
    provided meets the needs of the connection. Connections that are no
    longer being used to conduct business shall be terminated
    immediately.

##### Remote Control 

All remote control programs that permit a user to manage another
computer over a network connection shall comply with the following
principles:

1.  The BCISO shall provide guidance on the implementation the security
    features in your selected software package.

2.  All remote control hosts shall require a username and password to
    establish a connection. Anonymous access is prohibited.

3.  Remote control software shall retain log files and audit trails
    showing all access and failed access.

##### Telework 

Telework, also known as telecommuting, flexiwork, and flexiplace, is not
considered an employee right. Supervisors and/or the applicable BCISO
can suspend or terminate an individual's privilege to participate in the
Telework program at any time. Accordingly, the appropriate disciplinary
actions shall be taken against the individual.

1.  An employee who participates in the Telework program on a regular
    and recurring basis shall certify in writing the security level of
    the official information used outside the primary work-site and the
    protection of Government-owned equipment and property.

2.  Only Government-owned equipment, software, and materials shall be
    used for Telework duties.

3.  Government-owned equipment shall only be used for official duties.
    Only approved/authorized Telework users are authorized to use
    Government-furnished equipment (e.g, the Government-furnished
    equipment assigned to a Teleworker is for their exclusive use and
    other family members and friends must not be allowed access or
    permitted to use any such equipment).

4.  The employee shall return all Government-owned equipment, software,
    and materials at the conclusion of the Telework arrangement or at
    the request of the Interior.

5.  The Government retains the right to inspect the home or alternate
    work-site and the equipment used by an employee to ensure that
    proposed work-sites are safe and that all equipment is adequately
    installed, maintained, and secured.

##### Privacy Act, Sensitive or Classified Data 

1.  Decisions regarding the proper use and handling of sensitive data,
    as well as records subject to the Privacy Act, are delegated to
    individual supervisors who permit employees to work at home.

2.  Care shall be taken to ensure those records subject to the Privacy
    Act and sensitive data are not disclosed to anyone except to those
    who are authorized access to such information in order to perform
    their duties. Organizations allowing employees to access records
    subject to the Privacy Act from a remote work site shall maintain
    appropriate administrative, technical, and physical safeguards to
    ensure the security and confidentiality of the records.

3.  Due to the sensitive nature of payroll and personnel databases,
    applications not normally accessible using public web browsers,
    shall not be accessible to Telework users.

##### Data Access for Telework Users 

1.  All sensitive data shall be encrypted when stored on any remote
    and/or portable device and/or transmitted. Encryption software shall
    be loaded on Government-owned equipment for all Telework users.

2.  Users shall be trained to use the software package provided.

3.  Correspondence files and historical records are likely to be
    one-of-a-kind and may not be taken from the primary work-site. Since
    these records exist mainly in hard copy, they are inaccessible via
    electronic means. Scanners and imaging systems (copiers) may be used
    to reproduce records for use off-site if needed.

##### Computer Security Requirements 

1.  Only hardware/software configuration procured by the Federal
    Government and authorized by the Interior shall be installed at the
    Telework location. Only under documented and authorized
    circumstances shall the BCISO allow Users to add
    non-Government-owned or unauthorized hardware or software to the
    home workstation if Government-owned

2.  Government-owned computers utilized in support of the Telework
    program shall be loaded with the latest version of the common
    computing core load, applicable remote access software and a data
    encryption package, if required. Telework supervisors shall notify
    the information technology staff of any additional software
    requirements of the participant.

3.  Remote telecommunication access to Government computers presents
    special security concerns. A combination of physical controls,
    unique user identifiers, passwords, terminal identifiers, access
    control software, and strict adherence to security procedures is
    required to protect the information from unauthorized access.

4.  Telework users shall comply with security procedures to protect
    Government information stored on magnetic media of workplace
    computers when the computers are repaired or serviced. Where the
    hard disk of a computer is inoperable, arrangements shall be made to
    remove sensitive information from the hard disk prior to having the
    computer serviced in accordance with Media Sanitization and Disposal
    Security Standard or its replacement.

##### Help Desk Support 

1.  Telework users shall be provided the same type and availability of
    help desk service that would be available to them in the traditional
    work-site.

2.  Due to the limited nature of face-to-face troubleshooting, employees
    must be prepared to assist the help desk staff remotely. For
    example, employees shall be willing and capable of following
    detailed systematic instructions over the telephone to assist the
    help desk staff in troubleshooting and resolving issues.

3.  Situations that cannot be resolved remotely may require that the
    participant transport the equipment to the primary work-site for
    further evaluation.

##### Wireless Technology 

Wireless technology is a new telecommunications media that is being
explored. However, due to inherent security risks associated with
wireless technology, joint risk acceptance (departmental and
bureau/office) is required of any approved wireless deployments as these
technologies effectively create a potential backdoor into Interior's
network potentially bypassing and/or circumventing the network perimeter
security controls otherwise afforded by the Department's Enterprise
Services Network (ESN). The potential risks are not only to the
implementing bureau and/or office, but potentially to the entire
enterprise (including potentially affecting other bureaus/offices and
exposing them to additional risk as well).

Usage of a Home, Conference, or Hotel wireless is allowed when
authorized with risk acceptance of the appropriate DAA, and the usage of
required VPN or other approved encrypted access mechanism.

# NON-GOVERNMENT OWNED COMPUTER AND PED SECURITY STANDARD

## Mandatory Standard Guidelines 

1.  All non-Government issued computers shall be inspected and scanned
    by Interior Bureau Chief Information Security Officers (BCISO) or
    designated representative prior to connecting to any Interior
    network or computer resource. The inspection shall include scans and
    system checks to ensure all devices are safe and meet Interior
    standards. If the device is found to be safe, an authorization shall
    be given for that device. Non-Government issued computer
    authorizations for use must expire after five working days or after
    the computer leaves the Government premises that issued the
    authorization.

2.  Connection of non-Government owned Portable Electronic Devices (PED)
    to Government IT infrastructure is prohibited without documented
    Risk Acceptance by the bureau or office DAA

3.  The BCISO shall assist the computer owner to mitigate any
    vulnerability found during the inspection. The BCISO requests a
    48-hour advance notice of inspections to ensure equipment and
    personnel are available. Long-term use of non-Government issued
    computers shall require the submission of a wavier to the BCISO for
    approval.

4.  Laptop computers and PEDs provided to employees as awards are not
    considered Government-owned devices and shall be deemed to be of
    non-Government issue.

5.  For information on the use of Wireless Technology, refer to
    **Network Access Security Standard** or its replacement.

##### Non-Government Owned Computers Security 

#### Inspections 

1.  File and printer sharing must be controlled, secured, and limited or
    disabled on all laptops.

2.  Use of passwords is required to enter the system in accordance with
    **Authorization and Access Control Security Standard** or its
    replacement.

3.  Encryption must be available on tested computer equipment and must
    meet or exceed levels set in the Interior Security Policies.

4.  All computers must be compliant with **Virus Protection Security
    Standard** or its replacement.

5.  All computers shall be scanned for vulnerabilities. All discovered
    vulnerabilities shall be corrected prior to authorization.

6.  After a non-Government issued computer has completed the inspection
    process and is found to be safe, the inspecting BCISO shall issue an
    authorization form, specifically the Network Remote Access
    Authorization Form.

7.  All non-Government laptop computers shall have an Interior
    approved/current version of antivirus software (i.e., McAfee,
    Norton, etc.) installed prior to connecting to any Interior network
    or computer source.

##### Personal Usage 

1.  On-site computer usage is restricted to business purposes only with
    limited personal use allowed as outlined in the Acceptable Use
    Security Standard.

2.  While connected to Government networks, users are bound to adhere to
    the "Standards of Ethical Conduct for Employees of the Executive
    Branch." Laptop computers shall not be used to generate, view, send,
    or store harassing e-mail, pornography, or similar text and sound
    files.

##### Access Control 

1.  All sensitive information stored electronically shall be saved
    either as an encrypted file within an encrypted folder, or onto an
    encrypted drive. All sensitive data transmitted shall also be
    encrypted.

2.  Users entering and exiting a Federal facility with laptop computers
    are expected to carry their property pass with the device.

3.  Computers shall use a password-enabled screen saver to further
    protect data integrity and confidentiality when working outside the
    office perimeter.

4.  Before non-Government issued computers are removed from Government
    premises, all sensitive data files shall be removed from them.

5.  All computers shall require a password on startup. All passwords are
    to comply with the current Interior password standard in accordance
    with **Authorization and Access Control Security Standard** or its
    replacement.

##### Non-Government Owned Portable Electronic Devices (PED) 

#### Non-Government owned PEDs are not permitted. 

PEDs include, but are not limited to, non-Government owned/issued
cellular phones including picture and movie-enabled phones, pagers, text
messaging devices, and wireless e-mail devices such as Blackberries,
hand-held scanners, PDAs, voice recorders, and flash memory.

Users shall not attempt to connect non-Government owned PEDs to any
Interior network or computer resource.

# PATCH MANAGEMENT SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes requirements for a secure patch management
program for all Interior networks to prevent unauthorized use or misuse
of Federal Government information. The patch management program shall be
used to create a consistently configured environment that ensures
security against known vulnerabilities in operating systems and
application software. A key component of patch management is the intake
and selection of information regarding both security issues and patch
release. Interior must be aware of which security issues and software
updates are relevant to the environment.

## Standard Detail

#### Patch Prioritization and Scheduling 

#### Normal Application of Patches and Updates to Systems 

The patch cycle shall be used to facilitate the application of standard
patch releases and updates. This cycle can be time or event based. For
example, the schedule can mandate that system updates occur quarterly or
a cycle may be driven by the release of service packs or maintenance
releases. In either instance, modifications and customizations shall be
made based on availability requirements, system criticality, and
available resources.

##### Critical Security and Functionality Patches and Updates 

Criticality shall be the measure used by the Interior to determine the
priority of patch deployment. A number of factors shall be considered
when determining patch priority and scheduling urgency:

1.  Vendor-reported criticality (i.e., high, moderate, low) is a key
    input for calculating a patch\'s significance and priority as is the
    existence of a known exploit or other malicious code that uses the
    vulnerability being patched as an attack vector.

2.  System criticality (i.e., the relative importance of the
    applications and data the system supports to the overall business).

3.  System exposure (i.e., DMZ systems vs. internal file servers vs.
    client workstations).

##### Patch Testing 

Verification of the patch\'s source and integrity is an important step
that ensures the update is valid and has not been maliciously or
accidentally altered. Once a patch has been determined valid, it shall
be placed in a test environment that closely mirrors the production
environment. Critical applications and supported operating platforms
must be fully accounted for while testing the patch infrastructure.
However, detailed patch testing will be dictated by system criticality
and availability requirements, available resources, and patch severity.

##### 

##### Change Management 

Change management practices are required by Interior to be applied to
the patch management process. Once a configuration-managed item has been
identified for change, a Request for Change (RFC) must be submitted and
the configuration shall be modified according the procedures established
by the change management process.

##### Audit and Assessment 

The audit and assessment process is used to verify that the systems to
be updated were actually patched. Reports shall be generated that will
be used to drive the effort toward consistent installation of patches
and updates across the organization. Finally, controls should be in
place to ensure that newly deployed and rebuilt systems are up to
desired specifications with regard to Interior patch level requirements.

##### Notification of Users 

In the event that patches may be uploaded to workstations or servers in
an automated fashion, an announcement will normally be made to the user
organization. Awareness is also important for the user organization
incur unexpected impact that may occur as a result of the patch. Another
aspect that should be communicated in the patch notification is to
assure awareness for the users to patch any application for which they
are individually responsible such as a specific COTS software
application and home systems. Warnings or notices to users shall only
occur in the event that significant news has been released to the public
or if the update requires any special action on the part of the users or
administrative personnel.

#  

# ROUTER AND SWITCH MANAGEMENT SECURITY STANDARD 

This section will be revised in a subsequent release. The Network
Perimeter Security Standard remains in effect until this section is
promulgated.

# SECURITY ARCHITECTURE FRAMEWORK MANAGEMENT SECURITY STANDARD

## Mandatory Standard Guidelines 

This standard establishes requirements for the Interior to evaluate
Information System Security (ISS) architecture framework to ensure
adequate protection of all Interior information resources. The Interior
will conduct an initial review to develop a security model of their
information systems assets. The review will include a systematic
approach of identifying and allocating all information systems assets to
a security architecture baseline. The baseline will include assigning
assets with their functional responsibilities (end user systems, relay
systems, etc), identifying how these assets are used to meet Interior
business needs and requirements, in the form of security domains
(Internal, External, Public Access, Remote Access), and finally
identifying the general security control requirements for each asset.

## Standard Detail

The Interior will develop a Security Architecture Framework (SAF)
baseline and security model within their respective IT structure in
alignment with the Federal Enterprise Architecture, or its replacement,
for additional information and guidelines. The steps in this process
include:

1.  Identifying/storing information pertaining to local IT assets: The
    SAF process shall be used by the Interior to identify how each IT
    asset contributes to the security architecture framework.

2.  Identifying how assets link to a generic security model: The Bureaus
    supported by the Interior shall determine how their assets link to a
    Basic Element category and assign it to a generic security model.

3.  Identifying security domains: After identifying the assets and
    assigning them to their basic elements within the security model,
    the Interior must develop security domains. A security domain
    consists of a set of users, the data for a system, and a security
    standard that governs the use of the domain.

4.  Identifying security control requirements: Once Interior assets have
    been categorized into basic elements in the security model and
    security domains have been created, security controls will be
    assigned based upon the level of security required for each domain
    level and element.

5.  Identifying security products to support security controls and
    security domains: Only those products approved by the Interior in
    the Security Product Database will be used for meeting security
    requirements unless otherwise agreed upon with the Interior.

6.  Periodic Review of Security Architecture Framework: The Interior
    will periodically evaluate their ISS architecture to ensure that
    changes are made accordingly to the SAF baseline to reflect changes
    in business and systems requirements.

7.  Process Scope: This process can be used by the Interior for small
    and large IT architectures. The key is capturing all IT assets
    within the Interior architecture.

8.  Submission and review of the SAF shall follow the guidance of
    Interior's Enterprise Architecture.

# SERVER MANAGEMENT SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes requirements for authorization and access to
Interior server resources through the use of individual credentials.
Group credentials are not permitted for access to any server. For the
purpose of this standard, system level resources such as Domain Name
Server (DNS) or Dynamic Host Configuration Protocol (DHCP) do not apply.
The intent is to eliminate anonymous access to resources and establish a
foundation for auditing. Additionally, Interior servers containing
sensitive information shall meet Interior C2-like Level of Trust.

## Standard Detail

##### Server Configuration 

Configuration standards and management procedures shall be used to
control usability, efficiency, and security of the overall server
environment and shall be kept in a Trusted Facility Manual (TFM). These
standards and other procedures shall be strictly followed when
designing, implementing or managing server configurations. Written
approval from the Change Control Board (CCB) is required prior to any
deviation from these standards.

1.  All security-related service packs, patches, and hot-fixes shall be
    tested and applied to all servers in a timely manner in accordance
    with **Patch Management Security Standard** or its replacement.

2.  All servers shall comply with the encryption of sensitive data in
    accordance with **Information Classification Security Standard** or
    its replacement.

3.  All servers shall be physically secured.

4.  All servers shall be protected by antivirus software in accordance
    with **Virus Protection Security Standard** or its replacement.

5.  All servers will display a warning banner in accordance with
    **Network Access Security Standard** or its replacement.

6.  All servers shall be backed up in a manner that allows for a
    complete server recovery, including operating system, applications,
    data and system state, on a daily basis. Archives of server backups
    shall be kept for a period of at least six weeks.

7.  All back-up media shall be kept in a secured manner consistent with
    Physical Access Security Standard, or its replacement, and be
    protected by controlled access.

8.  A selected portion of backup media shall be kept in an alternate
    physical location secured in a manner consistent with Physical
    Access Security Standard, or its replacement, and be protected by
    controlled access.

9.  System owners shall be responsible for the documentation, validity,
    and availability of information regarding their full operations
    outside of the backup archive.

##### 

##### 

##### Server Specification Settings 

1.  Maximum password age shall be no more than 60 days.

2.  Minimum password length shall be set to twelve characters

3.  Lock out duration is set to 0 (zero) to enable lockout forever, or
    until unlocked by an authorized administrator.

4.  Lock out procedures shall be initiated after three failed attempts
    to login.

5.  Password complexity shall be implemented on all servers.

6.  Null login credentials shall be disabled on all servers.

7.  All server configurations shall be set to prevent administrators
    from performing the following actions:

8.  Debugging programs

9.  Using logon as a service

##### Server Management Access 

Access to server consoles and operating systems shall be limited to
system administrator personnel only. For security purposes, no
exceptions to this rule shall be allowed. All server administrator
accounts shall comply with the password requirements set by
**Authorization and Access Control Security Standard** or its
replacement.

1.  All non-essential user, group, and service accounts must be removed
    immediately.

2.  All non-essential services must be removed immediately.

3.  The administrator account is the original administrative account of
    the server and/or domain. This account shall be renamed and used on
    a limited basis. Only select system administrator personnel are to
    have knowledge of this account's credentials.

4.  Administrators are not permitted to have access to more than one
    administrator account.

5.  Administrators are not permitted to share their account information
    with anyone, including the help desk and management.

6.  Administrators are authorized to use there privileged credential
    only when necessary to the task.

7.  Administrators are not permitted to share their individual account
    or privileged account access information with anyone including the
    help desk and management. Passing of administrator authorized access
    when a system administrator is no longer assigned to a specific
    system to another system administrator shall be authorized by the
    system owner. On Unix systems administrator access is performed by
    the individual user who then does an "SU" for privileged access.

8.  Any service account used by a service to access system resources is
    not to be used for any other purpose. Only system administrator
    personnel are permitted to have knowledge of service account
    credentials.

9.  All system administrators shall receive the appropriate level of
    training to perform their duties in a competent manner.

##### Server Classification 

1.  Each server hosting a mission critical application or service in a
    production environment shall be identified as a production server.
    All production servers must be logically separated and isolated from
    test and development environments.

2.  Each server shall be clearly identified as to the classification of
    information stored or used by the server. These classifications
    shall follow information classification processes in accordance with
    **Information Classification Security Standard** or its replacement.

3.  Servers shall be managed and administered in accordance to their
    identified type and classification.

4.  Server Information: Access to server information is restricted to a
    system administrator and Bureau Chief Information Security Officer
    (BCISO) or persons with written permission from the BCISO. In the
    event that server access is created for security audit purposes, it
    shall be with read-only privileges.

##### Server Logs 

1.  All servers shall maintain security audit logs that include (at a
    minimum) the UserID, date, time, and action performed.

2.  All servers shall log security auditing events showing successful
    and unsuccessful events, including inappropriate access events.

3.  All log files and events shall be managed in a manner that maintains
    their integrity and authenticity, and will be stored or archived for
    a minimum of 1 year or longer as specified by policy requirements or
    standards. System owners may specify project specific log
    retentions, the minimum standard of 1 year must be maintained.

4.  Request for access to server logs shall comply with the server
    information statement in this document.

5.  Access to security auditing logs and web logs shall be limited to as
    appropriate to the system administrators, web administrators,
    Project specific IT Security staff and BCISO personnel. Guidelines
    include separate log servers and separation of duties.

6.  Event logs should be reviewed by system administrators on a daily
    basis and reviewed randomly or on an as-needed basis by BCISO
    personnel.

##### Server Implementation 

1.  All new servers shall meet defined standards and configuration
    requirements as outlined in the appropriate configuration management
    document. A request for implementation of new or revised
    configuration servers shall be submitted to the CCB. Only after
    obtaining CCB approval shall system administrators proceed with the
    server implementation. Any changes from the original design plan
    approved by CCB shall need to be resubmitted via a Request for
    Change (RFC). Servers being added to the environment shall require
    additional approval by the CCB.

2.  Server Change Requests Change requests for any changes to the
    enterprise server system components, configuration or active
    directory design shall be submitted in writing via an RFC to the CCB
    for review. All change requests shall include the reason and
    timeframe for the request as well as all risks, threats, and known
    issues associated with this change. Only after CCB approval shall
    system administrators proceed with the server changes.

3.  Server Services Servers shall only host services for which they were
    designed and approved to host. Any additional services must be
    approved by the CCB. For the purpose of this standard, the term
    'services' refers to specific services that a server was designed to
    host such as a web site, file and print, DNS, DHCP, Telnet, or FTP.
    All services not required for system functionality are to be
    disabled.

#### 

#### Implied Authority 

All system administrators have the implied authority and responsibility
to take action to protect Interior information assets from loss without
CCB approval in an emergency to include modifying or changing server
operating systems, hardware, configurations, or accounts. This authority
is only justified if a direct threat or attack has been discovered and
prompt action is required to reduce the risk and/or loss.

The BCISO has the implied authority and responsibility to direct and
authorize action to protect Interior information assets from loss
without prior approval in an emergency only. This authority is only
justified if a direct threat or attack has been discovered and prompt
action is required to reduce the risk and/or loss.

If this authority is exercised, the administrator shall report it as an
incident and follow Incident Identification, Declaration, Reporting, and
Handling Security Standard or it replacement.

##### Incident Reporting and Response 

In the event of a security vulnerability or breach, malicious activity,
successful attack, or violation of this standard has been discovered or
suspected, an incident shall be reported in accordance with Incident
Identification, Declaration, Reporting, and Handling Security Standard
or its replacement.

#  

# SYSTEMS DEVELOPMENT LIFE CYCLE SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes requirements for the Interior to successfully
implement security protocols and procedures into the Systems Development
Life Cycle (SDLC) to ensure that a system is developed in accordance
with the stated requirements, works effectively, is cost effective, is
secure, and is maintainable. The inclusion of security controls and
measures early in the SDLC will result in less expensive and more
effective security than adding it after a system is operational.

The Interior will implement baseline security controls during the
developmental life cycle of all IT systems. The security controls
selected for each baseline must be implemented at the recommended level
of robustness in order to achieve the estimated threat coverage. In
cases where security baselines do not provide sufficient coverage
against certain types of threats, additional security controls must be
provided upon discovery. National Institute of Standards and Technology
(NIST) Special Publication (SP) 800-53,Rev. 1, Recommended Security
Controls for Federal Information Systems, provides additional
information on appropriate security controls for each type of baseline.

Interior information systems security controls shall be integrated into
the SDLC from system inception. System owners will identify and contact
the Bureau Chief Information Security Officer (BCISO) when the system is
in the Initiation Phase of the SDLC.

Legacy systems which do not have an existing SDLC plan, or equivalent,
shall develop an SDLC Plan relative to the current phase of the system
if it is not fully operational or identified for additional security
controls. Corresponding documentation shall clearly reference its
equivalence to SDLC information.

Interior system security requirements documentation as identified in the
SDLC shall be placed under configuration management control from the
inception of the system and will be included as part of the total set of
system documentation that evolves over the lifecycle. All SDLC plans and
SDLC related documents shall be kept current.

## Standard Detail

The SDLC is separated into five phases during which information system
products are developed. These phases include the Initiation Phase, the
Development/Acquisition Phase, the Implementation Phase, the
Operations/Maintenance Phase, and the Disposition Phase.

#### Initiation Phase 

This is the first phase in the SDLC. The following shall be included in
this phase:

1.  Preparation of the Interconnectivity Security Agreement (ISA)

2.  The Interior shall initiate an ISA during this phase of the SDLC. An
    ISA is part of the overall Certification and Accreditation process
    and must be completed for each new system that will be connected to
    another system outside of the same management boundary.

##### Preliminary Risk Assessment 

The Interior shall conduct an assessment in examination of the basic
security needs of the proposed system. A preliminary risk assessment
shall define the threat environment in which the system will operate.
This assessment should:

1.  result in a brief initial description of the basic security needs of
    the system,

2.  define the threat environment in which the product or system will
    operate, and

3.  define a potential set of countermeasures. This risk-based approach
    to information security is defined in NIST SP 800-30, Risk
    Management Guide for Information Technology Systems.

##### Security Categorization 

The Interior shall define and establish a level (i.e., low, moderate, or
high) of potential impact to prevent a potential breach of security.
FIPS Publication 199, Standards for Security Categorization of Federal
Information and Information Systems and NIST Special Publication 800-60,
Guide for Mapping Types of Information and Information Sytems to
Security Categories, shall be used in conjunction with available
vulnerability and threat information in assessing all potential risk to
an organization through operation of the proposed information system.

##### Privacy Impact Assessment 

The Interior is required to initiate a Privacy Impact Assessment (PIA)
in this phase as part of the ongoing security effort. Refer to Privacy
Impact Assessment Security Standard, or its replacement, for additional
information on this subject.

#### Development Phase 

This is the second phase in the SDLC. The following shall be included in
this phase:

##### Risk Assessment

The Interior is required to perform a Security Risk Assessment during
this phase to identify protection requirements for the system through a
formal risk assessment process. The selection of appropriate types of
safeguards or countermeasures must take into consideration the results
of the security assurance requirements analysis as defined in the
previous phase.

##### Security Functional Requirements Analysis

The Interior is required to perform an analysis of requirements that
include the following components:

1.  system security environment, and

2.  security functional requirements. This process shall include an
    analysis of laws and regulations such as the Privacy Act, FISMA, OMB
    circulars, Agency enabling acts, NIST Special Publications and FIPS,
    and other legislation and federal regulations, which define baseline
    security requirements.

##### 

##### Security Assurance Requirements Analysis 

The Interior is required to conduct an analysis of requirements that
address the developmental activities required and assurance evidence
needed to produce the desired level of confidence that the information
security will work correctly and effectively. A balance must exist
between the benefits to mission performance from system security and the
risks associated with operation of the system without security.

##### Cost Considera**t**ions and Reporting 

The Interior is required to determine what percentage of the development
cost can be attributed to information security over the life cycle of
the system. Security controls should be included at the beginning of the
SDLC as it is the most cost effective approach for two reasons:

1.  it is usually more difficult to add functionality into a system
    after it has been built; and

2.  it is frequently less expensive to include the preventive measures
    to deal with the cost of a security incident.

##### Security Planning 

The Interior is required to ensure that agreed upon security controls,
planned or in place, are fully documented in a system security plan.

##### Security Control Development 

Security controls described in the respective security plans shall be
designed, developed, and implemented in this phase. Refer to Security
Plan Management Security Standard, or its replacement, for additional
information on this subject.

##### Developmental Security Test and Evaluation 

The Interior is required to ensure that security controls developed for
a new information system are working properly and are effective as
evidence by the developer's test materials and test results.

#### Implementation Phase 

This is the third phase of the SDLC. The following shall be included in
this phase:

##### Security Control Integration 

The Interior is required to make certain that security controls are
integrated at the operational site where the information system is to be
deployed into production. Security control settings and switches will be
enabled in accordance with manufacturer instructions and available
security implementation guidance such as the Trusted Facility Manual
(TFM) for the system.

##### Security Certification 

The Interior is required to ensure that security controls are
effectively implemented through established verification techniques and
procedures within the system certification process. Refer to
Certification and Accreditation Security Standard, or its replacement,
and in accordance with NIST SP 800-37: Guide for the Security
Certification and Accreditation of Federal Information Systems, May
2004.

##### Security Accreditation 

The Interior is required to ensure that the necessary security
authorization of an information system to process, store, or transmit
information is obtained. OMB Circular A-130 requires the security
authorization of an information system to process, store, or transmit
information. Refer to Certification and Accreditation Security Standard,
or its replacement, and in accordance with NIST SP 800-37: Guide for the
Security Certification and Accreditation of Federal Information Systems,
May 2004.

#### Operations and Maintenance Phase 

This phase is the fourth phase of the SDLC. The following shall be
included in this phase:

##### Configuration Management and Control 

The Interior is required to ensure adequate consideration of potential
security impacts due to specific changes to an information system or its
surrounding environment. Depending upon the extent of change to an
operational system, additional Certification and Accreditation (C&A)
measures may be required. Significant changes include operating system
version and major applications that could impact the current operation.

##### Continuous Monitoring

The Interior is required to make certain that controls continue to be
effective in their application through periodic testing and evaluation.

#### Disposition Phase 

Disposition is the final phase in the SDLC. The following shall be
included in this phase:

##### Media Sanitization

The Interior is required to make certain that all data is deleted,
erased, and/or written over as necessary to protect information system
hardware. Refer to **Media Sanitization and Disposal Security
Standard**, or its replacement, for additional information on this
subject.

#### Hardware and Software Disposition 

The Interior is required to ensure that all hardware and software is
disposed of in accordance with **Media Sanitization and Disposal
Security Standard** or its replacement.

# VIRUS PROTECTION SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes the guidelines for the management and
protection of software used within the Interior. Virus definitions and
updates shall be tested and certified prior to deployment. All users are
responsible for reporting suspected viruses to the designated IT support
staff immediately.

## Standard Detail

##### Virus Protected Systems 

Virus-checking software must be installed and maintained to include the
latest virus signature file applied on all servers, workstations,
laptops, and personal electronic devices regardless of operating system,
whether connected to the Interior networks or not. This includes
contractor-owned and/or contractor-operated systems, standalone
computers and personal electronic devices, and computers of the Interior
and business partners connected to networks. Virus-checking software
must meet the requirements outlined in this standard and in CCE Trusted
Facilities Manuals (TFM) or standards.

E-mail servers must have an antivirus package installed and running with
the latest virus signatures applied. E-mail servers shall have a content
filtering package or additional device capable of blocking specified
attachments, installed, and be running.

##### Virus Software Configurations and Scanning Standard 

1.  All non-Government machine-readable produced computer media (for
    example, floppy diskettes, zip cartridges, CD-ROMs, tapes, etc.) and
    downloaded files must be scanned for viruses and other malicious
    software before initial use. This pertains to all Interior equipment
    operated by employees, contractors, and partners.

2.  Remote access users are required to bring in their Government-issued
    computer laptops and Portable Electronic Devices (PED) to their
    designated bureau work facility (minimum of once each month) so that
    Interior approved virus scans can be run and/or antivirus software
    updates be installed on this equipment. However, this frequency may
    change in the event of a virus outbreak.

3.  Users are required to comply with any call-in of laptops within the
    timeframe designated in the announcement, and any non-compliant
    laptop will be prohibited from access to any Interior networks until
    the required updates are applied

4.  When feasible, standardized virus software configurations shall be
    used on non- enterprise systems.

5.  Antivirus software shall be configured to scan all files and macros
    (not just program executables) for viruses. This does not apply to
    swap files.

6.  Antivirus software shall be configured for both on-access and
    scheduled scanning.

7.  Antivirus software shall be configured so that all inbound and
    outbound files are scanned along with the boot sector and floppy
    drive (during shutdown).

8.  Antivirus software shall be configured to scan e-mail attachments
    prior to sending or opening.

9.  Antivirus software shall be configured so that ActiveX and Java
    components in Web pages and HTML-based e-mail messages are scanned.

10. End users shall not have the ability to disable the antivirus
    software on their computer.

11. All e-mail stored, inbound or outbound, with or without attachments,
    must be scanned for viruses regardless of the destination address.

12. E-mail scanning must include all attachments and macros. Attachments
    and macros that cannot be scanned must be deleted and replaced with
    a message detailing the action taken. Outgoing e-mail must be
    scanned at the network server to which the client is connected. If a
    virus is detected on outgoing e-mail, the server must run a virus
    scan immediately on the originating client.

13. Antivirus software shall be configured so that all activity of the
    antivirus software is logged. Ensure the logs are included in the
    daily backups. Logs must be maintained until no longer needed.

14. The date of the virus definitions shall be monitored to ensure the
    automatic update is functioning properly.

15. The directory that contains the "setup.exe" for the antivirus
    software shall be secured so that end users cannot delete, rename,
    or write files to this directory, and/or inhibit any file tampering.

16. Antivirus software shall be configured to block e-mail that it is
    unable to scan.

17. Antivirus updates shall be loaded at the time system instruction is
    received.

18. Antivirus software shall be configured to automatically pull and
    apply the latest virus definition updates from a central repository
    site daily.

19. All non-Government-owned laptops shall have an Interior
    approved/current version of antivirus software installed prior to
    connecting to any Interior network or computer source.

# VULNERABILITY SCAN SECURITY STANDARD 

## Mandatory Standard Guidelines 

This standard establishes the guidelines for the protection of Interior
information systems. Vulnerability scans are required to be conducted on
a monthly basis for all operational networks, systems, and servers,
inclusive of routers and switches, that the Interior are responsible for
managing.

Interior is the configuration authority for all vulnerability scans
performed and requires that all scanning configurations established by
the Bureaus are required to be uniform in approach.

Each Bureau Chief Information Security Officer (BCISO) is responsible
for scanning all regional-based hardware, regardless of who owns the
equipment.

## Standard Detail

##### New Equipment/Equipment Upgrade 

Informational scans may be requested by the BCISO and Change Control
Board (CCB) prior to implementation of new or modified/upgraded
equipment into the production environment. Scan results shall be
provided to the BCISO and CCB. Scans will be conducted prior to new
system installations and when any major modifications/upgrades are
implemented on current operational systems regarding their connectivity,
application functionality, and security configurations. Bureaus and
staff shall only scan networks or servers for which they are
responsible.

A series of scans shall be performed during the developmental cycle such
as baseline server (if new hardware) with full applications loaded, then
pre-pilot and preproduction. The systems administrator should contact
the closest regional Field Office to coordinate the scanning request.
Only pre-pilot and pre-production scans are required for configuration
management approval prior to further action.

New systems and equipment or major modifications to existing
systems/equipment must be scanned in their development and/or test
environment prior to deployment into a production environment. System
representatives must contact the BCISO and CCB to initiate a scan 10
working days prior to scheduling a special or pre-production scan. The
system/equipment will not be deployed until vulnerabilities identified
have been adequately addressed and risks accepted. Equipment not scanned
prior to production will be removed immediately from the network.

##### Routine Scans 

The BCISO shall coordinate all scans performed at the Agency level and
provide the Interior Office of Cyber Security with the names and contact
information for a primary and secondary contact person relative to
performing scans. Scan results from production sources shall be
forwarded to the responsible BCISO and CCB for corrective action
depending upon hardware ownership. It is the responsibility of the
applicable BCISO and/or the CCB to ensure that all vulnerabilities are
addressed within the appropriate timeframes and risks accepted.

1.  All scans should be completed no later than the 10th calendar day of
    each month, unless they are considered a special scan, i.e.,
    following major modifications/upgrades. BCISOs must notify the
    Department and all relative Bureaus prior to performing a scan.

2.  Scan results will be provided to the responsible system
    owners/administrators so that identified vulnerabilities can be
    addressed. High and moderate risk vulnerabilities require a formal
    response from the appropriate system representatives.

3.  Responsible parties will reply back to the respective Agency BCISO
    within seven calendar days after receiving the scan results for a
    moderate risk vulnerability, and within one workday for a high-risk
    vulnerability. An action plan must be included for vulnerabilities
    not mitigated within the required timeframes. The originating BCISO
    must receive the results no later than the 23rd calendar day of each
    month.

4.  Computer network staff shall address vulnerabilities in the order of
    their associated risk as a means to mitigate the most serious
    vulnerabilities immediately (High, Moderate, Low). All
    vulnerabilities on Interior networks, systems, and servers
    identified as 'high' and 'moderate' must be formally addressed in a
    timely fashion. A reasonable effort shall be made to address and
    correct vulnerabilities rated "low."

5.  Scan responses provided to the BCISO and CCB for all high and
    moderate vulnerabilities should fall into one of five categories:

6.  Vulnerability has been corrected. The response shall indicate what
    corrective action has been taken and the date of correction. The
    system owner/administrator must sign the response to certify that
    these actions have been taken. The BCISO and CCB must initiate a
    rescan to ensure that corrective actions mitigated the
    vulnerability.

7.  Vulnerability is a false-positive. System owners/administrators must
    explain why they believe an identified vulnerability is a
    false-positive. Once the system owner/administrator has provided the
    BCISO and CCB an explanation and the BCISO and CCB have concurred,
    the system representatives will no longer have to address the
    vulnerability on subsequent monthly reports.

8.  Corrective action is planned, but has not been completed. The
    response must include an explanation outlining steps planned and the
    timeframe for expected completion.

9.  Often vulnerability cannot be mitigated for business reasons. The
    responsible system owner/administrator shall provide strong
    justification for vulnerabilities for which there is not a plan to
    correct. Additionally, the BCISO will request risks acceptance from
    the Interior CIO for bureau vulnerabilities that cannot be mitigated
    for business reasons.

10. For vulnerability cannot be mitigated for vendor reasons. The system
    owner/administrator shall provide information on what is needed from
    the vendor to correct the vulnerability and the timeframe. If no fix
    is available or will not be available for one month or longer, then
    the owner/administrator should work with the BCISO to find a
    workable alternative to mitigate the vulnerability.

# Appendices 

# Appendix A - Glossary of Information Security Terms

Table 109 Links to Definitions by Alphabet

  ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
  [A](#GA)   [B](#GB)   [C](#GC)   [D](#GD)   [E](#GE)   [F](#GF)   [G](#GG)   [H](#GH)   [I](#GI)

  J          [K](#GK)   [L](#GL)   [M](#GM)   [N](#GN)   [O](#GO)   [P](#GP)   Q          [R](#GR)

  [S](#GS)   [T](#GT)   [U](#GU)   [V](#GV)   [W](#GW)   [X](#GZ)   Y          [Z](#GZ)   
  ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------

[]{#__RefHeading___Toc193514881 .anchor}Table 110 Glossary of
Information Security Terms Based upon NIST IR 7298 and DOI References

  ------------------------- ----------------------------------------- ------------------
  Term                      Definition                                Source Reference

  []{#GA .anchor}Access     Ability to make use of any information    SP 800-32
                            system (IS) resource.                     

  Access Authority          An entity responsible for monitoring and  SP 800-57
                            granting access privileges for other      
                            authorized entities.                      

  Access Control            The process of granting or denying        FIPS 201
                            specific requests:\                       
                            1) for obtaining and using information    
                            and related information processing        
                            services; and\                            
                            2) to enter specific physical facilities  
                            (e.g., Federal buildings, military        
                            establishments, and border crossing       
                            entrances).                               

  Access Control Lists      A register of:\                           SP 800-12
  (ACLs)                    1) users (including groups, machines,     
                            processes) who have been given permission 
                            to use a particular system resource, and\ 
                            2) the types of access they have been     
                            permitted.                                

  Account Management, User  Involves:\                                SP 800-12
                            1) the process of requesting,             
                            establishing, issuing, and closing user   
                            accounts;\                                
                            2) tracking users and their respective    
                            access authorizations; and\               
                            3) managing these functions.              

  Accountability            The security goal that generates the      SP 800-27A
                            requirement for actions of an entity to   
                            be traced uniquely to that entity. This   
                            supports non-repudiation, deterrence,     
                            fault isolation, intrusion detection and  
                            prevention, and after-action recovery and 
                            legal action.                             

  Accreditation             The official management decision given by SP 800-53; FIPS
                            a senior agency official to authorize     200
                            operation of an information system and to 
                            explicitly accept the risk to agency      
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals, based on the implementation  
                            of an agreed-upon set of security         
                            controls.                                 

  Accreditation Authority   SEE Authorizing Official                   

  Accreditation Boundary    All components of an information system   SP 800-53
                            to be accredited by an authorizing        
                            official and excludes separately          
                            accredited systems, to which the          
                            information system is connected.          

  Accreditation Package     The evidence provided to the authorizing  SP 800-37
                            official to be used in the security       
                            accreditation decision process.\          
                            Evidence includes, but is not limited     
                            to:\                                      
                            1) the system security plan;\             
                            2) the assessment results from the        
                            security certification; and\              
                            3) the plan of action and milestones.     

  Accrediting Authority     Official with the authority to formally   SP 800-53
                            assume responsibility for operating an    
                            information system at an acceptable level 
                            of risk to agency operations (including   
                            mission, functions, image, or             
                            reputation), agency assets, or            
                            individuals.                              

  Activation Data           Private data, other than keys, that are   SP 800-32
                            required to access cryptographic modules. 

  Active Content            Active content refers to electronic       SP 800-46
                            documents that are able to automatically  
                            carry out or trigger actions on a         
                            computer platform without the             
                            intervention of a user.                   

  Adequate Security         Security commensurate with the risk and   SP 800-53; FIPS
                            the magnitude of harm resulting from the  200; OMB Circular
                            loss, misuse, or unauthorized access to   A-130, App. III
                            or modification of information.           

  Administrative Safeguards Administrative actions, policies, and     SP 800-66
                            procedures to manage the selection,       
                            development, implementation, and          
                            maintenance of security measures to       
                            protect electronic health information and 
                            to manage the conduct of the covered      
                            entity\'s workforce in relation to        
                            protecting that information.              

  Advanced Encryption       The Advanced Encryption Standard          SP 800-46
  Standard (AES)            specifies a U.S. Government-approved      
                            cryptographic algorithm that can be used  
                            to protect electronic data. The AES       
                            algorithm is a symmetric block cipher     
                            that can encrypt (encipher) and decrypt   
                            (decipher) information.                   

  Advanced Encryption       This standard specifies the Rijndael      FIPS 197
  Standard (AES)            algorithm, a symmetric block cipher that  
                            can process data blocks of 128 bits,      
                            using cipher keys with lengths of 128,    
                            192, and 256 bits.                        

  Agency                    Any executive department, military        FIPS 200; 44
                            department, government corporation,       U.S.C., Sec. 3502
                            government controlled corporation, or     
                            other establishment in the executive      
                            branch of the government (including the   
                            Executive Office of the President), or    
                            any independent regulatory agency, but    
                            does not include:\                        
                            1) the General Accounting Office;\        
                            2) the Federal Election Commission;\      
                            3) the governments of the District of     
                            Columbia and of the territories and       
                            possessions of the United States, and     
                            their various subdivisions; or\           
                            4) government-owned contractor-operated   
                            facilities, including laboratories        
                            engaged in national defense research and  
                            production activities.                    

  ALSO SEE Executive Agency                                            

  Agency Certification      A CA that acts on behalf of an Agency,    SP 800-32
  Authority (CA)            and is under the operational control of   
                            an Agency.                                

  Agent                     A program used in distributed denial of   SP 800-61
                            service (DDoS) attacks that sends         
                            malicious traffic to hosts based on the   
                            instructions of a handler.                

  Analysis                  The examination of acquired data for its  SP 800-72
                            significance and probative value to the   
                            case.                                     

  Antivirus Software        A program that monitors a computer or     SP 800-83
                            network to identify all major types of    
                            malware and prevent or contain malware    
                            incidents.                                

  Applicant                 The subscriber is sometimes called an     SP 800-32
                            "applicant" after applying to a           
                            certification authority for a             
                            certificate, but before the certificate   
                            issuance procedure is completed.          

  Application               The use of information resources          SP 800-37
                            (information and information technology)  
                            to satisfy a specific set of user         
                            requirements.                             

  Application Content       Application content filtering is          SP 800-41
  Filtering                 performed by a software proxy agent to    
                            remove or quarantine viruses that may be  
                            contained in email attachments, to block  
                            specific Multipurpose Internet Mail       
                            Extensions (MIME) types, or to filter     
                            other active content such as Java,        
                            JavaScript, and ActiveX® Controls.        

  Approved                  Federal Information Processing Standard   FIPS 201
                            (FIPS) approved or National Institute of  
                            Standards and Technology (NIST)           
                            recommended.\                             
                            An algorithm or technique that is         
                            either:\                                  
                            1) specified in a FIPS or NIST            
                            Recommendation, or\                       
                            2) adopted in a FIPS or NIST              
                            Recommendation.                           

  Approved                  FIPS-approved and/or NIST-recommended.    FIPS 140-2

  Approved Mode of          A mode of the cryptographic module that   FIPS 140-2
  Operation                 employs only Approved security functions  
                            (not to be confused with a specific mode  
                            of an Approved security function, e.g.,   
                            Data Encryption Standard (DES) Cipher     
                            Block Chaining (CBC) mode).               

  Approved Security         A security function (e.g., cryptographic  FIPS 140-2
  Function                  algorithm, cryptographic key management   
                            technique, or authentication technique)   
                            that is either\                           
                            a) specified in an Approved standard,\    
                            b) adopted in an Approved standard and    
                            specified either in an appendix of the    
                            Approved standard or in a document        
                            referenced by the Approved standard, or\  
                            c) specified in the list of Approved      
                            security functions.                       

  Assessment Method         A focused activity or action employed by  SP 800-53
                            an assessor for evaluating a particular   
                            attribute of a security control.          

  Assessment Procedure      A set of activities or actions employed   SP 800-53
                            by an assessor to determine the extent to 
                            which a security control is implemented   
                            correctly, operating as intended, and     
                            producing the desired outcome with        
                            respect to meeting the security           
                            requirements for the system.              

  Asset                     A major application, general support      SP 800-26
                            system, high impact program, physical     
                            plant, mission critical system, or a      
                            logically related group of systems.       

  Assurance                 One of the five "Security Goals." It      SP 800-27A
                            involves support for our confidence that  
                            the other four security goals (integrity, 
                            availability, confidentiality, and        
                            accountability) have been adequately met  
                            by a specific implementation. "Adequately 
                            met" includes\                            
                            (1) functionality that performs           
                            correctly,\                               
                            (2) sufficient protection against         
                            unintentional errors (by users or         
                            software), and\                           
                            (3) sufficient resistance to intentional  
                            penetration or by-pass.                   

  Asymmetric Keys           Two related keys, a public key and a      FIPS 201
                            private key that are used to perform      
                            complementary operations, such as         
                            encryption and decryption or signature    
                            generation and signature verification.    

  Attack Signature          A specific sequence of events indicative  SP 800-12
                            of an unauthorized access attempt.        

  Attribute Authority       An entity, recognized by the Federal      SP 800-32
                            Public Key Infrastructure (PKI) Policy    
                            Authority or comparable Agency body as    
                            having the authority to verify the        
                            association of attributes to an identity. 

  Audit                     Independent review and examination of     SP 800-32;
                            records and activities to assess the      CNSSI-4009
                            adequacy of system controls, to ensure    
                            compliance with established policies and  
                            operational procedures, and to recommend  
                            necessary changes in controls, policies,  
                            or procedures                             

  Audit Data                Chronological record of system activities SP 800-32
                            to enable the reconstruction and          
                            examination of the sequence of events and 
                            changes in an event.                      

  Audit Reduction Tools     Preprocessors designed to reduce the      SP 800-12
                            volume of audit records to facilitate     
                            manual review. Before a security review,  
                            these tools can remove many audit records 
                            known to have little security             
                            significance. These tools generally       
                            remove records generated by specified     
                            classes of events, such as records        
                            generated by nightly backups.             

  Audit Trail               A record showing who has accessed an      SP 800-47
                            Information Technology (IT) system and    
                            what operations the user has performed    
                            during a given period.                    

  Authenticate              To confirm the identity of an entity when SP 800-32
                            that identity is presented.               

  Authentication            Verifying the identity of a user,         SP 800-53; FIPS
                            process, or device, often as a            200
                            prerequisite to allowing access to        
                            resources in an information system.       

  Authentication            The process of establishing confidence of FIPS 201
                            authenticity.                             

  Authentication            Encompasses identity verification,        FIPS 190
                            message origin authentication, and        
                            message content authentication.           

  Authentication            A process that establishes the origin of  SP 800-21 \[2nd
                            information or determines an entity's     Ed\]
                            identity.                                 

  Authentication Code       A cryptographic checksum based on an      FIPS 140-2
                            Approved security function (also known as 
                            a Message Authentication Code (MAC)).     

  Authentication,           The process of establishing confidence in SP 800-63
  Electronic                user identities electronically presented  
                            to an information system.                 

  Authentication Mechanism  Hardware or software-based mechanisms     SP 800-72
                            that force users to prove their identity  
                            before accessing data on a device.        

  Authentication Mode       A block cipher mode of operation that can SP 800-38B
                            provide assurance of the authenticity     
                            and, therefore, the integrity of data.    

  Authentication Protocol   A well specified message exchange process SP 800-63
                            that verifies possession of a token to    
                            remotely authenticate a claimant. Some    
                            authentication protocols also generate    
                            cryptographic keys that are used to       
                            protect an entire session, so that the    
                            data transferred in the session is        
                            cryptographically protected.              

  Authentication Tag        A pair of bit strings associated to data  SP 800-38B
                            to provide assurance of its authenticity. 

  Authentication Token      Authentication information conveyed       FIPS 196
                            during an authentication exchange.        

  Authenticity              The property of being genuine and being   SP 800-53
                            able to be verified and trusted;          
                            confidence in the validity of a           
                            transmission, a message, or message       
                            originator. See authentication.           

  Authorization             The official management decision given by SP 800-37
                            a senior agency official to authorize     
                            operation of an information system and to 
                            explicitly accept the risk to agency      
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals, based on the implementation  
                            of an agreed-upon set of security         
                            controls.                                 

  Authorize Processing      The official management decision given by SP 800-53
                            a senior agency official to authorize     
                            operation of an information system and to 
                            explicitly accept the risk to agency      
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals, based on the implementation  
                            of an agreed-upon set of security         
                            controls.                                 

  Authorizing Official      Official with the authority to formally   SP 800-53; FIPS
                            assume responsibility for operating an    200
                            information system at an acceptable level 
                            of risk to agency operations (including   
                            mission, functions, image, or             
                            reputation), agency assets, or            
                            individuals. Synonymous with Designated   
                            Approving/Accrediting Authority (DAA).    

  Authorizing Official's    Individual selected by an authorizing     SP 800-37
  Designated Representative official to act on their behalf in        
                            coordinating and carrying out the         
                            necessary activities required during the  
                            security certification and accreditation  
                            of an information system (with certain    
                            limitations and restrictions).            

  Automated Key Transport   The transport of cryptographic keys,      FIPS 140-2
                            usually in encrypted form, using          
                            electronic means such as a computer       
                            network (e.g., key transport/agreement    
                            protocols).                               

  Automated Password        An algorithm which creates random         FIPS 181
  Generator                 passwords that have no association with a 
                            particular user.                          

  Availability              Ensuring timely and reliable access to    SP 800-53; FIPS
                            and use of information.                   200; FIPS 199; 44
                                                                      U.S.C., Sec. 3542

  Awareness (Information    Activities which seek to focus an         SP 800-50
  Security)                 individual's attention on an (information 
                            security) issue or set of issues.         

  []{#GB .anchor}Backup     A copy of files and programs made to      SP 800-34;
                            facilitate recovery if necessary.         CNSSI-4009

  Baseline Security         The minimum security controls required    SP 800-16
                            for safeguarding an IT system based on    
                            its identified needs for confidentiality, 
                            integrity and/or availability protection. 

  Baselining                Monitoring resources to determine typical SP 800-61
                            utilization patterns so that significant  
                            deviations can be detected.               

  Bastion Host              A bastion host is typically a firewall    SP 800-41
                            implemented on top of an operating system 
                            that has been specially configured and    
                            hardened to be resistant to attack.       

  Behavioral Outcome        What an individual who has completed the  SP 800-16
                            specific training module is expected to   
                            be able to accomplish in terms of IT      
                            security-related job performance.         

  Binding                   Process of associating two related        SP 800-32
                            elements of information.                  

  Binding                   An acknowledgement by a trusted           SP 800-21 \[2nd
                            third-party that associates an entity's   Ed\]
                            identity with its public key.\            
                            This may take place through\              
                            (1) a certification authority's           
                            generation of a public key certificate,\  
                            (2) a security officer's verification of  
                            an entity's credentials and placement of  
                            the entity's public key and identifier in 
                            a secure database, or\                    
                            (3) an analogous method.                  

  Biometric                 A physical or behavioral characteristic   SP 800-32
                            of a human being.                         

  Biometric                 A measurable, physical characteristic or  FIPS 201
                            personal behavioral trait used to         
                            recognize the identity, or verify the     
                            claimed identity, of an applicant. Facial 
                            images, fingerprints, and handwriting     
                            samples are all examples of biometrics.   

  Biometric Information     The stored electronic information         FIPS 201
                            pertaining to a biometric. This           
                            information can be in terms of raw or     
                            compressed pixels or in terms of some     
                            characteristic (e.g. patterns.)           

  Biometric System          An automated system capable of:1)         FIPS 201
                            capturing a biometric sample from an end  
                            user;2) extracting biometric data from    
                            that sample;3) comparing the biometric    
                            data with that contained in one or more   
                            reference templates;4) deciding how well  
                            they match; and 5) indicating whether or  
                            not an identification or verification of  
                            identity has been achieved.               

  Biometric Template        A characteristic of biometric information FIPS 201
                            (e.g. minutiae or patterns.)              

  Blended Attack            Malicious code that uses multiple methods SP 800-61
                            to spread.                                

  Block                     Sequence of binary bits that comprise the FIPS 197
                            input, output, State, and Round Key. The  
                            length of a sequence is the number of     
                            bits it contains. Blocks are also         
                            interpreted as arrays of bytes.           

  Block Cipher              A symmetric key cryptographic algorithm   SP 800-90
                            that transforms a block of information at 
                            a time using a cryptographic key. For a   
                            block cipher algorithm, the length of the 
                            input block is the same as the length of  
                            the output block.                         

  Block Cipher Algorithm    A family of functions and their inverses  SP 800-67
                            that is parameterized by a cryptographic  
                            key; the function maps bit strings of a   
                            fixed length to bit strings of the same   
                            length.                                   

  Boot Sector Virus         A virus that plants itself in a system's  SP 800-61
                            boot sector and infects the master boot   
                            record.                                   

  Boundary Protection       Monitoring and control of communications  SP 800-53 Rev 1
                            at the external boundary between          
                            information systems completely under the  
                            management and control of the             
                            organization and information systems not  
                            completely under the management and       
                            control of the organization, and at key   
                            internal boundaries between information   
                            systems completely under the management   
                            and control of the organization, to       
                            prevent and detect malicious and other    
                            unauthorized communication, employing     
                            controlled interfaces (e.g., proxies,     
                            gateways, routers, firewalls, encrypted   
                            tunnels).                                 

  Boundary Router           A boundary router is located at the       SP 800-41
                            organizations boundary to an external     
                            network.                                  

  Brute Force Password      A method of accessing an obstructed       SP 800-72
  Attack                    device through attempting multiple        
                            combinations of numeric and/or            
                            alphanumeric passwords.                   

  Buffer Overflow           A condition at an interface under which   SP 800-28
                            more input can be placed into a buffer or 
                            data holding area than the capacity       
                            allocated, overwriting other information. 
                            Attackers exploit such a condition to     
                            crash a system or to insert specially     
                            crafted code that allows them to gain     
                            control of the system.                    

  Buffer Overflow Attack    A method of overloading a predefined      SP 800-72
                            amount of space in a buffer, which can    
                            potentially overwrite and corrupt data in 
                            memory.                                   

  Business Continuity Plan  The documentation of a predetermined set  SP 800-34
  (BCP)                     of instructions or procedures that        
                            describe how an organization's business   
                            functions will be sustained during and    
                            after a significant disruption.           

  Business Impact Analysis  An analysis of an information technology  SP 800-34
  (BIA)                     (IT) system's requirements, processes,    
                            and interdependencies used to             
                            characterize system contingency           
                            requirements and priorities in the event  
                            of a significant disruption.              

  Business                  The documentation of a predetermined set  SP 800-34
  Recovery-Resumption Plan  of instructions or procedures that        
  (BRP)                     describe how business processes will be   
                            restored after a significant disruption   
                            has occurred.                             

  []{#GC .anchor}Capture    The method of taking a biometric sample   FIPS 201
                            from an end user.                         

  Cardholder                An individual possessing an issued        FIPS 201
                            Personal Identity Verification (PIV)      
                            card.                                     

  CBC/MAC                   SEE Cipher Block Chaining-Message          
                            Authentication Code                       

  CCM SEE Counter with      A digital representation of information   SP 800-32
  Cipher-Block              which at least\                           
  Chaining-Message          1) identifies the certification authority 
  Authentication Code       issuing it,\                              
  Certificate               2) names or identifies its subscriber,\   
                            3) contains the subscriber\'s public      
                            key,\                                     
                            4) identifies its operational period,     
                            and\                                      
                            5) is digitally signed by the             
                            certification authority issuing it.       

  Certificate               A set of data that uniquely identifies an SP 800-21 \[2nd
                            entity, contains the entity's public key  Ed\]
                            and possibly other information, and is    
                            digitally signed by a trusted party,      
                            thereby binding the public key to the     
                            entity. Additional information in the     
                            certificate could specify how the key is  
                            used and its cryptoperiod.                

  Certificate Management    A Certification Authority (CA) or a       SP 800-32
  Authority (CMA)           Registration Authority (RA).              

  Certificate Policy (CP)   A Certificate Policy is a specialized     SP 800-32
                            form of administrative policy tuned to    
                            electronic transactions performed during  
                            certificate management. A Certificate     
                            Policy addresses all aspects associated   
                            with the generation, production,          
                            distribution, accounting, compromise      
                            recovery and administration of digital    
                            certificates. Indirectly, a certificate   
                            policy can also govern the transactions   
                            conducted using a communications system   
                            protected by a certificate-based security 
                            system. By controlling critical           
                            certificate extensions, such policies and 
                            associated enforcement technology can     
                            support provision of the security         
                            services required by particular           
                            applications.                             

  Certificate-Related       Information, such as a subscriber\'s      SP 800-32
  Information               postal address, that is not included in a 
                            certificate. May be used by a             
                            Certification Authority (CA) managing     
                            certificates.                             

  Certificate Revocation    A list of revoked public key certificates SP 800-63
  List (CRL)                created and digitally signed by a         
                            Certification Authority.                  

  Certificate Revocation    A list of revoked but un-expired          SP 800-21 \[2nd
  List                      certificates issued by a CA.              Ed\]

  Certificate Status        A trusted entity that provides on-line    SP 800-32
  Authority                 verification to a Relying Party of a      
                            subject certificate\'s trustworthiness,   
                            and may also provide additional attribute 
                            information for the subject certificate.  

  Certification             A comprehensive assessment of the         SP 800-53; FIPS
                            management, operational, and technical    200
                            security controls in an information       
                            system, made in support of security       
                            accreditation, to determine the extent to 
                            which the controls are implemented        
                            correctly, operating as intended, and     
                            producing the desired outcome with        
                            respect to meeting the security           
                            requirements for the system.              

  Certification             The process of verifying the correctness  FIPS 201
                            of a statement or claim and issuing a     
                            certificate as to its correctness.        

  Certification Agent       The individual, group, or organization    SP 800-53
                            responsible for conducting a security     
                            certification.                            

  Certification and         A comprehensive assessment of the         SP 800-37
  Accreditation (C&A)       management, operational, and technical    
                            security controls in an information       
                            system, made in support of security       
                            accreditation, to determine the extent to 
                            which the controls are implemented        
                            correctly, operating as intended, and     
                            producing the desired outcome with        
                            respect to meeting the security           
                            requirements for the system.              
                            Accreditation is the official management  
                            decision given by a senior agency         
                            official to authorize operation of an     
                            information system and to explicitly      
                            accept the risk to agency operations      
                            (including mission, functions, image, or  
                            reputation), agency assets, or            
                            individuals, based on the implementation  
                            of an agreed-upon set of security         
                            controls.                                 

  Certification Authority   A trusted entity that issues and revokes  FIPS 201
  (CA)                      public key certificates.                  

  Certification Authority   The entity in a public key infrastructure SP 800-21 \[2nd
                            (PKI) that is responsible for issuing     Ed\]
                            certificates and exacting compliance to a 
                            PKI policy.                               

  Certification Authority   The collection of equipment, personnel,   SP 800-32
  Facility                  procedures and structures that are used   
                            by a Certification Authority to perform   
                            certificate issuance and revocation.      

  Certification Practice    A statement of the practices that a       SP 800-32
  Statement (CPS)           Certification Authority employs in        
                            issuing, suspending, revoking and         
                            renewing certificates and providing       
                            access to them, in accordance with        
                            specific requirements (i.e., requirements 
                            specified in this Certificate Policy, or  
                            requirements specified in a contract for  
                            services).                                

  Chain of Custody          A process that tracks the movement of     SP 800-72
                            evidence through its collection,          
                            safeguarding, and analysis lifecycle by   
                            documenting each person who handled the   
                            evidence, the date/time it was collected  
                            or transferred, and the purpose for the   
                            transfer.                                 

  Challenge-Response        An authentication protocol where the      SP 800-63
  Protocol                  verifier sends the claimant a challenge   
                            (usually a random value or a nonce) that  
                            the claimant combines with a shared       
                            secret (often by hashing the challenge    
                            and secret together) to generate a        
                            response that is sent to the verifier.    
                            The verifier knows the shared secret and  
                            can independently compute the response    
                            and compare it with the response          
                            generated by the claimant. If the two are 
                            the same, the claimant is considered to   
                            have successfully authenticated himself.  
                            When the shared secret is a cryptographic 
                            key, such protocols are generally secure  
                            against eavesdroppers. When the shared    
                            secret is a password, an eavesdropper     
                            does not directly intercept the password  
                            itself, but the eavesdropper may be able  
                            to find the password with an off-line     
                            password guessing attack.                 

  Chief Information Officer Agency official responsible for:\         SP 800-53; FIPS
  (CIO)                     1) Providing advice and other assistance  200;\
                            to the head of the executive agency and   Public Law
                            other senior management personnel of the  104-106, Sec.
                            agency to ensure that information         5125(b)
                            technology is acquired and information    
                            resources are managed in a manner that is 
                            consistent with laws, executive orders,   
                            directives, policies, regulations, and    
                            priorities established by the head of the 
                            agency;\                                  
                            2) Developing, maintaining, and           
                            facilitating the implementation of a      
                            sound and integrated information          
                            technology architecture for the agency;   
                            and\                                      
                            3) Promoting the effective and efficient  
                            design and operation of all major         
                            information resources management          
                            processes for the agency, including       
                            improvements to work processes of the     
                            agency.                                   

  Chief Information         SEE Senior Agency Information Security     
  Security Officer          Officer.                                  

  Cipher                    Series of transformations that converts   FIPS 197
                            plaintext to ciphertext using the Cipher  
                            Key.                                      

  Cipher Block              A secret-key block-cipher algorithm used  SP 800-38C
  Chaining-Message          to encrypt data and to generate a Message 
  Authentication Code       Authentication Code (MAC) to provide      
  (CBC-MAC)                 assurance that the payload and the        
                            associated data are authentic.            

  Cipher Key                Secret, cryptographic key that is used by FIPS 197
                            the Key Expansion routine to generate a   
                            set of Round Keys; can be pictured as a   
                            rectangular array of bytes, having four   
                            rows and Nk columns.                      

  Cipher Suite              Negotiated algorithm identifiers. Cipher  SP 800-52
                            suites are identified in human readable   
                            form using a pneumonic code.              

  Ciphertext                Data output from the Cipher or input to   FIPS 197
                            the Inverse Cipher.                       

  Ciphertext                Data in its encrypted form.               SP 800-21 \[2nd
                                                                      Ed\]

  Claimant                  A party whose identity is to be verified  SP 800-63; FIPS
                            using an authentication protocol.         201

  Claimant                  An entity which is or represents a        FIPS 196
                            principal for the purposes of             
                            authentication, together with the         
                            functions involved in an authentication   
                            exchange on behalf of that entity. A      
                            claimant acting on behalf of a principal  
                            must include the functions necessary for  
                            engaging in an authentication exchange.   
                            (e.g., a smartcard (claimant) can act on  
                            behalf of a human user (principal))       

  Classified Information    Information that has been determined      SP 800-60; E.O.
                            pursuant to Executive Order (E.O.) 13292  13292
                            or any predecessor order to require       
                            protection against unauthorized           
                            disclosure and is marked to indicate its  
                            classified status when in documentary     
                            form.                                     

  Client (Application)      A system entity, usually a computer       SP 800-32
                            process acting on behalf of a human user, 
                            that makes use of a service provided by a 
                            server.                                   

  Clinger-Cohen Act of 1996 Also known as Information Technology      SP 800-64
                            Management Reform Act. A statute that     
                            substantially revised the way that IT     
                            resources are managed and procured,       
                            including a requirement that each agency  
                            design and implement a process for        
                            maximizing the value and assessing and    
                            managing the risks of IT investments.     

  Cold Site                 A backup facility that has the necessary  SP 800-34
                            electrical and physical components of a   
                            computer facility, but does not have the  
                            computer equipment in place. The site is  
                            ready to receive the necessary            
                            replacement computer equipment in the     
                            event that the user has to move from      
                            their main computing location to an       
                            alternate site.                           

  Collision                 Two or more distinct inputs produce the   SP 800-57
                            same output.                              

  Common Security Control   Security control that can be applied to   SP 800-53; FIPS
                            one or more agency information systems    200
                            and has the following properties:\        
                            1) the development, implementation, and   
                            assessment of the control can be assigned 
                            to a responsible official or              
                            organizational element (other than the    
                            information system owner); and\           
                            2) the results from the assessment of the 
                            control can be used to support the        
                            security certification and accreditation  
                            processes of an agency information system 
                            where that control has been applied.      

  Common Vulnerabilities    A dictionary of common names for publicly SP 800-51
  and Exposures (CVE)       known IT system vulnerabilities.          

  Comparison                The process of comparing a biometric with FIPS 201
                            a previously stored reference template or 
                            templates.                                

  Compensating Controls     The management, operational, and          FIPS 200
                            technical controls (i.e., safeguards or   
                            countermeasures) employed by an           
                            organization in lieu of the recommended   
                            controls in the low, moderate, or high    
                            security control baselines, that provide  
                            equivalent or comparable protection for   
                            an information system.                    

  Compensating Security     The management, operational, and          SP 800-53
  Controls                  technical controls (i.e., safeguards or   
                            countermeasures) employed by an           
                            organization in lieu of the recommended   
                            controls in the low, moderate, or high    
                            baselines described in NIST Special       
                            Publication 800-53, that provide          
                            equivalent or comparable protection for   
                            an information system.                    

  Compromise                Disclosure of information to unauthorized SP 800-32
                            persons, or a violation of the security   
                            policy of a system in which unauthorized  
                            intentional or unintentional disclosure,  
                            modification, destruction, or loss of an  
                            object may have occurred.                 

  Compromise                The unauthorized disclosure,              FIPS 140-2
                            modification, substitution or use of      
                            sensitive data (including plaintext       
                            cryptographic keys and other critical     
                            security parameters).                     

  Computer Forensics        The practice of gathering, retaining, and SP 800-61
                            analyzing computer-related data for       
                            investigative purposes in a manner that   
                            maintains the integrity of the data.      

  Computer Security         A violation or imminent threat of         SP 800-61
  Incident                  violation of computer security policies,  
                            acceptable use policies, or standard      
                            computer security practices.              

  Computer Security         A capability set up for the purpose of    SP 800-61
  Incident Response Team    assisting in responding to computer       
  (CSIRT)                   security-related incidents; also called a 
                            Computer Incident Response Team (CIRT) or 
                            a CIRC (Computer Incident Response        
                            Center, Computer Incident Response        
                            Capability).                              

  Computer Security Object  A resource, tool, or mechanism used to    FIPS 188
  (CSO)                     maintain a condition of security in a     
                            computerized environment. These objects   
                            are defined in terms of attributes they   
                            possess, operations they perform or are   
                            performed on them, and their relationship 
                            with other objects.                       

  Computer Security Objects A collection of Computer Security Object  FIPS 188
  Register                  names and definitions kept by a           
                            registration authority.                   

  Computer Virus            A computer virus is similar to a Trojan   SP 800-46
                            horse because it is a program that        
                            contains hidden code, which usually       
                            performs some unwanted function as a side 
                            effect. The main difference between a     
                            virus and a Trojan horse is that the      
                            hidden code in a computer virus can only  
                            replicate by attaching a copy of itself   
                            to other programs and may also include an 
                            additional \"payload\" that triggers when 
                            specific conditions are met.              

  Confidentiality           Preserving authorized restrictions on     SP 800-53; FIPS
                            information access and disclosure,        200;\
                            including means for protecting personal   FIPS 199; 44
                            privacy and proprietary information.      U.S.C., Sec. 3542

  Confidentiality           The property that sensitive information   FIPS 140-2
                            is not disclosed to unauthorized          
                            individuals, entities or processes.       

  Configuration Control     Process for controlling modifications to  SP 800-53;
                            hardware, firmware, software, and         CNSSI-4009
                            documentation to ensure the information   
                            system is protected against improper      
                            modifications prior to, during, and after 
                            system implementation.                    

  Contingency Plan          Management policy and procedures designed SP 800-34
                            to maintain or restore business           
                            operations, including computer            
                            operations, possibly at an alternate      
                            location, in the event of emergencies,    
                            system failures, or disaster.             

  Continuity of Operations  A predetermined set of instructions or    SP 800-34
  Plan (COOP)               procedures that describe how an           
                            organization's essential functions will   
                            be sustained for up to 30 days as a       
                            result of a disaster event before         
                            returning to normal operations.           

  Continuity of Support     The documentation of a predetermined set  SP 800-34
  Plan                      of instructions or procedures mandated by 
                            Office of Management and Budget (OMB)     
                            A-130 that describe how to sustain major  
                            applications and general support systems  
                            in the event of a significant disruption. 

  Control Information       Information that is entered into a        FIPS 140-2
                            cryptographic module for the purposes of  
                            directing the operation of the module.    

  Controlled Interface      Mechanism that facilitates the            SP 800-53; FIPS
                            adjudication of different interconnected  200; CNSSI-4009
                            system security policies (e.g.,           
                            controlling the flow of information into  
                            or out of an interconnected system).      

  Cookie                    A piece of information supplied by a web  SP 800-46
                            server to a browser, along with requested 
                            resource, for the browser to store        
                            temporarily and return to the server on   
                            any subsequent visits or requests.        

  Counter with Cipher Block A mode of operation for a symmetric key   SP 800-38C
  Chaining-Message          block cipher algorithm. It combines the   
  Authentication Code (CCM) techniques of the Counter (CTR) mode and  
                            the Cipher Block Chaining-Message         
                            Authentication Code (CBC-MAC) algorithm   
                            to provide assurance of the               
                            confidentiality and the authenticity of   
                            computer data.                            

  Countermeasures           Actions, devices, procedures, techniques, SP 800-53; FIPS
                            or other measures that reduce the         200; CNSSI-4009
                            vulnerability of an information system.   
                            Synonymous with security controls and     
                            safeguards.                               

  Credential                An object that authoritatively binds an   SP 800-63
                            identity (and optionally, additional      
                            attributes) to a token possessed and      
                            controlled by a person.                   

  Credential                Evidence attesting to one's right to      FIPS 201
                            credit or authority.                      

  Credentials Service       A trusted entity that issues or registers SP 800-63
  Provider (CSP)            subscriber tokens and issues electronic   
                            credentials to subscribers. The CSP may   
                            encompass Registration Authorities and    
                            verifiers that it operates. A CSP may be  
                            an independent third-party, or may issue  
                            credentials for its own use.              

  Critical Security         Security-related information (e.g.,       FIPS 140-2
  Parameter                 secret and private cryptographic keys,    
                            and authentication data such as passwords 
                            and Personal Identification Numbers       
                            (PINs)) whose disclosure or modification  
                            can compromise the security of a          
                            cryptographic module.                     

  Criticality Level         Refers to the (consequences of) incorrect SP 800-60
                            behavior of a system. The more serious    
                            the expected direct and indirect effects  
                            of incorrect behavior, the higher the     
                            criticality level.                        

  Cross-Certificate         A certificate used to establish a trust   SP 800-32
                            relationship between two Certification    
                            Authorities.                              

  Cryptanalysis             1\) Operations performed in defeating     SP 800-57
                            cryptographic protection without an       
                            initial knowledge of the key employed in  
                            providing the protection.\                
                            2) The study of mathematical techniques   
                            for attempting to defeat cryptographic    
                            techniques and information system         
                            security. This includes the process of    
                            looking for errors or weaknesses in the   
                            implementation of an algorithm or of the  
                            algorithm itself.                         

  Crypto Officer            An operator or process (subject), acting  FIPS 140-2
                            on behalf of the operator, performing     
                            cryptographic initialization or           
                            management functions.                     

  Cryptographic Algorithm   A well-defined computational procedure    SP 800-21 \[2nd
                            that takes variable inputs, including a   Ed\]
                            cryptographic key, and produces an        
                            output.                                   

  Cryptographic Boundary    An explicitly defined continuous          FIPS 140-2
                            perimeter that establishes the physical   
                            bounds of a cryptographic module and      
                            contains all the hardware, software,      
                            and/or firmware components of a           
                            cryptographic module.                     

  Cryptographic Hash        A function that maps a bit string of      SP 800-21 \[2nd
  Function                  arbitrary length to a fixed length bit    Ed\]
                            string.\                                  
                            Approved hash functions satisfy the       
                            following properties:\                    
                            1) (One-way) It is computationally        
                            infeasible to find any input which maps   
                            to any pre-specified output, and\         
                            2) (Collision resistant) It is            
                            computationally infeasible to find any    
                            two distinct inputs that map to the same  
                            output.                                   

  Cryptographic Key         A value used to control cryptographic     SP 800-63
                            operations, such as decryption,           
                            encryption, signature generation or       
                            signature verification.                   

  Cryptographic Key         A parameter used in conjunction with a    FIPS 201; FIPS 198
                            cryptographic algorithm that determines   
                            the specific operation of that algorithm. 

  Cryptographic Key         A parameter used in conjunction with a    FIPS 140-2
                            cryptographic algorithm that determines,  
                            the transformation of plaintext data into 
                            ciphertext data,the transformation of     
                            ciphertext data into plaintext data,a     
                            digital signature computed from data,the  
                            verification of a digital signature       
                            computed from data, an authentication     
                            code computed from data, or an exchange   
                            agreement of a shared secret.             

  Cryptographic Module      The set of hardware, software, firmware,  SP 800-32; FIPS
                            or some combination thereof that          196
                            implements cryptographic logic or         
                            processes, including cryptographic        
                            algorithms, and is contained within the   
                            cryptographic boundary of the module.     

  Cryptographic Module      The set of hardware, software, and/or     FIPS 140-2
                            firmware that implements Approved         
                            security functions (including             
                            cryptographic algorithms and key          
                            generation) and is contained within the   
                            cryptographic boundary.                   

  Cryptographic Module      A precise specification of the security   FIPS 140-2
  Security Policy           rules under which a cryptographic module  
                            will operate, including the rules derived 
                            from the requirements of this standard    
                            (FIPS 140-2) and additional rules imposed 
                            by the vendor.                            

  Cryptographic Module      Validates cryptographic modules to        FIPS 140-2
  Validation Program (CMVP) Federal Information Processing Standard   
                            (FIPS) 140-2 and other cryptography based 
                            standards. The CMVP is a joint effort     
                            between National Institute of Standards   
                            and Technology (NIST) and the             
                            Communications Security Establishment     
                            (CSE) of the Government of Canada.        
                            Products validated as conforming to FIPS  
                            140-2 are accepted by the Federal         
                            agencies of both countries for the        
                            protection of sensitive information       
                            (United States) or Designated Information 
                            (Canada). The goal of the CMVP is to      
                            promote the use of validated              
                            cryptographic modules and provide Federal 
                            agencies with a security metric to use in 
                            procuring equipment containing validated  
                            cryptographic modules.                    

  Cryptographic Strength    A measure of the expected number of       SP 800-63
                            operations required to defeat a           
                            cryptographic mechanism.                  

  Cryptographic Token       A token where the secret is a             SP 800-63
                            cryptographic key.                        

  Cryptography              The discipline that embodies the          SP 800-59; ANSDIT
                            principles, means, and methods for the    
                            transformation of data in order to hide   
                            their semantic content, prevent their     
                            unauthorized use, or prevent their        
                            undetected modification.                  

  Cryptography              The discipline that embodies principles,  SP 800-21 \[2nd
                            means and methods for providing           Ed\]
                            information security, including           
                            confidentiality, data integrity,          
                            non-repudiation, and authenticity.        

  Cryptography              Is categorized as either secret key or    FIPS 191
                            public key. Secret key cryptography is    
                            based on the use of a single              
                            cryptographic key shared between two      
                            parties . The same key is used to encrypt 
                            and decrypt data. This key is kept secret 
                            by the two parties. Public key            
                            cryptography is a form of cryptography    
                            which make use of two keys: a public key  
                            and a private key. The two keys are       
                            related but have the property that, given 
                            the public key, it is computationally     
                            infeasible to derive the private key      
                            \[FIPS 140-1\]. In a public key           
                            cryptosystem, each party has its own      
                            public/private key pair. The public key   
                            can be known by anyone; the private key   
                            is kept secret.                           

  Cryptology                The science that deals with hidden,       SP 800-60
                            disguised, or encrypted communications.   
                            It includes communications security and   
                            communications intelligence.              

  Cryptoperiod              Time span during which each key setting   SP 800-32
                            remains in effect.                        

  CVE                       SEE Common Vulnerabilities and Exposures.  

  Cyclical Redundancy Check A method to ensure data has not been      SP 800-72
  (CRC)                     altered after being sent through a        
                            communication channel.                    

  []{#GD .anchor}DAA        SEE Designated Approving/Accrediting       
                            Authority                                 

  Data Element              A basic unit of information that has a    SP 800-47
                            unique meaning and subcategories (data    
                            items) of distinct value. Examples of     
                            data elements include gender, race, and   
                            geographic location.                      

  Data Encryption Algorithm The cryptographic engine that is used by  SP 800-67
  (DEA)                     the Triple Data Encryption Algorithm      
                            (TDEA).                                   

  Data Encryption Standard  A U.S. Government-approved, symmetric     SP 800-46
  (DES)                     cipher, encryption algorithm used by      
                            business and civilian government          
                            agencies. The Advanced Encryption         
                            Standard (AES) is designed to replace     
                            DES. The original "single" DES algorithm  
                            is no longer secure because it is now     
                            possible to try every possible key with   
                            special purpose equipment or a high       
                            performance cluster. Triple DES (see      
                            glossary entry below), however, is still  
                            considered to be secure.                  

  Data Integrity            The property that data has not been       SP 800-27A
                            altered in an unauthorized manner. Data   
                            integrity covers data in storage, during  
                            processing, and while in transit.         

  Decryption                The process of transforming ciphertext    SP 800-67
                            into plaintext.                           

  Decryption                The process of changing ciphertext into   SP 800-21 \[2nd
                            plaintext using a cryptographic algorithm Ed\]
                            and key.                                  

  Decryption                Conversion of ciphertext to plaintext     FIPS 185
                            through the use of a cryptographic        
                            algorithm.                                

  Deleted File              A file that has been logically, but not   SP 800-72
                            necessarily physically, erased from the   
                            operating system, perhaps to eliminate    
                            potentially incriminating evidence.       
                            Deleting files does not always            
                            necessarily eliminate the possibility of  
                            recovering all or part of the original    
                            data.                                     

  Demilitarized Zone (DMZ)  A network created by connecting two       SP 800-41
                            firewalls. Systems that are externally    
                            accessible but need some protections are  
                            usually located on DMZ networks.          

  Denial of Service (DoS)   The prevention of authorized access to    SP 800-27A
                            resources or the delaying of              
                            time-critical operations. (Time-critical  
                            may be milliseconds or it may be hours,   
                            depending upon the service provided.)     

  Designated                The individual selected by an authorizing SP 800-37
  Approving/Accrediting     official to act on their behalf in        
  Authority (DAA)           coordinating and carrying out the         
                            necessary activities required during the  
                            security certification and accreditation  
                            of an information system. Also see        
                            authorizing official.                     

  Differential Power        An analysis of the variations of the      FIPS 140-2
  Analysis (DPA)            electrical power consumption of a         
                            cryptographic module, using advanced      
                            statistical methods and/or other          
                            techniques, for the purpose of extracting 
                            information correlated to cryptographic   
                            keys used in a cryptographic algorithm.   

  Digital Evidence          Electronic information stored or          SP 800-72
                            transferred in digital form.              

  Digital Signature         An asymmetric key operation where the     SP 800-63
                            private key is used to digitally sign an  
                            electronic document and the public key is 
                            used to verify the signature. Digital     
                            signatures provide authentication and     
                            integrity protection.                     

  Digital Signature         A nonforgeable transformation of data     FIPS 196
                            that allows the proof of the source (with 
                            nonrepudiation) and the verification of   
                            the integrity of that data.               

  Digital Signature         The result of a cryptographic             FIPS 140-2
                            transformation of data which, when        
                            properly implemented, provides the        
                            services of: 1. origin authentication 2.  
                            data integrity, and 3. signer             
                            non-repudiation.                          

  Digital Signature         Asymmetric algorithms used for digitally  SP 800-49
  Algorithm                 signing data.                             

  Disaster Recovery Plan    A written plan for processing critical    SP 800-34
  (DRP)                     applications in the event of a major      
                            hardware or software failure or           
                            destruction of facilities.                

  Disconnection             The termination of an interconnection     SP 800-47
                            between two or more IT systems. A         
                            disconnection may be planned (e.g., due   
                            to changed business needs) or unplanned   
                            (i.e., due to an attack or other          
                            contingency).                             

  Discretionary Access      The basis of this kind of security is     FIPS 191
  Control                   that an individual user, or program       
                            operating on the user's behalf is allowed 
                            to specify explicitly the types of access 
                            other users (or programs executing on     
                            their behalf) may have to information     
                            under the user's control.                 

  Disruption                An unplanned event that causes the        SP 800-34
                            general system or major application to be 
                            inoperable for an unacceptable length of  
                            time (e.g., minor or extended power       
                            outage, extended unavailable network, or  
                            equipment or facility damage or           
                            destruction).                             

  Distinguishing Identifier Information which unambiguously           FIPS 196
                            distinguishes an entity in the            
                            authentication process.                   

  Distributed Denial of     A Denial of Service technique that uses   SP 800-61
  Service (DDoS)            numerous hosts to perform the attack.     

  DMZ                       SEE Demilitarized Zone.                    

  Domain                    A set of subjects, their information      SP 800-27A
                            objects, and a common security policy.    

  Dual-Use Certificate      A certificate that is intended for use    SP 800-32
                            with both digital signature and data      
                            encryption services.                      

  Due Care                  The responsibility that managers and      SP 800-30
                            their organizations have a duty to        
                            provide for information security to       
                            ensure that the type of control, the cost 
                            of control, and the deployment of control 
                            are appropriate for the system being      
                            managed.                                  

  Duplicate Digital         A duplicate is an accurate digital        SP 800-72
  Evidence                  reproduction of all data objects          
                            contained on the original physical item   
                            and associated media.                     

  Duration                  A field within a certificate that is      SP 800-32
                            composed of two subfields; "date of       
                            issue" and "date of next issue".          

  Dynamic Host              The protocol used to assign Internet      SP 800-48
  Configuration Protocol    Protocol (IP) addresses to all nodes on   
  (DHCP)                    the network.                              

  []{#GE .anchor}Easter Egg Hidden functionality within an            SP 800-28
                            application program, which becomes        
                            activated when an undocumented, and often 
                            convoluted, set of commands and           
                            keystrokes are entered. Easter eggs are   
                            typically used to display the credits for 
                            the development team and are intended to  
                            be non-threatening.                       

  Education (Information    Education integrates all of the security  SP 800-50
  Security)                 skills and competencies of the various    
                            functional specialties into a common body 
                            of knowledge . . . and strives to produce 
                            IT security specialists and professionals 
                            capable of vision and pro-active          
                            response.                                 

  Egress Filtering          The process of blocking outgoing packets  SP 800-61
                            that use obviously false Internet         
                            Protocol (IP) addresses, such as source   
                            addresses from internal networks.         

  Electronic Authentication The process of establishing confidence in SP 800-63
  (E-authentication)        user identities electronically presented  
                            to an information system.                 

  Electronic Credentials    Digital documents used in authentication  SP 800-63
                            that bind an identity or an attribute to  
                            a subscriber\'s token.                    

  Electronic Evidence       Information and data of investigative     SP 800-72
                            value that is stored on or transmitted by 
                            an electronic device.                     

  Electronic Key Entry      The entry of cryptographic keys into a    FIPS 140-2
                            cryptographic module using electronic     
                            methods such as a smart card or a         
                            key-loading device. (The operator of the  
                            key may have no knowledge of the value of 
                            the key being entered.)                   

  Encrypted Key             A cryptographic key that has been         FIPS 140-2
                            encrypted using an Approved security      
                            function with a key encrypting key, a     
                            PIN, or a password in order to disguise   
                            the value of the underlying plaintext     
                            key.                                      

  Encrypted Network         A network on which messages are encrypted SP 800-32
                            (e.g. using DES, AES, or other            
                            appropriate algorithms) to prevent        
                            reading by unauthorized parties.          

  Encryption                Encryption is the conversion of data into SP 800-46
                            a form, called a ciphertext, which cannot 
                            be easily understood by unauthorized      
                            people.                                   

  Encryption                Conversion of plaintext to ciphertext     FIPS 185
                            through the use of a cryptographic        
                            algorithm.                                

  Encryption                The process of changing plaintext into    SP 800-21 \[2nd
                            ciphertext for the purpose of security or Ed\]
                            privacy.                                  

  Encryption Certificate    A certificate containing a public key     SP 800-32
                            that is used to encrypt electronic        
                            messages, files, documents, or data       
                            transmissions, or to establish or         
                            exchange a session key for these same     
                            purposes.                                 

  End to End Encryption     Communications encryption in which data   SP 800-12
                            is encrypted when being passed through a  
                            network, but routing information remains  
                            visible.                                  

  Entity                    Either a subject (an active element that  SP 800-27A
                            operates on information or the system     
                            state) or an object (a passive element    
                            that contains or receives information).   

  Entity                    An active element in an open system.      FIPS 188

  Entity                    Any participant in an authentication      FIPS 196
                            exchange; such a participant may be human 
                            or nonhuman, and may take the role of a   
                            claimant and/or verifier.                 

  Entropy                   A measure of the amount of uncertainty    SP 800-63
                            that an attacker faces to determine the   
                            value of a secret.                        

  Environment               Aggregate of external procedures,         FIPS 200;
                            conditions, and objects affecting the     CNSSI-4009
                            development, operation, and maintenance   
                            of an information system.                 

  Ephemeral Keys            Short-lived cryptographic keys that are   SP 800-57
                            statistically unique to each execution of 
                            a key establishment process and meets     
                            other requirements of the key type (e.g., 
                            unique to each message or session).       

  Error Detection Code      A code computed from data and comprised   FIPS 140-2
                            of redundant bits of information designed 
                            to detect, but not correct, unintentional 
                            changes in the data.                      

  Escrow                    Something (e.g., a document, an           FIPS 185
                            encryption key) that is \"delivered to a  
                            third person to be given to the grantee   
                            only upon the fulfillment of a            
                            condition.\"                              

  Event                     Any observable occurrence in a network or SP 800-61
                            system.                                   

  Examination               A technical review that makes the         SP 800-72
                            evidence visible and suitable for         
                            analysis; tests performed on the evidence 
                            to determine the presence or absence of   
                            specific data.                            

  Exculpatory Evidence      Evidence that tends to decrease the       SP 800-72
                            likelihood of fault or guilt.             

  Executive Agency          An executive department specified in 5    SP 800-53; FIPS
                            United States Code (U.S.C.), Sec. 101; a  200; FIPS 199; 41
                            military department specified in 5        U.S.C., Sec. 403
                            U.S.C., Sec. 102; an independent          
                            establishment as defined in 5 U.S.C.,     
                            Sec. 104(1); and a wholly owned           
                            Government corporation fully subject to   
                            the provisions of 31 U.S.C., Chapter 91.  

  Exploit Code              A program that allows attackers to        SP 800-40 Ver 2
                            automatically break into a system.        

  []{#GF .anchor}False      When a biometric system incorrectly       FIPS 201
  Acceptance                identifies an individual or incorrectly   
                            verifies an impostor against a claimed    
                            identity                                  

  False Acceptance Rate     The probability that a biometric system   FIPS 201
                            will incorrectly identify an individual   
                            or will fail to reject an impostor. The   
                            rate given normally assumes passive       
                            impostor attempts.                        

  False Match Rate (FMR)    Alternative to 'False Acceptance Rate'.   FIPS 201
                            Used to avoid confusion in applications   
                            that reject the claimant if their         
                            biometric data matches that of an         
                            applicant.                                

  False Non Match Rate      Alternative to 'False Rejection Rate'.    FIPS 201
  (FNMR)                    Used to avoid confusion in applications   
                            that reject the claimant if their         
                            biometric data matches that of an         
                            applicant.                                

  False Positive            An alert that incorrectly indicates that  SP 800-61
                            malicious activity is occurring.          

  False Rejection           When a biometric system fails to identify FIPS 201
                            an applicant or fails to verify the       
                            legitimate claimed identity of an         
                            applicant.                                

  False Rejection Rate      The probability that a biometric system   FIPS 201
  (FRR)                     will fail to identify an applicant, or    
                            verify the legitimate claimed identity of 
                            an applicant.                             

  Federal Agency            SEE Agency.                                

  Federal Bridge            The Federal Bridge Certification          SP 800-32
  Certification Authority   Authority consists of a collection of     
  (FBCA)                    Public Key Infrastructure components      
                            (Certificate Authorities, Directories,    
                            Certificate Policies and Certificate      
                            Practice Statements) that are used to     
                            provide peer-to-peer interoperability     
                            among Agency Principal Certification      
                            Authorities.                              

  Federal Bridge            The Federal Bridge Certification          SP 800-32
  Certification Authority   Authority Membrane consists of a          
  Membrane                  collection of Public Key Infrastructure   
                            components including a variety of         
                            Certification Authority PKI products,     
                            Databases, CA specific Directories,       
                            Border Directory, Firewalls, Routers,     
                            Randomizers, etc.                         

  Federal Bridge            The Federal Bridge Certification          SP 800-32
  Certification Authority   Authority Operational Authority is the    
  Operational Authority     organization selected by the Federal      
                            Public Key Infrastructure Policy          
                            Authority to be responsible for operating 
                            the Federal Bridge Certification          
                            Authority.                                

  Federal Information       A standard for adoption and use by        FIPS 201
  Processing Standard       Federal agencies that has been developed  
  (FIPS)                    within the Information Technology         
                            Laboratory and published by the National  
                            Institute of Standards and Technology, a  
                            part of the U.S. Department of Commerce.  
                            A FIPS covers some topic in information   
                            technology in order to achieve a common   
                            level of quality or some level of         
                            interoperability.                         

  Federal Information       An information system used or operated by SP 800-53; FIPS
  System                    an executive agency, by a contractor of   200; FIPS 199; 40
                            an executive agency, or by another        U.S.C., Sec. 11331
                            organization on behalf of an executive    
                            agency.                                   

  Federal Information       An organization whose members come from   SP 800-16
  Systems Security          federal agencies, industry, and academic  
  Educators' Association    institutions devoted to improving the IT  
  (FISSEA)                  security awareness and knowledge within   
                            the federal government and its related    
                            external workforce.                       

  Federal Public Key        The Federal PKI Policy Authority is a     SP 800-32
  Infrastructure Policy     federal government body responsible for   
  Authority (FPKI PA)       setting, implementing, and administering  
                            policy decisions regarding interagency    
                            PKI interoperability that uses the FBCA.  

  File Infector Virus       A virus that attaches itself to a program SP 800-61
                            file, such as a word processor,           
                            spreadsheet application, or game.         

  File Integrity Checker    Software that generates, stores, and      SP 800-61
                            compares message digests for files to     
                            detect changes to the files.              

  File Name Anomaly         1\) A mismatch between the internal file  SP 800-72
                            header and its external extension;\       
                            2) A file name inconsistent with the      
                            content of the file (e.g., renaming a     
                            graphics file with a non-graphical        
                            extension.                                

  FIPS                      SEE Federal Information Processing         
                            Standard                                  

  FIPS Approved Security    A security method (e.g., cryptographic    FIPS 196
  Method                    algorithm, cryptographic key generation   
                            algorithm or key distribution technique,  
                            random number generator, authentication   
                            technique, or evaluation criteria) that   
                            is either a) specified in a FIPS, or b)   
                            adopted in a FIPS.                        

  FIPS PUB                  An acronym for Federal Information        SP 800-64
                            Processing Standards Publication. FIPS    
                            publications (PUB) are issued by NIST     
                            after approval by the Secretary of        
                            Commerce.                                 

  Firewall                  A gateway that limits access between      SP 800-32
                            networks in accordance with local         
                            security policy.                          

  Firewall Control Proxy    The component that controls a firewall's  SP 800-58
                            handling of a call. The firewall control  
                            proxy can instruct the firewall to open   
                            specific ports that are needed by a call, 
                            and direct the firewall to close these    
                            ports at call termination.                

  Firewall Environment      A firewall environment is a collection of SP 800-41
                            systems at a point on a network that      
                            together constitute a firewall            
                            implementation. A firewall environment    
                            could consist of one device or many       
                            devices such as several firewalls,        
                            intrusion detection systems, and proxy    
                            servers.                                  

  Firewall Platform         A firewall platform is the system device  SP 800-41
                            upon which a firewall is implemented. An  
                            example of a firewall platform is a       
                            commercial operating system running on a  
                            personal computer.                        

  Firewall Ruleset          A firewall ruleset is a table of          SP 800-41
                            instructions that the firewall uses for   
                            determining how packets should be routed  
                            between its interfaces. In routers, the   
                            ruleset can be a file that the router     
                            examines from top to bottom when making   
                            routing decisions.                        

  Firmware                  The programs and data components of a     FIPS 140-2
                            cryptographic module that are stored in   
                            hardware within the cryptographic         
                            boundary and cannot be dynamically        
                            written or modified during execution.     

  FISMA                     Federal Information Security Management   SP 800-65
                            Act - requires agencies to integrate IT   
                            security into their capital planning and  
                            enterprise architecture processes at the  
                            agency, conduct annual IT security        
                            reviews of all programs and systems, and  
                            report the results of those reviews to    
                            the Office of Management and Budget       
                            (OMB).                                    

  Forensic Copy             An accurate bit-for-bit reproduction of   SP 800-72
                            the information contained on an           
                            electronic device or associated media,    
                            whose validity and integrity has been     
                            verified using an accepted algorithm.     

  Forensic Specialist       A professional who locates, identifies,   SP 800-72
                            collects, analyzes and examines data      
                            while preserving the integrity and        
                            maintaining a strict chain of custody of  
                            information discovered.                   

  Forensics, Computer       The practice of gathering, retaining, and SP 800-61
                            analyzing computer-related data for       
                            investigative purposes in a manner that   
                            maintains the integrity of the data.      

  Formatting Function       The function that transforms the payload, SP 800-38C
                            associated data, and nonce into a         
                            sequence of complete blocks.              

  Forward Cipher            One of the two functions of the block     SP 800-67
                            cipher algorithm that is determined by    
                            the choice of a cryptographic key.        

  []{#GG .anchor}General    An interconnected set of information      SP 800-53; OMB
  Support System            resources under the same direct           Circular A-130,
                            management control that shares common     App. III
                            functionality. It normally includes       
                            hardware, software, information, data,    
                            applications, communications, and people. 

  Graduated Security        A security system that provides several   FIPS 201
                            levels (e.g., low, moderate, high) of     
                            protection based on threats, risks,       
                            available technology, support services,   
                            time, human concerns, and economics.      

  Guard (System)            A mechanism limiting the exchange of      SP 800-53 Rev 1;
                            information between information systems   CNSSI-4009 Adapted
                            or subsystems.                            

  Guessing Entropy          A measure of the difficulty that an       SP 800-63
                            attacker has to guess the average         
                            password used in a system. In this        
                            document, entropy is stated in bits. When 
                            a password has n-bits of guessing entropy 
                            then an attacker has as much difficulty   
                            guessing the average password as in       
                            guessing an n-bit random quantity. The    
                            attacker is assumed to know the actual    
                            password frequency distribution.          

  []{#GH .anchor}Handler    A type of program used in DDoS attacks to SP 800-61
                            control agents distributed throughout a   
                            network. Also refers to an incident       
                            handler, which refers to a person who     
                            performs incident response work.          

  Hash Function             A function that maps a bit string of      SP 800-63; FIPS
                            arbitrary length to a fixed length bit    201
                            string.\                                  
                            Approved hash functions satisfy the       
                            following properties:\                    
                            1) One-Way. It is computationally         
                            infeasible to find any input that maps to 
                            any pre-specified output.\                
                            2) Collision Resistant. It is             
                            computationally infeasible to find any    
                            two distinct inputs that map to the same  
                            output.                                   

  Hash Function             An Approved mathematical function that    FIPS 198
                            maps a string of arbitrary length (up to  
                            a pre-determined maximum size) to a fixed 
                            length string. It may be used to produce  
                            a checksum, called a hash value or        
                            message digest, for a potentially long    
                            string or message.                        

  Hash-based Message        A symmetric key authentication method     SP 800-63
  Authentication Code       using hash functions.                     
  (HMAC)                                                              

  Hash-based Message        A message authentication code that uses a FIPS 201
  Authentication Code       cryptographic key in conjunction with a   
  (HMAC)                    hash function.                            

  Hash-based Message        A message authentication code that        FIPS 140-2
  Authentication Code       utilizes a keyed hash.                    
  (HMAC)                                                              

  Hashing                   The process of using a mathematical       SP 800-72
                            algorithm against data to produce a       
                            numeric value that is representative of   
                            that data.                                

  High Assurance Guard      An enclave boundary protection device     SP 800-32
  (HAG)                     that controls access between a local area 
                            network that an enterprise system has a   
                            requirement to protect, and an external   
                            network that is outside the control of    
                            the enterprise system, with a high degree 
                            of assurance.                             

  High Impact System        An information system in which at least   SP 800-53; FIPS
                            one security objective (i.e.,             200
                            confidentiality, integrity, or            
                            availability) is assigned a FIPS 199      
                            potential impact value of high.           

  Honeypot                  A host that is designed to collect data   SP 800-61
                            on suspicious activity and has no         
                            authorized users other than its           
                            administrators.                           

  Hot Site                  A fully operational off-site data         SP 800-34
                            processing facility equipped with         
                            hardware and system software to be used   
                            in the event of a disaster.               

  []{#GI                    The process of verifying the identity of  SP 800-47
  .anchor}Identification    a user, process, or device, usually as a  
                            prerequisite for granting access to       
                            resources in an IT system.                

  Identification            The process of discovering the true       FIPS 201
                            identity (i.e., origin, initial history)  
                            of a person or item from the entire       
                            collection of similar persons or items.   

  Identifier                A unique data string used as a key in the FIPS 201
                            biometric system to name a person's       
                            identity and its associated attributes.   

  Identity                  A unique name of an individual person.    SP 800-63
                            Since the legal names of persons are not  
                            necessarily unique, the identity of a     
                            person must include sufficient additional 
                            information to make the complete name     
                            unique.                                   

  Identity                  The set of physical and behavioral        FIPS 201
                            characteristics by which an individual is 
                            uniquely recognizable.                    

  Identity-Based Security   A security policy based on the identities SP 800-33
  Policy                    and/or attributes of the object (system   
                            resource) being accessed and of the       
                            subject (user, group of users, process,   
                            or device) requesting access.             

  Identity Binding          Binding of the vetted claimed identity to FIPS 201
                            the individual (through biometrics)       
                            according to the issuing authority.       

  Identity Proofing         The process by which a Credentials        SP 800-63
                            Service Provider (CSP) and a Registration 
                            Authority (RA) validate sufficient        
                            information to uniquely identify a        
                            person.                                   

  Identity Proofing         The process of providing sufficient       FIPS 201
                            information (e.g., identity history,      
                            credentials, documents) to a Personal     
                            Identity Verification Registrar when      
                            attempting to establish an identity.      

  Identity Registration     The process of making a person's identity FIPS 201
                            known to the Personal Identity            
                            Verification (PIV) system, associating a  
                            unique identifier with that identity, and 
                            collecting and recording the person's     
                            relevant attributes into the system.      

  Identity Verification     The process of affirming that a claimed   FIPS 201
                            identity is correct by comparing the      
                            offered claims of identity with           
                            previously proven information stored in   
                            the identity card or PIV system.          

  Identity Verification     The process of confirming or denying that SP 800-79
                            a claimed identity is correct by          
                            comparing the credentials (something you  
                            know, something you have, something you   
                            are) of a person requesting access with   
                            those previously proven and stored in the 
                            PIV Card or system and associated with    
                            the identity being claimed.               

  IDS                       SEE Intrusion Detection System             

  IDS - Host-Based          IDSs which operate on information         SP 800-36
                            collected from within an individual       
                            computer system. This vantage point       
                            allows host-based IDSs to determine       
                            exactly which processes and user accounts 
                            are involved in a particular attack on    
                            the Operating System. Furthermore, unlike 
                            network-based IDSs, host-based IDSs can   
                            more readily "see" the intended outcome   
                            of an attempted attack, because they can  
                            directly access and monitor the data      
                            files and system processes usually        
                            targeted by attacks.                      

  IDS - Network-Based       IDSs which detect attacks by capturing    SP 800-36
                            and analyzing network packets. Listening  
                            on a network segment or switch, one       
                            network-based IDS can monitor the network 
                            traffic affecting multiple hosts that are 
                            connected to the network segment.         

  Image                     An exact bit-stream copy of all           SP 800-72
                            electronic data on a device, performed in 
                            a manner that ensures the information is  
                            not altered.                              

  Impact                    The magnitude of harm that can be         SP 800-60
                            expected to result from the consequences  
                            of unauthorized disclosure of             
                            information, unauthorized modification of 
                            information, unauthorized destruction of  
                            information, or loss of information or    
                            information system availability.          

  Inappropriate Usage       A person who violates acceptable          SP 800-61
                            computing use policies.                   

  Incident                  A violation or imminent threat of         SP 800-61
                            violation of computer security policies,  
                            acceptable use policies, or standard      
                            computer security practices.              

  Incident                  An occurrence that actually or            FIPS 200
                            potentially jeopardizes the               
                            confidentiality, integrity, or            
                            availability of an information system or  
                            the information the system processes,     
                            stores, or transmits or that constitutes  
                            a violation or imminent threat of         
                            violation of security policies, security  
                            procedures, or acceptable use policies.   

  Incident Handling         The mitigation of violations of security  SP 800-61
                            policies and recommended practices.       

  Incident Response Plan    The documentation of a predetermined set  SP 800-34
                            of instructions or procedures to detect,  
                            respond to, and limit consequences of a   
                            malicious cyber attacks against an        
                            organization's IT systems(s).             

  Inculpatory Evidence      Evidence that tends to increase the       SP 800-72
                            likelihood of fault or guilt.             

  Indication                A sign that an incident may have occurred SP 800-61
                            or may be currently occurring.            

  Individual                A citizen of the United States or an      SP 800-60
                            alien lawfully admitted for permanent     
                            residence. Agencies may, consistent with  
                            individual practice, choose to extend the 
                            protections of the Privacy Act and        
                            E-Government Act to businesses, sole      
                            proprietors, aliens, etc.                 

  Information               An instance of an information type.       FIPS 200

  Information Assurance     Measures that protect and defend          SP 800-59;
                            information and information systems by    CNSSI-4009
                            ensuring their availability, integrity,   
                            authentication, confidentiality, and      
                            non-repudiation. These measures include   
                            providing for restoration of information  
                            systems by incorporating protection,      
                            detection, and reaction capabilities.     

  Information in            is information in an IT system or online  OMB M-03-22
  identifiable form-        collection: (i) that directly identifies  
                            an individual (e.g., name, address,       
                            social security number or other           
                            identifying number or code, telephone     
                            number, email address, etc.) or (ii) by   
                            which an agency intends to identify       
                            specific individuals in conjunction with  
                            other data elements, i.e., indirect       
                            identification. (These data elements may  
                            include a combination of gender, race,    
                            birth date, geographic indicator, and     
                            other descriptors).                       

  Information Owner         Official with statutory or operational    SP 800-53;
                            authority for specified information and   CNSSI-4009
                            responsibility for establishing the       
                            controls for its generation, collection,  
                            processing, dissemination, and disposal.  

  Information Resources     Information and related resources, such   SP 800-53; 44
                            as personnel, equipment, funds, and       U.S.C., Sec. 3502
                            information technology.                   

  Information Resources     Information and related resources, such   FIPS 200; FIPS 199
                            as personnel, equipment, funds, and       
                            information technology.                   

  Information Security      The protection of information and         SP 800-53; FIPS
                            information systems from unauthorized     200; FIPS 199; 44
                            access, use, disclosure, disruption,      U.S.C., Sec. 3542
                            modification, or destruction in order to  
                            provide confidentiality, integrity, and   
                            availability.                             

  Information Security      Protecting information and information    SP 800-66; 44
                            systems from unauthorized access, use,    U.S.C., Sec 3541
                            disclosure, disruption, modification, or  
                            destruction in order to provide\          
                            1) integrity, which means guarding        
                            against improper information modification 
                            or destruction, and includes ensuring     
                            information nonrepudiation and            
                            authenticity;\                            
                            2) confidentiality, which means           
                            preserving authorized restrictions on     
                            access and disclosure, including means    
                            for protecting personal privacy and       
                            proprietary information; and\             
                            3) availability, which means ensuring     
                            timely and reliable access to and use of  
                            information.                              

  Information Security      Aggregate of directives, regulations,     SP 800-53;
  Policy                    rules, and practices that prescribes how  CNSSI-4009
                            an organization manages, protects, and    
                            distributes information.                  

  Information Sharing       The requirements for information sharing  SP 800-16
                            by an IT system with one or more other IT 
                            systems or applications, for information  
                            sharing to support multiple internal or   
                            external organizations, missions, or      
                            public programs.                          

  Information System        A discrete set of information resources   SP 800-53; FIPS
                            organized for the collection, processing, 200; FIPS 199; 44
                            maintenance, use, sharing, dissemination, U.S.C., Sec. 3502;
                            or disposition of information. Within     OMB Circular
                            DOI, this definition is further expounded A-130, App. III
                            upon to read: as defined by FISMA, any    
                            equipment or interconnected system or     
                            subsystems of equipment that is used in   
                            the automatic acquisition, storage,       
                            manipulation, management, movement,       
                            control, display, switching, interchange, 
                            transmission, or reception of data or     
                            information, and includes computers and   
                            computers networks; ancillary equipment;  
                            software, firmware, and related           
                            procedures; services, including           
                            supporting services; and related          
                            resources.                                

  Information System Owner  Official responsible for the overall      SP 800-53;
  (or Program Manager)      procurement, development, integration,    CNSSI-4009 Adapted
                            modification, or operation and            
                            maintenance of an information system.     

  Information System Owner  Official responsible for the overall      FIPS 200;
                            procurement, development, integration,    CNSSI-4009 Adapted
                            modification, or operation and            
                            maintenance of an information system.     

  Information System        Individual assigned responsibility by the SP 800-53;
  Security Officer (ISSO)   senior agency information security        CNSSI-4009 Adapted
                            officer, authorizing official, management 
                            official, or information system owner for 
                            ensuring the appropriate operational      
                            security posture is maintained for an     
                            information system or program.            

  Information Technology    Any equipment or interconnected system or SP 800-53; FIPS
                            subsystem of equipment that is used in    200; FIPS 199; 40
                            the automatic acquisition, storage,       U.S.C., Sec. 11101
                            manipulation, management, movement,       
                            control, display, switching, interchange, 
                            transmission, or reception of data or     
                            information by the executive agency. For  
                            purposes of the preceding sentence,       
                            equipment is used by an executive agency  
                            if the equipment is used by the executive 
                            agency directly or is used by a           
                            contractor under a contract with the      
                            executive agency which--- 1) requires the 
                            use of such equipment; or 2) requires the 
                            use, to a significant extent, of such     
                            equipment in the performance of a service 
                            or the furnishing of a product. The term  
                            information technology includes           
                            computers, ancillary equipment, software, 
                            firmware and similar procedures, services 
                            (including support services), and related 
                            resources.                                

  Information Type          A specific category of information (e.g., SP 800-53; FIPS
                            privacy, medical, proprietary, financial, 200; FIPS 199
                            investigative, contractor sensitive,      
                            security management), defined by an       
                            organization or in some instances, by a   
                            specific law, executive order, directive, 
                            policy, or regulation.                    

  Ingress Filtering         The process of blocking incoming packets  SP 800-61
                            that use obviously false IP addresses,    
                            such as reserved source addresses.        

  Initialization Vector     A vector used in defining the starting    SP 800-57; FIPS
  (IV)                      point of an encryption process within a   140-2
                            cryptographic algorithm.                  

  Initiator                 The entity that initiates an              FIPS 196
                            authentication exchange.                  

  Inside Threat             An entity with authorized access that has SP 800-32
                            the potential to harm an information      
                            system through destruction, disclosure,   
                            modification of data, and/or denial of    
                            service.                                  

  Integrity                 Guarding against improper information     SP 800-53; FIPS
                            modification or destruction, and includes 200; FIPS 199; 44
                            ensuring information non-repudiation and  U.S.C., Sec. 3542
                            authenticity.                             

  Integrity                 The property that sensitive data has not  FIPS 140-2
                            been modified or deleted in an            
                            unauthorized and undetected manner.       

  Intellectual Property     Useful artistic, technical, and/or        SP 800-32
                            industrial information, knowledge or      
                            ideas that convey ownership and control   
                            of tangible or virtual usage and/or       
                            representation.                           

  Interconnection, System   SEE System Interconnection                 

  Interconnection Security  An agreement established between the      SP 800-47
  Agreement (ISA)           organizations that own and operate        
                            connected IT systems to document the      
                            technical requirements of the             
                            interconnection. The ISA also supports a  
                            Memorandum of Understanding or Agreement  
                            (MOU/A) between the organizations.        

  Intermediate              A Certification Authority that is         SP 800-32
  Certification Authority   subordinate to another CA, and has a CA   
  (CA)                      subordinate to itself.                    

  Interoperability          In FIPS 201, interoperability allows any  FIPS 201
                            Government facility or information        
                            system, regardless of the cardholder's    
                            parent organization, to authenticate      
                            cardholder's identity using the           
                            credentials stored on the Personal        
                            Identity Verification (PIV) card.         

  Intrusion Detection       Software that looks for suspicious        SP 800-61
  System (IDS)              activity and alerts administrators.       

  Intrusion Prevention      Systems which can detect an intrusive     SP 800-36
  Systems                   activity and can also attempt to stop the 
                            activity, ideally before it reaches its   
                            targets.                                  

  Inverse Cipher            Series of transformations that converts   FIPS 197
                            ciphertext to plaintext using the Cipher  
                            Key.                                      

  IP Address                An IP address is a unique number for a    SP 800-46
                            computer that is used to determine where  
                            messages transmitted on the Internet      
                            should be delivered. The IP address is    
                            analogous to a house number for ordinary  
                            postal mail.                              

  IP Security (IPsec)       An Institute of Electrical and Electronic SP 800-46
                            Engineers (IEEE) standard, Request For    
                            Comments (RFC) 2411, protocol that        
                            provides security capabilities at the     
                            Internet Protocol (IP) layer of           
                            communications. IPsec's key management    
                            protocol is used to negotiate the secret  
                            keys that protect Virtual Private Network 
                            (VPN) communications, and the level and   
                            type of security protections that will    
                            characterize the VPN. The most widely     
                            used key management protocol is the       
                            Internet Key Exchange (IKE) protocol.     

  IT-Related Risk           The net mission/business impact           SP 800-27A
                            considering\                              
                            1) the likelihood that a particular       
                            threat source will exploit, or trigger, a 
                            particular information system             
                            vulnerability, and\                       
                            2) the resulting impact if this should    
                            occur. IT-related risks arise from legal  
                            liability or mission/business loss due    
                            to, but not limited to: Unauthorized      
                            (malicious, non-malicious, or accidental) 
                            disclosure, modification, or destruction  
                            of information. Non-malicious errors and  
                            omissions. IT disruptions due to natural  
                            or man-made disasters. Failure to         
                            exercise due care and diligence in the    
                            implementation and operation of the IT.   

  IT Security Architecture  A description of security principles and  SP 800-27A
                            an overall approach for complying with    
                            the principles that drive the system      
                            design; i.e., guidelines on the placement 
                            and implementation of specific security   
                            services within various distributed       
                            computing environments.                   

  IT Security Awareness     The purpose of awareness presentations is SP 800-50
                            simply to focus attention on security.    
                            Awareness presentations are intended to   
                            allow individuals to recognize IT         
                            security concerns and respond             
                            accordingly.                              

  IT Security Awareness and Explains proper rules of behavior for the SP 800-50
  Training Program          use of agency IT systems and information. 
                            The program communicates IT security      
                            policies and procedures that need to be   
                            followed.                                 

  IT Security Education     IT Security Education seeks to integrate  SP 800-50
                            all of the security skills and            
                            competencies of the various functional    
                            specialties into a common body of         
                            knowledge, adds a multidisciplinary study 
                            of concepts, issues, and principles       
                            (technological and social), and strives   
                            to produce IT security specialists and    
                            professionals capable of vision and       
                            pro-active response.                      

  IT Security Goal          The five security goals are               SP 800-27A
                            confidentiality, availability, integrity, 
                            accountability, and assurance.            

  IT Security Investment    An IT application or system that is       SP 800-65
                            solely devoted to security. For instance, 
                            intrusion detection systems (IDS) and     
                            public key infrastructure (PKI) are       
                            examples of IT security investments.      

  IT Security Metrics       Metrics based on IT security performance  SP 800-55
                            goals and objectives.                     

  IT Security Policy        The documentation of IT security          SP 800-35
                            decisions in an organization. NIST SP     
                            800-12 categorizes IT Security Policy     
                            into three basic types:\                  
                            1) Program Policy---high-level policy     
                            used to create an organization's IT       
                            security program, define its' scope       
                            within the organization, assign           
                            implementation responsibilities,          
                            establish strategic direction, and assign 
                            resources for implementation.\            
                            2) Issue-Specific Policies---address      
                            specific issues of concern to the         
                            organization, such as contingency         
                            planning, the use of a particular         
                            methodology for systems risk management,  
                            and implementation of new regulations or  
                            law. These policies are likely to require 
                            more frequent revision as changes in      
                            technology and related factors take       
                            place.\                                   
                            3) System-Specific Policies---address     
                            individual systems, such as establishing  
                            an access control list or in training     
                            users as to what system actions are       
                            permitted. These policies may vary from   
                            system to system within the same          
                            organization. In addition, policy may     
                            refer to entirely different matters, such 
                            as the specific managerial decisions      
                            setting an organization's electronic mail 
                            (e-mail) policy or fax security policy.   

  IT Security Training      IT Security Training strives to produce   SP 800-50
                            relevant and needed security skills and   
                            competencies by practitioners of          
                            functional specialties other than IT      
                            security (e.g., management, systems       
                            design and development, acquisition,      
                            auditing). The most significant           
                            difference between training and awareness 
                            is that training seeks to teach skills,   
                            which allow a person to perform a         
                            specific function, while awareness seeks  
                            to focus an individual's attention on an  
                            issue or set of issues. The skills        
                            acquired during training are built upon   
                            the awareness foundation, in particular,  
                            upon the security basics and literacy     
                            material.                                 

  []{#GK .anchor}Kerberos   A widely used authentication protocol     SP 800-63
                            developed at the Massachusetts Institute  
                            of Technology (MIT). In "classic"         
                            Kerberos, users share a secret password   
                            with a Key Distribution Center (KDC). The 
                            user, Alice, who wishes to communicate    
                            with another user, Bob, authenticates to  
                            the KDC and is furnished a "ticket" by    
                            the KDC to use to authenticate with Bob.  
                            When Kerberos authentication is based on  
                            passwords, the protocol is known to be    
                            vulnerable to off-line dictionary attacks 
                            by eavesdroppers who capture the initial  
                            user-to-KDC exchange.                     

  Key                       A value used to control cryptographic     SP 800-63
                            operations, such as decryption,           
                            encryption, signature generation or       
                            signature verification.                   

  Key Bundle                The three cryptographic keys (Key1, Key2, SP 800-67
                            Key3) that are used with a Triple Data    
                            Encryption Algorithm mode.                

  Key Escrow                A deposit of the private key of a         SP 800-32
                            subscriber and other pertinent            
                            information pursuant to an escrow         
                            agreement or similar contract binding     
                            upon the subscriber, the terms of which   
                            require one or more agents to hold the    
                            subscriber\'s private key for the benefit 
                            of the subscriber, an employer, or other  
                            party, upon provisions set forth in the   
                            agreement.                                

  Key Escrow                The processes of managing (e.g.,          FIPS 185
                            generating, storing, transferring,        
                            auditing) the two components of a         
                            cryptographic key by two key component    
                            holders.                                  

  Key Escrow System         A system that entrusts the two components FIPS 185
                            comprising a cryptographic key (e.g., a   
                            device unique key) to two key component   
                            holders (also called \"escrow agents\").  

  Key Establishment         The process by which cryptographic keys   FIPS 140-2
                            are securely distributed among            
                            cryptographic modules using manual        
                            transport methods (e.g., key loaders),    
                            automated methods (e.g., key transport    
                            and/or key agreement protocols), or a     
                            combination of automated and manual       
                            methods (consists of key transport plus   
                            key agreement).                           

  Key Exchange              The process of exchanging public keys in  SP 800-32;
                            order to establish secure communications. CNSSI-4009 Adapted

  Key Expansion             Routine used to generate a series of      FIPS 197
                            Round Keys from the Cipher Key.           

  Key Generation Material   Random numbers, pseudo-random numbers,    SP 800-32
                            and cryptographic parameters used in      
                            generating cryptographic keys.            

  Key Loader                A self-contained unit that is capable of  FIPS 140-2
                            storing at least one plaintext or         
                            encrypted cryptographic key or key        
                            component that can be transferred, upon   
                            request, into a cryptographic module.     

  Key Management            The activities involving the handling of  FIPS 140-2
                            cryptographic keys and other related      
                            security parameters (e.g., IVs and        
                            passwords) during the entire life cycle   
                            of the keys, including their generation,  
                            storage, establishment, entry and output, 
                            and zeroization.                          

  Key Pair                  Two mathematically related keys having    SP 800-32
                            the properties that\                      
                            1) one key can be used to encrypt a       
                            message that can only be decrypted using  
                            the other key, and\                       
                            2) even knowing one key, it is            
                            computationally infeasible to discover    
                            the other key.                            

  Key Pair                  A public key and its corresponding        SP 800-21 \[2nd
                            private key; a key pair is used with a    Ed\]; CNSSI-4009
                            public key algorithm.                     Adapted

  Key Transport             The secure transport of cryptographic     FIPS 140-2
                            keys from one cryptographic module to     
                            another module.                           

  Key Wrap                  A method of encrypting keys (along with   SP 800-56
                            associated integrity information) that    
                            provides both confidentiality and         
                            integrity protection using a symmetric    
                            key algorithm.                            

  Keyed-hash based message  A message authentication code that uses a FIPS 198
  authentication code       cryptographic key in conjunction with a   
  (HMAC)                    hash function.                            

  Keystroke Monitoring      The process used to view or record both   SP 800-12
                            the keystrokes entered by a computer user 
                            and the computer's response during an     
                            interactive session. Keystroke monitoring 
                            is usually considered a special case of   
                            audit trails.                             

  []{#GL .anchor}Label      SEE Security Label.                        

  Least Privilege           The security objective of granting users  SP 800-12
                            only those accesses they need to perform  
                            their official duties.                    

  Link Encryption           Link encryption encrypts all of the data  SP 800-12
                            along a communications path (e.g., a      
                            satellite link, telephone circuit, or T1  
                            line). Since link encryption also         
                            encrypts routing data, communications     
                            nodes need to decrypt the data to         
                            continue routing.                         

  Local Registration        A Registration Authority with             SP 800-32
  Authority (LRA)           responsibility for a local community.     

  Low Impact System         An information system in which all three  SP 800-53; FIPS
                            security objectives (i.e.,                200
                            confidentiality, integrity, and           
                            availability) are assigned a FIPS 199     
                            potential impact of low.                  

  []{#GM .anchor}Macro      A virus that attaches itself to documents SP 800-61
  Virus                     and uses the macro programming            
                            capabilities of the document's            
                            application to execute and propagate.     

  Major Application         An application that requires special      SP 800-53; OMB
                            attention to security due to the risk and Circular A-130,
                            magnitude of harm resulting from the      App. III
                            loss, misuse, or unauthorized access to   
                            or modification of the information in the 
                            application. Note: All federal            
                            applications require some level of        
                            protection. Certain applications, because 
                            of the information in them, however,      
                            require special management oversight and  
                            should be treated as major. Adequate      
                            security for other applications should be 
                            provided by security of the systems in    
                            which they operate.                       

  Major Information System  An information system that requires       SP 800-53; OMB
                            special management attention because of   Circular A-130,
                            its importance to an agency mission; its  App. III
                            high development, operating, or           
                            maintenance costs; or its significant     
                            role in the administration of agency      
                            programs, finances, property, or other    
                            resources.                                

  Malicious Code            Software or firmware intended to perform  SP 800-53 Rev 1;
                            an unauthorized process that will have    CNSSI-4009
                            adverse impact on the confidentiality,    
                            integrity, or availability of an          
                            information system. A virus, worm, Trojan 
                            horse, or other code-based entity that    
                            infects a host.                           

  Malware                   A program that is inserted into a system, SP 800-83
                            usually covertly, with the intent of      
                            compromising the confidentiality,         
                            integrity, or availability of the         
                            victim's data, applications, or operating 
                            system or of otherwise annoying or        
                            disrupting the victim.                    

  Man-in-the-middle Attack  An attack on the authentication protocol  SP 800-63
  (MitM)                    run in which the attacker positions       
                            himself in between the claimant and       
                            verifier so that he can intercept and     
                            alter data traveling between them.        

  Management Controls       The security controls (i.e., safeguards   SP 800-53; FIPS
                            or countermeasures) for an information    200
                            system that focus on the management of    
                            risk and the management of information    
                            system security.                          

  Mandatory Access Control  A means of restricting access to system   SP 800-44;
                            resources based on the sensitivity (as    CNSSI-4009 Adapted
                            represented by a label) of the            
                            information contained in the system       
                            resource and the formal authorization     
                            (i.e., clearance) of users to access      
                            information of such sensitivity.          

  Mandatory Access Control  Access controls (which) are driven by the FIPS 191
                            results of a comparison between the       
                            user's trust level or clearance and the   
                            sensitivity designation of the            
                            information.                              

  Mandatory Topography      The format and information required to be FIPS 201
                            displayed on a PIV card. Also known as    
                            the Standard Topography.                  

  Manual Key Transport      A non-electronic means of transporting    SP 800-57
                            cryptographic keys by physically moving a 
                            device, document or person containing or  
                            possessing the key or a key component.    

  Manual Key Transport      A non-electronic means of transporting    FIPS 140-2
                            cryptographic keys.                       

  Masquerading              When an unauthorized agent claims the     SP 800-19
                            identity of another agent it is said to   
                            be masquerading.                          

  Match/matching            The process of comparing biometric        FIPS 201
                            information against a previously stored   
                            template(s) and scoring the level of      
                            similarity.                               

  Media                     Physical devices or writing surfaces      FIPS 200
                            including but not limited to magnetic     
                            tapes, optical disks, magnetic disks, LSI 
                            memory chips, printouts (but not          
                            including display media) onto which       
                            information is recorded, stored, or       
                            printed within an information system.     

  Media Sanitization        A general term referring to the actions   SP 800-88
                            taken to render data written on media     
                            unrecoverable by both ordinary and        
                            extraordinary means.                      

  Memorandum of             A document established between two or     SP 800-47
  Understanding/Agreement   more parties to define their respective   
  (MOU/A)                   responsibilities in accomplishing a       
                            particular goal or mission. In this       
                            guide, an MOU/A defines the               
                            responsibilities of two or more           
                            organizations in establishing, operating, 
                            and securing a system interconnection.    

  Message Authentication    A cryptographic checksum on data that     SP 800-63; FIPS
  Code (MAC)                uses a symmetric key to detect both       201
                            accidental and intentional modifications  
                            of the data.                              

  Message Authentication    A cryptographic checksum that results     FIPS 198
  Code (MAC)                from passing data through a message       
                            authentication algorithm.                 

  Message Digest            A cryptographic checksum, typically       SP 800-61
                            generated for a file that can be used to  
                            detect changes to the file; Secure Hash   
                            Algorithm-1 (SHA-1) is an example of a    
                            message digest algorithm                  

  Metrics                   Tools designed to facilitate              SP 800-55
                            decision-making and improve performance   
                            and accountability through collection,    
                            analysis, and reporting of relevant       
                            performance-related data.                 

  MIME                      SEE Multipurpose Internet Mail             
                            Extensions.                               

  Min-Entropy               A measure of the difficulty that an       SP 800-63
                            attacker has to guess the most commonly   
                            chosen password used in a system.         

  Minor Application         An application, other than a major        SP 800-53
                            application, that requires attention to   
                            security due to the risk and magnitude of 
                            harm resulting from the loss, misuse, or  
                            unauthorized access to or modification of 
                            the information in the application. Minor 
                            applications are typically included as    
                            part of a general support system.         

  Misnamed Files            A technique used to disguise a file's     SP 800-72
                            content by changing the file's name to    
                            something innocuous or altering its       
                            extension to a different type of file,    
                            forcing the examiner to identify the      
                            files by file signature versus file       
                            extension.                                

  Mission Critical          Any telecommunications or information     SP 800-60
                            system that is defined as a national      
                            security system (Federal Information      
                            Security Management Act of 2002 - FISMA)  
                            or processes any information the loss,    
                            misuse, disclosure, or unauthorized       
                            access to or modification of, would have  
                            a debilitating impact on the mission of   
                            an agency.                                

  Mobile Code               Software programs or parts of programs    SP 800-53;
                            obtained from remote information systems, CNSSI-4009 Adapted
                            transmitted across a network, and         
                            executed on a local information system    
                            without explicit installation or          
                            execution by the recipient.               

  Mobile Code Technologies  Software technologies that provide the    SP 800-53
                            mechanisms for the production and use of  
                            mobile code (e.g., Java, JavaScript,      
                            ActiveX, VBScript).                       

  Mobile Site               A self-contained, transportable shell     SP 800-34
                            custom-fitted with the specific IT        
                            equipment and telecommunications          
                            necessary to provide full recovery        
                            capabilities upon notice of a significant 
                            disruption.                               

  Mobile Software Agent     Programs that are goal-directed and       SP 800-19
                            capable of suspending their execution on  
                            one platform and moving to another        
                            platform where they resume execution.     

  Mode of Operation         An algorithm for the cryptographic        SP 800-38C
                            transformation of data that features a    
                            symmetric key block cipher algorithm.     

  Moderate Impact System    An information system in which at least   SP 800-53; FIPS
                            one security objective (i.e.,             200
                            confidentiality, integrity, or            
                            availability) is assigned a FIPS 199      
                            potential impact value of moderate and no 
                            security objective is assigned a FIPS 199 
                            potential impact value of high.           

  Multi-Factor              Authentication controls that generally    
  Authentication            consist of something a user knows         
                            \[password\], has \[token, PIV, CAC\] ,   
                            or is \[biometric\]; minimally two-factor 
                            authentication is a combination of these  
                            elements - e.g. a hard token and complex  
                            password -- NOT A {USER ID AND PASSWORD}, 
                            OR A {PASSWORD AND ANOTHER PASSWORD}).    

  Multi-Hop Problem         The security risks resulting from a       SP 800-19
                            mobile software agent visiting several    
                            platforms.                                

  Multiple Component        A single incident that encompasses two or SP 800-61
  Incident                  more incidents.                           

  Multipurpose Internet     An extensible mechanism for email. A      SP 800-41
  Mail Extensions (MIME)    variety of MIME types exist for sending   
                            content such as audio using the Simple    
                            Mail Transfer Protocol (SMTP) protocol.   

  Mutual Authentication     Occurs when parties at both ends of a     SP 800-32
                            communication activity authenticate each  
                            other.                                    

  []{#GN .anchor}Naming     An organizational entity responsible for  SP 800-32
  Authority                 assigning distinguished names (DNs) and   
                            for assuring that each DN is meaningful   
                            and unique within its domain.             

  National Security         Telecommunications services that are used SP 800-53; 47
  Emergency Preparedness    to maintain a state of readiness or to    C.F.R., Part 64,
  Telecommunications        respond to and manage any event or crisis App A
  Services                  (local, national, or international) that  
                            causes or could cause injury or harm to   
                            the population, damage to or loss of      
                            property, or degrade or threaten the      
                            national security or emergency            
                            preparedness posture of the United        
                            States.                                   

  Needs Assessment (IT      A process that can be used to determine   SP 800-50
  Security Awareness and    an organization's awareness and training  
  Training)                 needs. The results of a needs assessment  
                            can provide justification to convince     
                            management to allocate adequate resources 
                            to meet the identified awareness and      
                            training needs.                           

  National Information      A U.S. Government initiative originated   SP 800-64
  Assurance Partnership     to meet the security testing needs of     
  (NIAP)                    both information technology (IT)          
                            consumers and producers. NIAP is          
                            collaboration between the National        
                            Institute of Standards and Technology     
                            (NIST) and the National Security Agency   
                            (NSA) in fulfilling their respective      
                            responsibilities. The partnership         
                            combines the extensive IT security        
                            experience of both agencies to promote    
                            the development of technically sound      
                            security requirements for IT products and 
                            systems and appropriate measures for      
                            evaluating those products and systems.    

  Non-repudiation           Assurance that the sender of information  SP 800-53;
                            is provided with proof of delivery and    CNSSI-4009
                            the recipient is provided with proof of   
                            the sender's identity, so neither can     
                            later deny having processed the           
                            information.                              

  Non-Repudiation           Is the security service by which the      FIPS 191
                            entities involved in a communication      
                            cannot deny having participated.          
                            Specifically the sending entity cannot    
                            deny having sent a message                
                            (non-repudiation with proof of origin)    
                            and the receiving entity cannot deny      
                            having received a message                 
                            (non-repudiation with proof of delivery). 

  Nonce                     A value used in security protocols that   SP 800-63
                            is never repeated with the same key. For  
                            example, challenges used in               
                            challenge-response authentication         
                            protocols generally must not be repeated  
                            until authentication keys are changed, or 
                            there is a possibility of a replay        
                            attack. Using a nonce as a challenge is a 
                            different requirement than a random       
                            challenge, because a nonce is not         
                            necessarily unpredictable.                

  []{#GO .anchor}Object     A passive entity that contains or         SP 800-27A;
                            receives information.                     CNSSI-4009 Adapted

  Object Identifier         A specialized formatted number that is    SP 800-32
                            registered with an internationally        
                            recognized standards organization. The    
                            unique alphanumeric/numeric identifier    
                            registered under the ISO registration     
                            standard to reference a specific object   
                            or object class. In the federal           
                            government PKI they are used to uniquely  
                            identify each of the four policies and    
                            cryptographic algorithms supported.       

  Off-Card                  Refers to data that is not stored within  FIPS 201
                            the PIV card or computation that is not   
                            done by the Integrated Circuit Chip (ICC) 
                            of the PIV card.                          

  Off-line Attack           An attack where the attacker obtains some SP 800-63
                            data (typically by eavesdropping on an    
                            authentication protocol run, or by        
                            penetrating a system and stealing         
                            security files) that he/she is able to    
                            analyze in a system of his/her own        
                            choosing.                                 

  On-Card                   Refers to data that is stored within the  FIPS 201
                            PIV card or computation that is done by   
                            the ICC of the PIV card.                  

  On-line Attack            An attack against an authentication       SP 800-63
                            protocol where the attacker either        
                            assumes the role of a claimant with a     
                            genuine verifier or actively alters the   
                            authentication channel. The goal of the   
                            attack may be to gain authenticated       
                            access or learn authentication secrets.   

  On-Line Certificate       An on-line protocol used to determine the SP 800-63
  Status Protocol (OCSP)    status of a public key certificate.       

  One-Way Hash Algorithm    Hash algorithms which map arbitrarily     SP 800-49
                            long inputs into a fixed-size output such 
                            that it is very difficult                 
                            (computationally infeasible) to find two  
                            different hash inputs that produce the    
                            same output. Such algorithms are an       
                            essential part of the process of          
                            producing fixed-size digital signatures   
                            that can both authenticate the signer and 
                            provide for data integrity checking       
                            (detection of input modification after    
                            signature).                               

  Online Certification      An on-line protocol used to determine the FIPS 201
  Status Protocol (OCSP)    status of a public key certificate.       

  Operational Controls      The security controls (i.e., safeguards   SP 800-53; FIPS
                            or countermeasures) for an information    200
                            system that primarily are implemented and 
                            executed by people (as opposed to         
                            systems).                                 

  Optional Topography       A Personal Identity Verification (PIV)    FIPS 201
                            card having both the Standard Topography  
                            (Mandatory Topography) features and the   
                            Optional features as defined in FIPS 201  
                            sections 4.1.4.3 and 4.1.4.4.             

  Outside Threat            An unauthorized entity from outside the   SP 800-32
                            domain perimeter that has the potential   
                            to harm an Information System through     
                            destruction, disclosure, modification of  
                            data, and/or denial of service.           

  []{#GP .anchor}Packet     Software that observes and records        SP 800-61
  Sniffer                   network traffic.                          

  Parent Organization       The organization that is applying for the FIPS 201
                            Personal Identity Verification card on    
                            behalf of an applicant. Typically this is 
                            an organization for whom the applicant is 
                            working.                                  

  Passive Attack            An attack against an authentication       SP 800-63
                            protocol where the attacker intercepts    
                            data traveling along the network between  
                            the claimant and verifier, but does not   
                            alter the data (i.e. eavesdropping).      

  Password                  A secret that a claimant memorizes and    SP 800-63
                            uses to authenticate his or her identity. 
                            Passwords are typically character         
                            strings.                                  

  Password                  A protected character string used to      FIPS 181
                            authenticate the identity of a computer   
                            system user or to authorize access to     
                            system resources.                         

  Password                  A string of characters (letters, numbers, FIPS 140-2
                            and other symbols) used to authenticate   
                            an identity or to verify access           
                            authorization.                            

  Password Protected        The ability to protect a file using a     SP 800-72
                            password access control, protecting the   
                            data contents from being viewed with the  
                            appropriate viewer unless the proper      
                            password is entered.                      

  Path Histories            Maintaining an authenticatable record of  SP 800-19
                            the prior platforms visited by a mobile   
                            software agent, so that a newly visited   
                            platform can determine whether to process 
                            the agent and what resource constraints   
                            to apply.                                 

  Payload                   The input data to the CCM                 SP 800-38C
                            generation-encryption process that is     
                            both authenticated and encrypted.         

  Personally Identifiable   Any information about an individual       OMB
  Information (PII)         maintained by an agency, including but    
                            not limited to, education, financial      
                            transactions, medical history, and        
                            criminal or employment history and        
                            information which can be used to          
                            distinguish or trace an individual\'s     
                            identity, such as their name, social      
                            security number, date and place of birth, 
                            mother\'s maiden name, biometric records, 
                            etc., including any other personal        
                            information which is linked or linkable   
                            to an individual                          

  Personal Identification   A password consisting only of decimal     SP 800-63
  Number (PIN)              digits.                                   

  Personal Identification   A secret that a claimant memorizes and    FIPS 201
  Number (PIN)              uses to authenticate his or her identity. 
                            PINS are generally only decimal digits.   

  Personal Identification   An alphanumeric code or password used to  FIPS 140-2
  Number (PIN)              authenticate an identity.                 

  Personal Identity         An individual who can act on behalf of an FIPS 201
  Verification Authorizing  agency to authorize the issuance of a     
  Official                  credential to an applicant.               

  Personal Identity         Physical artifact (e.g., identity card,   FIPS 201
  Verification Card (PIV    "smart" card) issued to an individual     
  Card)                     that contains stored identity credentials 
                            (e.g., photograph, cryptographic keys,    
                            digitized fingerprint representation      
                            etc.) such that a claimed identity of the 
                            cardholder may be verified against the    
                            stored credentials by another person      
                            (human readable and verifiable) or an     
                            automated process (computer readable and  
                            verifiable).                              

  Personal Identity         An authorized identity card creator that  FIPS 201
  Verification Issuance     procures FIPS approved blank identity     
  Authority                 cards, initializes them with appropriate  
                            software and data elements for the        
                            requested identity verification and       
                            access control application, personalizes  
                            the card with the identity credentials of 
                            the authorized subject, and delivers the  
                            personalized card to the authorized       
                            subject along with appropriate            
                            instructions for protection and use.      

  Personal Identity         An entity that establishes and vouches    FIPS 201
  Verification Registration for the identity of an applicant to a PIV 
  Authority                 Issuing Authority. The PIV RA             
                            authenticates the applicant's identity by 
                            checking identity source documents and    
                            identity proofing and ensures a proper    
                            background check has been completed       
                            before the credential is issued.          

  Personal Identity         An individual who can act on behalf of an FIPS 201
  Verification Requesting   agency to request a credential for an     
  Official                  applicant.                                

  Personally Identifiable   Any information about an individual       OMB Memorandum
  Information               maintained by an agency, including, but   m-06-19
                            not limited to, education, financial      
                            transactions, medical history, and        
                            criminal or employment history and        
                            information which can be used to          
                            distinguish or trace an individual\'s     
                            identity, such as their name, social      
                            security number, date and place of birth, 
                            mother's maiden name, biometric records,  
                            etc., including any other personal        
                            information which is linked or linkable   
                            to an individual.                         

  Phishing                  Tricking individuals into disclosing      SP 800-83
                            sensitive personal information through    
                            deceptive computer-based means.           

  Physically Isolated       A network that is not connected to        SP 800-32
  Network                   entities or systems outside a physically  
                            controlled space.                         

  Plaintext                 Data input to the Cipher or output from   FIPS 197
                            the Inverse Cipher.                       

  Plaintext                 Intelligible data that has meaning and    SP 800-21 \[2nd
                            can be understood without the application Ed\]
                            of decryption.                            

  Plaintext Key             An unencrypted cryptographic key.         FIPS 140-2

  Plan of Action and        A document that identifies tasks needing  SP 800-53; OMB
  Milestones (POA&M)        to be accomplished. It details resources  Memorandum 02-01
                            required to accomplish the elements of    
                            the plan, any milestones in meeting the   
                            tasks, and scheduled completion dates for 
                            the milestones.                           

  Policy                    A document that delineates the security   SP 800-26
                            management structure and clearly assigns  
                            security responsibilities and lays the    
                            foundation necessary to reliably measure  
                            progress and compliance.ALSO SEE Security 
                            Policy.                                   

  Policy Management         Body established to oversee the creation  SP 800-32
  Authority (PMA)           and update of Certificate Policies,       
                            review Certification Practice Statements, 
                            review the results of CA audits for       
                            policy compliance, evaluate non-domain    
                            policies for acceptance within the        
                            domain, and generally oversee and manage  
                            the PKI certificate policies. For the     
                            FBCA, the PMA is the Federal PKI Policy   
                            Authority.                                

  Policy Mapping            Recognizing that, when a CA in one domain SP 800-15
                            certifies a CA in another domain, a       
                            particular certificate policy in the      
                            second domain may be considered by the    
                            authority of the first domain to be       
                            equivalent (but not necessarily identical 
                            in all respects) to a particular          
                            certificate policy in the first domain.   

  Port                      A physical entry or exit point of a       FIPS 140-2
                            cryptographic module that provides access 
                            to the module for physical signals,       
                            represented by logical information flows  
                            (physically separated ports do not share  
                            the same physical pin or wire).           

  Port Scanning             Using a program to remotely determine     SP 800-61
                            which ports on a system are open (e.g.,   
                            whether systems allow connections through 
                            those ports).                             

  Potential Impact          The loss of confidentiality, integrity,   SP 800-53
                            or availability could be expected to      
                            have:\                                    
                            1) a limited adverse effect (FIPS 199     
                            low);\                                    
                            2) a serious adverse effect (FIPS 199     
                            moderate); or\                            
                            3) a severe or catastrophic adverse       
                            effect (FIPS 199 high) on organizational  
                            operations, organizational assets, or     
                            individuals.                              

  Potential Impact          The loss of confidentiality, integrity,   FIPS 200
                            or availability could be expected to have 
                            a limited adverse effect; a serious       
                            adverse effect, or a severe or            
                            catastrophic adverse effect on            
                            organizational operations, organizational 
                            assets, or individuals.                   

  Practice Statement        A formal statement of the practices       SP 800-63
                            followed by an authentication entity      
                            (e.g., RA, CSP, or verifier); typically   
                            the specific steps taken to register and  
                            verify identities, issue credentials and  
                            authenticate claimants.                   

  Precursor                 A sign that an attacker may be preparing  SP 800-61
                            to cause an incident.                     

  Principal                 An entity whose identity can be           FIPS 196
                            authenticated.                            

  Principal Certification   The Principal Certification Authority is  SP 800-32
  Authority (CA)            a CA designated by an Agency to           
                            interoperate with the FBCA. An Agency may 
                            designate multiple Principal CAs to       
                            interoperate with the FBCA.               

  Privacy                   Restricting access to subscriber or       SP 800-32
                            Relying Party information in accordance   
                            with Federal law and Agency policy.       

  Privacy Impact Assessment An analysis of how information is         SP 800-53; OMB
                            handled:\                                 Memorandum 03-22
                            1) to ensure handling conforms to         
                            applicable legal, regulatory, and policy  
                            requirements regarding privacy;\          
                            2) to determine the risks and effects of  
                            collecting, maintaining and disseminating 
                            information in identifiable form in an    
                            electronic information system; and\       
                            3) to examine and evaluate protections    
                            and alternative processes for handling    
                            information to mitigate potential privacy 
                            risks.                                    

  Private Key               The secret part of an asymmetric key pair SP 800-63
                            that is typically used to digitally sign  
                            or decrypt data.                          

  Private Key               A cryptographic key, used with a public   SP 800-57
                            key cryptographic algorithm, that is      
                            uniquely associated with an entity and is 
                            not made public. In an asymmetric         
                            (public) cryptosystem, the private key is 
                            associated with a public key. Depending   
                            on the algorithm, the private key may be  
                            used to: 1) Compute the corresponding     
                            public key,2) Compute a digital signature 
                            that may be verified by the corresponding 
                            public key, 3) Decrypt data that was      
                            encrypted by the corresponding public     
                            key, or 4) Compute a piece of common      
                            shared data, together with other          
                            information.                              

  Private Key               A cryptographic key used with a public    FIPS 196
                            key cryptographic algorithm, which is     
                            uniquely associated with an entity, and   
                            not made public; it is used to generate a 
                            digital signature; this key is            
                            mathematically linked with a              
                            corresponding public key.                 

  Private Key               A cryptographic key, used with a public   FIPS 140-2
                            key cryptographic algorithm, that is      
                            uniquely associated with an entity and is 
                            not made public.                          

  Privileged Accounts       Individuals who have access to set        SP 800-12
                            "access rights" for users on a given      
                            system. Sometimes referred to as system   
                            or network administrative accounts.       

  Profiling                 Measuring the characteristics of expected SP 800-61
                            activity so that changes to it can be     
                            more easily identified.                   

  Proof of Possession       A protocol where a claimant proves to a   SP 800-63
  Protocol (PoP Protocol)   verifier that he/she possesses and        
                            controls a token (e.g., a key or          
                            password).                                

  Protective Distribution   Wire line or fiber optic system that      SP 800-53
  System                    includes adequate safeguards and/or       
                            countermeasures (e.g., acoustic,          
                            electric, electromagnetic, and physical)  
                            to permit its use for the transmission of 
                            unencrypted information.                  

  Protocol Data Unit        A unit of data specified in a protocol    FIPS 188
                            and consisting of protocol information    
                            and, possibly, user data.                 

  Protocol Entity           Entity that follows a set of rules and    FIPS 188
                            formats (semantic and syntactic) that     
                            determines the communication behavior of  
                            other entities.                           

  Protocol Run              An instance of the exchange of messages   SP 800-63
                            between a claimant and a verifier in a    
                            defined authentication protocol that      
                            results in the authentication (or         
                            authentication failure) of the claimant.  

  Proxy                     A proxy is an application that breaks the SP 800-44
                            connection between client and server. The 
                            proxy accepts certain types of traffic    
                            entering or leaving a network and         
                            processes it and forwards it. This        
                            effectively closes the straight path      
                            between the internal and external         
                            networks. Making it more difficult for an 
                            attacker to obtain internal addresses and 
                            other details of the organization's       
                            internal network. Proxy servers are       
                            available for common Internet services;   
                            for example, an Hyper Text Transfer       
                            Protocol (HTTP) proxy used for Web        
                            access, and an Simple Mail Transfer       
                            Protocol (SMTP) proxy used for e-mail.    

  Proxy Agent               A proxy agent is a software application   SP 800-41
                            running on a firewall or on a dedicated   
                            proxy server that is capable of filtering 
                            a protocol and routing it to between the  
                            interfaces of the device.                 

  Proxy Server              A server that sits between a client       SP 800-46
                            application, such as a web browser, and a 
                            real server. It intercepts all requests   
                            to the real server to see if it can       
                            fulfill the requests itself. If not, it   
                            forwards the request to the real server.  

  Pseudorandom number       An algorithm that produces a sequence of  SP 800-57
  generator (PRNG)          bits that are uniquely determined from an 
                            initial value called a seed. The output   
                            of the PRNG "appears" to be random, i.e., 
                            the output is statistically               
                            indistinguishable from random values. A   
                            cryptographic PRNG has the additional     
                            property that the output is               
                            unpredictable, given that the seed is not 
                            known.                                    

  Pseudonym                 A subscriber name that has been chosen by SP 800-63
                            the subscriber that is not verified as    
                            meaningful by identity proofing.          

  Public Key                The public part of an asymmetric key pair SP 800-63
                            that is typically used to verify          
                            signatures or encrypt data.               

  Public Key                A cryptographic key that is used with a   SP 800-57
                            public key cryptographic algorithm. The   
                            public key is uniquely associated with an 
                            entity and may be made public. In an      
                            asymmetric (public) cryptosystem, the     
                            public key is associated with a private   
                            key. The public key may be known by       
                            anyone and, depending on the algorithm,   
                            may be used to 1) Verify a digital        
                            signature that is signed by the           
                            corresponding private key,2) Encrypt data 
                            that can be decrypted by the              
                            corresponding private key, or 3) Compute  
                            a piece of shared data.                   

  Public Key                A cryptographic key used with a public    FIPS 196
                            key cryptographic algorithm, uniquely     
                            associated with an entity, and which may  
                            be made public; it is used to verify a    
                            digital signature; this key is            
                            mathematically linked with a              
                            corresponding private key.                

  Public Key                A cryptographic key used with a public    FIPS 140-2
                            key cryptographic algorithm that is       
                            uniquely associated with an entity and    
                            that may be made public.                  

  Public Key Certificate    A digital document issued and digitally   SP 800-63
                            signed by the private key of a            
                            Certification Authority that binds the    
                            name of a subscriber to a public key. The 
                            certificate indicates that the subscriber 
                            identified in the certificate has sole    
                            control and access to the private key.    

  Public Key Certificate    A set of data that unambiguously          FIPS 196
                            identifies an entity, contains the        
                            entity\'s public key, and is digitally    
                            signed by a trusted third-party           
                            (certification authority).                

  Public Key Certificate    A set of data that uniquely identifies an FIPS 140-2
                            entity, contains the entity's public key, 
                            and is digitally signed by a trusted      
                            party, thereby binding the public key to  
                            the entity.                               

  Public Key (Asymmetric)   A cryptographic algorithm that uses two   FIPS 140-2
  Cryptographic Algorithm   related keys, a public key and a private  
                            key. The two keys have the property that  
                            deriving the private key from the public  
                            key is computationally infeasible.        

  Public (Asymmetric) Key   Public key cryptography uses "key pairs," SP 800-46
  Encryption                a public key and a mathematically related 
                            private key. Given the public key, it is  
                            infeasible to find the private key. The   
                            private key is kept secret while the      
                            public key may be shared with others. A   
                            message encrypted with the public key can 
                            only be decrypted with the private key. A 
                            message can be digitally signed with the  
                            private key, and anyone can verify the    
                            signature with the public key.            

  Public Key Infrastructure A set of policies, processes, server      SP 800-32
  (PKI)                     platforms, software and workstations used 
                            for the purpose of administering          
                            certificates and public-private key       
                            pairs, including the ability to issue,    
                            maintain, and revoke public key           
                            certificates.                             

  Public Key Infrastructure An architecture which is used to bind     FIPS 196
                            public keys to entities, enable other     
                            entities to verify public key bindings,   
                            revoke such bindings, and provide other   
                            services critical to managing public      
                            keys.                                     

  Public Seed               A starting value for a pseudorandom       SP 800-56
                            number generator. The value produced by   
                            the random number generator may be made   
                            public. The public seed is often called a 
                            "salt".                                   

  Purge                     Rendering sanitized data unrecoverable by SP 800-88
                            laboratory attack methods.                

  []{#GR .anchor}Random     A process used to generate an             SP 800-57
  Number Generator (RNG)    unpredictable series of numbers. Each     
                            individual value is called random if each 
                            of the values in the total population of  
                            values has an equal probability of being  
                            selected.                                 

  Random Number Generator   Random Number Generators (RNGs) used for  FIPS 140-2
  (RNG)                     cryptographic applications typically      
                            produce a sequence of zero and one bits   
                            that may be combined into sub-sequences   
                            or blocks of random numbers. There are    
                            two basic classes: deterministic and      
                            nondeterministic. A deterministic RNG     
                            consists of an algorithm that produces a  
                            sequence of bits from an initial value    
                            called a seed. A nondeterministic RNG     
                            produces output that is dependent on some 
                            unpredictable physical source that is     
                            outside human control.                    

  Recipient Usage Period    The period of time during the             SP 800-57
                            cryptoperiod of a symmetric key when      
                            protected information is processed. The   
                            recipient usage period of the key is      
                            usually identical to the cryptoperiod of  
                            that key.                                 

  Records                   The recordings of evidence of activities  SP 800-53; FIPS
                            performed or results achieved (e.g.,      200
                            forms, reports, test results) which serve 
                            as the basis for verifying that the       
                            organization and the information system   
                            are performing as intended. Also used to  
                            refer to units of related data fields     
                            (i.e., groups of data fields that can be  
                            accessed by a program and that contain    
                            the complete set of information on        
                            particular items).                        

  Reference Monitor         The security engineering term for IT      SP 800-33
                            functionality that\                       
                            1) controls all access,\                  
                            2) cannot be by-passed,\                  
                            3) is tamper-resistant, and\              
                            4) provides confidence that the other     
                            three items are true.                     

  Registration              The process through which a party applies SP 800-63
                            to become a subscriber of a Credentials   
                            Service Provider (CSP) and a Registration 
                            Authority validates the identity of that  
                            party on behalf of the CSP.               

  Registration Authority    A trusted entity that establishes and     SP 800-63
  (RA)                      vouches for the identity of a subscriber  
                            to a CSP. The RA may be an integral part  
                            of a CSP, or it may be independent of a   
                            CSP, but it has a relationship to the     
                            CSP(s).                                   

  Registration Authority    Organization responsible for assignment   FIPS 188
  (RA)                      of unique identifiers to registered       
                            objects.                                  

  Re-key (a certificate)    To change the value of a cryptographic    SP 800-32
                            key that is being used in a cryptographic 
                            system application; this normally entails 
                            issuing a new certificate on the new      
                            public key.                               

  Relying Party             An entity that relies upon the            SP 800-63
                            subscriber's credentials, typically to    
                            process a transaction or grant access to  
                            information or a system.                  

  Remediation               The act of correcting a vulnerability or  SP 800-40 Ver 2
                            eliminating a threat. Three possible      
                            types of remediation are installing a     
                            patch, adjusting configuration settings,  
                            or uninstalling a software application.   

  Remediation Plan          A plan to perform the remediation of one  SP 800-40 Ver 2
                            or more threats or vulnerabilities facing 
                            an organization's systems. The plan       
                            typically includes options to remove      
                            threats and vulnerabilities and           
                            priorities for performing the             
                            remediation.                              

  Remote Access             Access by users (or information systems)  SP 800-18 Rev 1
                            communicating external to an information  
                            system security perimeter.                

  Remote Access Point       A remote access point provides            SP 800-18 Rev 1
                            connectivity for users (or information    
                            systems) external to an information       
                            system security perimeter to other users  
                            (or information systems) within the       
                            information system security perimeter.    

  Remote Maintenance        Maintenance activities conducted by       SP 800-18 Rev 1
                            individuals communicating external to an  
                            information system security perimeter.    

  Renew (a certificate)     The act or process of extending the       SP 800-32
                            validity of the data binding asserted by  
                            a public key certificate by issuing a new 
                            certificate.                              

  Repository                A database containing information and     SP 800-32
                            data relating to certificates as          
                            specified in a CP; may also be referred   
                            to as a directory.                        

  Residual Risk             The remaining, potential risk after all   SP 800-33
                            IT security measures are applied. There   
                            is a residual risk associated with each   
                            threat.                                   

  Responder                 The entity that responds to the initiator FIPS 196
                            of the authentication exchange.           

  Responsible Individual    A trustworthy person designated by a      SP 800-32
                            sponsoring organization to authenticate   
                            individual applicants seeking             
                            certificates on the basis of their        
                            affiliation with the sponsor.             

  Revoke a Certificate      To prematurely end the operational period SP 800-32
                            of a certificate effective at a specific  
                            date and time.                            

  Rijndael                  Cryptographic algorithm specified in the  FIPS 197
                            Advanced Encryption Standard (AES).       

  Risk                      The level of impact on agency operations  SP 800-53; FIPS
                            (including mission, functions, image, or  200
                            reputation), agency assets, or            
                            individuals resulting from the operation  
                            of an information system given the        
                            potential impact of a threat and the      
                            likelihood of that threat occurring.      

  Risk Analysis             The process of identifying the risks to   SP 800-27A
                            system security and determining the       
                            likelihood of occurrence, the resulting   
                            impact, and the additional safeguards     
                            that mitigate this impact. Part of risk   
                            management and synonymous with risk       
                            assessment.                               

  Risk Assessment           The process of identifying risks to       SP 800-53
                            agency operations (including mission,     
                            functions, image, or reputation), agency  
                            assets, or individuals by determining the 
                            probability of occurrence, the resulting  
                            impact, and additional security controls  
                            that would mitigate this impact. Part of  
                            risk management, synonymous with risk     
                            analysis, and incorporates threat and     
                            vulnerability analyses.                   

  Risk Management           The process of managing risks to agency   SP 800-53
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals resulting from the operation  
                            of an information system. It includes     
                            risk assessment; cost-benefit analysis;   
                            the selection, implementation, and        
                            assessment of security controls; and the  
                            formal authorization to operate the       
                            system. The process considers             
                            effectiveness, efficiency, and            
                            constraints due to laws, directives,      
                            policies, or regulations.                 

  Risk Management           The process of managing risks to          FIPS 200
                            organizational operations (including      
                            mission, functions, image, or             
                            reputation), organizational assets, or    
                            individuals resulting from the operation  
                            of an information system, and             
                            includes: 1) the conduct of a risk        
                            assessment; 2) the implementation of a    
                            risk mitigation strategy; and 3)          
                            employment of techniques and procedures   
                            for the continuous monitoring of the      
                            security state of the information system. 

  Risk Management           The process of:\                          FIPS 191
                            1) estimating potential losses due to the 
                            use of or dependence upon automated       
                            information system technology,\           
                            2) analyzing potential threats and system 
                            vulnerabilities that contribute to loss   
                            estimates, and\                           
                            3) selecting cost effective safeguards    
                            that reduce risk to an acceptable level.  

  Risk Mitigation           Risk mitigation involves prioritizing,    SP 800-30
                            evaluating, and implementing the          
                            appropriate risk-reducing controls        
                            recommended from the risk assessment      
                            process.                                  

  Risk Tolerance            The level of risk an entity is willing to SP 800-32
                            assume in order to achieve a potential    
                            desired result.                           

  Root Certification        In a hierarchical Public Key              SP 800-32
  Authority                 Infrastructure, the Certification         
                            Authority whose public key serves as the  
                            most trusted datum (i.e., the beginning   
                            of trust paths) for a security domain.    

  Rootkit                   A set of tools used by an attacker after  SP 800-61
                            gaining root-level access to a host to    
                            conceal the attacker's activities on the  
                            host and permit the attacker to maintain  
                            root-level access to the host through     
                            covert means.                             

  Round Key                 Round keys are values derived from the    FIPS 197
                            Cipher Key using the Key Expansion        
                            routine; they are applied to the State in 
                            the Cipher and Inverse Cipher.            

  Rule-Based Security       A security policy based on global rules   SP 800-33
  Policy                    imposed for all subjects. These rules     
                            usually rely on a comparison of the       
                            sensitivity of the objects being accessed 
                            and the possession of corresponding       
                            attributes by the subjects requesting     
                            access.                                   

  []{#GS .anchor}S-box      Non-linear substitution table used in     FIPS 197
                            several byte substitution transformations 
                            and in the Key Expansion routine to       
                            perform a one for one substitution of a   
                            byte value.                               

  S/MIME                    A set of specifications for securing      SP 800-49
                            electronic mail. Secure/ Multipurpose     
                            Internet Mail Extensions (S/MIME) is      
                            based upon the widely used MIME standard  
                            and describes a protocol for adding       
                            cryptographic security services through   
                            MIME encapsulation of digitally signed    
                            and encrypted objects. The basic security 
                            services offered by S/MIME are            
                            authentication, non-repudiation of        
                            origin, message integrity, and message    
                            privacy. Optional security services       
                            include signed receipts, security labels, 
                            secure mailing lists, and an extended     
                            method of identifying the signer's        
                            certificate(s).                           

  Safeguards                Protective measures prescribed to meet    SP 800-53;
                            the security requirements (i.e.,          CNSSI-4009 Adapted
                            confidentiality, integrity, and           
                            availability) specified for an            
                            information system. Safeguards may        
                            include security features, management     
                            constraints, personnel security, and      
                            security of physical structures, areas,   
                            and devices. Synonymous with security     
                            controls and countermeasures.             

  Safeguards                Protective measures prescribed to meet    FIPS 200;
                            the security requirements (i.e.,          CNSSI-4009 Adapted
                            confidentiality, integrity, and           
                            availability) specified for an            
                            information system. Safeguards may        
                            include security features, management     
                            constraints, personnel security, and      
                            security of physical structures, areas,   
                            and devices.                              

  Salt                      A non-secret value that is used in a      SP 800-63
                            cryptographic process, usually to ensure  
                            that the results of computations for one  
                            instance cannot be reused by an attacker. 

  Sandboxing                A method of isolating application modules SP 800-19
                            into distinct fault domains enforced by   
                            software. The technique allows untrusted  
                            programs written in an unsafe language,   
                            such as C, to be executed safely within   
                            the single virtual address space of an    
                            application. Untrusted machine            
                            interpretable code modules are            
                            transformed so that all memory accesses   
                            are confined to code and data segments    
                            within their fault domain. Access to      
                            system resources can also be controlled   
                            through a unique identifier associated    
                            with each domain.                         

  Sanitization              Process to remove information from media  SP 800-53; FIPS
                            such that information recovery is not     200; CNSSI-4009
                            possible. It includes removing all        Adapted
                            labels, markings, and activity logs.      

  Scanning                  Sending packets or requests to another    SP 800-61
                            system to gain information to be used in  
                            a subsequent attack.                      

  Scoping Guidance          Provides organizations with specific      SP 800-53
                            technology-related,                       
                            infrastructure-related, public            
                            access-related, scalability-related,      
                            common security control-related, and      
                            risk-related considerations on the        
                            applicability and implementation of       
                            individual security controls in the       
                            control baseline.                         

  Scoping Guidance          Specific factors related to technology,   FIPS 200
                            infrastructure, public access,            
                            scalability, common security controls,    
                            and risk that can be considered by        
                            organizations in the applicability and    
                            implementation of individual security     
                            controls in the security control          
                            baseline.                                 

  Secret Key                A cryptographic key that is used with a   SP 800-57
                            secret key (symmetric) cryptographic      
                            algorithm, that is uniquely associated    
                            with one or more entities and is not be   
                            made public. The use of the term "secret" 
                            in this context does not imply a          
                            classification level, but rather implies  
                            the need to protect the key from          
                            disclosure.                               

  Secret Key                A cryptographic key that must be          FIPS 201
                            protected from unauthorized disclosure to 
                            protect data encrypted with the key.      

  Secret Key                A cryptographic key that is uniquely      FIPS 198
                            associated with one or more entities. The 
                            use of the term "secret" in this context  
                            does not imply a classification level,    
                            but rather implies the need to protect    
                            the key from disclosure.                  

  Secret Key                A cryptographic key, used with a secret   FIPS 140-2
                            key cryptographic algorithm, that is      
                            uniquely associated with one or more      
                            entities and should not be made public.   

  Secret Key (symmetric)    A cryptographic algorithm that uses a     FIPS 140-2
  Cryptographic Algorithm   single secret key for both encryption and 
                            decryption.                               

  Secret (Symmetric) Key    This is the traditional method used for   SP 800-46
  Encryption                encryption. The same key is used for both 
                            encryption and decryption. Only the party 
                            or parties that exchange secret messages  
                            know the secret key. The biggest problem  
                            with symmetric key encryption is securely 
                            distributing the keys. Public key         
                            techniques are now often used to          
                            distribute the symmetric keys.            

  Secret Seed               A secret value that used to initialize a  SP 800-57
                            pseudorandom number generator. The        
                            resulting value from the random number    
                            generator remains secret or private.      

  Secure/Multipurpose       A set of specifications for securing      SP 800-49
  Internet Mail Extensions  electronic mail. S/MIME is based upon the 
  (S/MIME)                  widely used MIME standard \[MIME\] and    
                            describes a protocol for adding           
                            cryptographic security services through   
                            MIME encapsulation of digitally signed    
                            and encrypted objects. The basic security 
                            services offered by S/MIME are            
                            authentication, non-repudiation of        
                            origin, message integrity, and message    
                            privacy. Optional security services       
                            include signed receipts, security labels, 
                            secure mailing lists, and an extended     
                            method of identifying the signer's        
                            certificate(s).                           

  Secure Communication      A communication protocol that provides    SP 800-57
  Protocol                  the appropriate confidentiality,          
                            authentication and content integrity      
                            protection.                               

  Secure Hash Algorithm     The Secure Hash Algorithm defined in      SP 800-22
  (SHA-1)                   Federal Information Processing Standard   
                            180-1.                                    

  Secure Socket Layer and   Secure Sockets Layer is a protocol        SP 800-46
  Transport Layer Security  developed by Netscape for transmitting    
  (SSL and TSL)             private documents via the Internet. SSL   
                            works by using a public key to encrypt    
                            data that\'s transferred over the SSL     
                            connection. Most web browsers support     
                            SSL, and many web sites use the protocol  
                            to obtain confidential user information,  
                            such as credit card numbers. By           
                            convention, URLs that require an SSL      
                            connection start with "https:" instead of 
                            "http:." TLS is a protocol created to     
                            provide authentication, confidentiality   
                            and data integrity between two            
                            communicating applications. TLS is based  
                            on a precursor protocol called "The       
                            Secure Sockets Layer Version 3.0" (SSL    
                            3.0) and is considered to be an           
                            improvement to SSL 3.0. SSL is specified  
                            in an expired Internet Draft working      
                            document of the Internet Engineering Task 
                            Force (IETF). The Transport Layer         
                            Security Version 1 (TLS 1.0)              
                            specification is an Internet Request for  
                            Comments \[RFC2246\]. Each document       
                            specifies a similar protocol that         
                            provides security services over the       
                            Internet. While TLS 1.0 is based on SSL   
                            3.0, and the differences are not          
                            dramatic; they are significant enough     
                            that TLS 1.0 and SSL 3.0 do not           
                            interoperate.                             

  Security Accreditation    The official management decision given by SP 800-37
                            a senior agency official to authorize     
                            operation of an information system and to 
                            explicitly accept the risk to agency      
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals, based on the implementation  
                            of an agreed-upon set of security         
                            controls.                                 

  Security Assertion Markup A specification for encoding security     SP 800-63
  Language (SAML)           assertions in the Extensible Markup       
                            Language (XML).                           

  Security Attribute        A security-related quality of an object.  FIPS 188
                            Security attributes may be represented as 
                            hierarchical levels, bits in a bit map,   
                            or numbers. Compartments, caveats, and    
                            release markings are examples of security 
                            attributes.                               

  Security Authorization    The official management decision given by SP 800-37
                            a senior agency official to authorize     
                            operation of an information system and to 
                            explicitly accept the risk to agency      
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals, based on the implementation  
                            of an agreed-upon set of security         
                            controls.                                 

  Security Category         The characterization of information or an SP 800-53; FIPS
                            information system based on an assessment 200; FIPS 199
                            of the potential impact that a loss of    
                            confidentiality, integrity, or            
                            availability of such information or       
                            information system would have on          
                            organizational operations, organizational 
                            assets, or individuals.                   

  Security Control Baseline The set of minimum security controls      SP 800-53; FIPS
                            defined for a low-impact,                 200
                            moderate-impact, or high-impact           
                            information system.                       

  Security Control          Statements of security capability to:\    SP 800-53
  Enhancements              1) build in additional, but related,      
                            functionality to a basic control; and/or\ 
                            2) increase the strength of a basic       
                            control.                                  

  Security Controls         The management, operational, and          SP 800-53; FIPS
                            technical controls (i.e., safeguards or   200; FIPS 199
                            countermeasures) prescribed for an        
                            information system to protect the         
                            confidentiality, integrity, and           
                            availability of the system and its        
                            information.                              

  Security Domain           A set of subjects, their information      SP 800-27A
                            objects, and a common security policy.    

  Security Domain           A collection of entities to which applies FIPS 188
                            a single security policy executed by a    
                            single authority.                         

  Security Goals            The five security goals are               SP 800-27A
                            confidentiality, availability, integrity, 
                            accountability, and assurance.            

  Security Impact Analysis  The analysis conducted by an agency       SP 800-53
                            official, often during the continuous     
                            monitoring phase of the security          
                            certification and accreditation process,  
                            to determine the extent to which changes  
                            to the information system have affected   
                            the security posture of the system.       

  Security Label            Explicit or implicit marking of a data    SP 800-53
                            structure or output media associated with 
                            an information system representing the    
                            FIPS 199 security category, or            
                            distribution limitations or handling      
                            caveats of the information contained      
                            therein.                                  

  Security Label            A marking bound to a resource (which may  FIPS 188
                            be a data unit) that names or designates  
                            the security attributes of that resource. 

  Security Level            A hierarchical indicator of the degree of FIPS 188
                            sensitivity to a certain threat. It       
                            implies, according to the security policy 
                            being enforced, a specific level of       
                            protection.                               

  Security Objective        Confidentiality, integrity, or            SP 800-53; FIPS
                            availability.                             200; FIPS 199

  Security Perimeter        SEE Accreditation Boundary.                

  Security Plan             SEE System Security Plan.                  

  Security Policy           The statement of required protection of   SP 800-27A
                            the information objects.                  

  Security Policy           Security Policy is senior management\'s   SP 800-12
                            directives to create a computer security  
                            program, establish its goals, and assign  
                            responsibilities.                         

  Security Policy           A set of criteria for the provision of    FIPS 188
                            security services. It defines and         
                            constrains the activities of a data       
                            processing facility in order to maintain  
                            a condition of security for systems and   
                            data.                                     

  Security Requirements     Requirements levied on an information     SP 800-53
                            system that are derived from laws,        
                            executive orders, directives, policies,   
                            instructions, regulations, or             
                            organizational (mission) needs to ensure  
                            the confidentiality, integrity, and       
                            availability of the information being     
                            processed, stored, or transmitted.        

  Security Requirements     Requirements levied on an information     FIPS 200
                            system that are derived from applicable   
                            laws, Executive Orders, directives,       
                            policies, standards, instructions,        
                            regulations, or procedures, or            
                            organizational mission/business case      
                            needs to ensure the confidentiality,      
                            integrity, and availability of the        
                            information being processed, stored, or   
                            transmitted.                              

  Security Service          A capability that supports one, or many,  SP 800-27A
                            of the security goals. Examples of        
                            security services are key management,     
                            access control, and authentication.       

  Security Tag              Information unit containing a             FIPS 188
                            representation of certain                 
                            security-related information (e.g., a     
                            restrictive attribute bit map).           

  Senior Agency Information The Department's Chief Information        SP 800-53; FIPS
  Security Officer (SAISO)  Security Officer (CISO). Official         200; 44 U.S.C.,
                            responsible for carrying out the Chief    Sec. 3544
                            Information Officer responsibilities      
                            under the Federal Information Security    
                            Management Act (FISMA) and serving as the 
                            Chief Information Officer's primary       
                            liaison to the agency's authorizing       
                            officials, information system owners, and 
                            information system security officers.     

  Sensitive Information     Any information, the loss, misuse, or     15 USC Sec. 278-g3
                            unauthorized access to or modification of 
                            which could adversely affect the national 
                            interest or the conduct of federal        
                            programs, or the privacy to which         
                            individuals are entitled under section    
                            552a of Title 5, United States Code (the  
                            Privacy Act), but which has not been      
                            specifically authorized under criteria    
                            established by an Executive Order or an   
                            Act of Congress to be kept secret in the  
                            interest of national defense or foreign   
                            policy.                                   

  Sensitivity               Used in this guideline to mean a measure  SP 800-60
                            of the importance assigned to information 
                            by its owner, for the purpose of denoting 
                            its need for protection.                  

  Sensitivity Levels        A graduated system of marking (e.g., low, FIPS 201
                            moderate, high) information and           
                            information processing systems based on   
                            threats and risks that result if a threat 
                            is successfully conducted.                

  SHA-1                     SEE Secure Hash Algorithm.                 

  Shared Secret             A secret used in authentication that is   SP 800-63
                            known to the claimant and the verifier.   

  Signature                 A recognizable, distinguishing pattern    SP 800-61
                            associated with an attack, such as a      
                            binary string in a virus or a particular  
                            set of keystrokes used to gain            
                            unauthorized access to a system.          

  Signature Certificate     A public key certificate that contains a  SP 800-32
                            public key intended for verifying digital 
                            signatures rather than encrypting data or 
                            performing any other cryptographic        
                            functions.                                

  Signature Generation      Uses a digital signature algorithm and a  SP 800-57
                            private key to generate a digital         
                            signature on data.                        

  Signature Verification    Uses a digital signature algorithm and a  SP 800-57
                            public key to verify a digital signature. 

  Signed Data               Data on which a digital signature is      FIPS 196
                            generated.                                

  Single-Hop Problem        The security risks resulting from an      SP 800-19
                            mobile software agent moving from its     
                            home platform to another platform.        

  Smart Card                A credit card with a built-in             SP 800-48
                            microprocessor and memory that is used    
                            for identification or financial           
                            transactions. When inserted into a        
                            reader, the card transfers data to and    
                            from a central computer. A smart card is  
                            more secure than a magnetic stripe card   
                            and can be programmed to self-destruct if 
                            the wrong password is entered too many    
                            times.                                    

  Sniffer                   Software that observes and records        SP 800-61
                            network traffic.                          

  Social Engineering        An attempt to trick someone into          SP 800-61
                            revealing information (e.g., a password)  
                            that can be used to attack systems or     
                            networks.                                 

  Software-Based Fault      A method of isolating application modules SP 800-19
  Isolation                 into distinct fault domains enforced by   
                            software. The technique allows untrusted  
                            programs written in an unsafe language,   
                            such as C, to be executed safely within   
                            the single virtual address space of an    
                            application. Untrusted machine            
                            interpretable code modules are            
                            transformed so that all memory accesses   
                            are confined to code and data segments    
                            within their fault domain. Access to      
                            system resources can also be controlled   
                            through a unique identifier associated    
                            with each domain.                         

  Split Knowledge           A procedure whereby a cryptographic key   SP 800-57
                            is handled as multiple key components     
                            from the time that the key or the         
                            separate key components are generated     
                            until the key components are combined for 
                            use. Each key component provides no       
                            knowledge of the ultimate key. The key    
                            may be created and then split into the    
                            key components, or may be created as      
                            separate key components. The key          
                            components are output from the generating 
                            cryptographic module(s) to separate       
                            entities for individual handling, and     
                            subsequently input separately into the    
                            intended cryptographic module and         
                            combined to form the ultimate key. Note:  
                            A suitable combination function is not    
                            provided by simple concatenation; e.g.,   
                            it is not acceptable to form an 80-bit    
                            key by concatenating two 40-bit key       
                            components.                               

  Split Knowledge           A process by which a cryptographic key is FIPS 140-2
                            split into multiple key components,       
                            individually sharing no knowledge of the  
                            original key, that can be subsequently    
                            input into, or output from, a             
                            cryptographic module by separate entities 
                            and combined to recreate the original     
                            cryptographic key.                        

  Spoofing                  IP spoofing" refers to sending a network  SP 800-48
                            packet that appears to come from a source 
                            other than its actual source.             

  Spoofing                  Involves\                                 FIPS 191
                            1) the ability to receive a message by    
                            masquerading as the legitimate receiving  
                            destination, or\                          
                            2) masquerading as the sending machine    
                            and sending a message to a destination.   

  Spyware                   Software that is secretly or              SP 800-53 Rev 1
                            surreptitiously installed into an         
                            information system to gather information  
                            on individuals or organizations without   
                            their knowledge; a type of malicious      
                            code.                                     

  SSL                       SEE Secure Socket Layer and Transport      
                            Layer Security (SSL and TSL).             

  Standard                  A published statement on a topic          FIPS 201
                            specifying characteristics, usually       
                            measurable, that must be satisfied or     
                            achieved in order to comply with the      
                            standard.                                 

  Standard Topography       The format and information required to be FIPS 201
                            displayed on a PIV card. Also known as    
                            the Mandatory Topography.                 

  State                     Intermediate Cipher result that can be    FIPS 197
                            pictured as a rectangular array of bytes. 

  Static Keys               Static keys are relatively long-lived and SP 800-57
                            are common to a number of executions of a 
                            given algorithm.                          

  Steganography             The art and science of communicating in a SP 800-72
                            way that hides the existence of the       
                            communication. For example, a child       
                            pornography image can be hidden inside    
                            another graphic image file, audio file,   
                            or other file format.                     

  Subject                   The person whose identity is bound to a   SP 800-63
                            particular credential.                    

  Subordinate Certification In a hierarchical PKI, a Certification    SP 800-32
  Authority (CA)            Authority whose certificate signature key 
                            is certified by another CA, and whose     
                            activities are constrained by that other  
                            CA.                                       

  Subscriber                A party who receives a credential or      SP 800-63
                            token from a CSP and becomes a claimant   
                            in an authentication protocol.            

  Subsystem                 A major subdivision or component of an    SP 800-18 Rev 1
                            information system consisting of          
                            information, information technology, and  
                            personnel that perform one or more        
                            specific functions.                       

  Superior Certification    In a hierarchical PKI, a Certification    SP 800-32
  Authority (CA)            Authority who has certified the           
                            certificate signature key of another CA,  
                            and who constrains the activities of that 
                            CA.                                       

  Symmetric Encryption      Encryption algorithms using the same      SP 800-49
  Algorithm                 secret key for encryption and decryption. 

  Symmetric Key             A cryptographic key that is used to       SP 800-63
                            perform both the cryptographic operation  
                            and its inverse, for example to encrypt   
                            and decrypt, or create a message          
                            authentication code and to verify the     
                            code.                                     

  Symmetric Key             A single cryptographic key that is used   SP 800-21 \[2nd
                            with a secret (symmetric) key algorithm.  Ed\]

  System                    A discrete set of information resources   SP 800-53
                            organized for the collection, processing, 
                            maintenance, use, sharing, dissemination, 
                            or disposition of information.ALSO SEE    
                            Information System.                       

  System Administrator      A person who manages the technical        SP 800-40 Ver 2
                            aspects of a system.                      

  System Development Life   The scope of activities associated with a SP 800-34
  Cycle (SDLC)              system, encompassing the system's         
                            initiation, development and acquisition,  
                            implementation, operation and             
                            maintenance, and ultimately its disposal  
                            that instigates another system            
                            initiation.                               

  System Integrity          The quality that a system has when it     SP 800-27A;
                            performs its intended function in an      CNSSI-4009 Adapted
                            unimpaired manner, free from unauthorized 
                            manipulation of the system, whether       
                            intentional or accidental.                

  System Interconnection    The direct connection of two or more IT   SP 800-47
                            systems for the purpose of sharing data   
                            and other information resources.          

  System-specific Security  A security control for an information     SP 800-53
  Control                   system that has not been designated as a  
                            common security control.                  

  System Security Plan      Formal document that provides an overview SP 800-53; FIPS
                            of the security requirements for the      200
                            information system and describes the      
                            security controls in place or planned for 
                            meeting those requirements.               

  System Software           The special software within the           FIPS 140-2
                            cryptographic boundary (e.g., operating   
                            system, compilers or utility programs)    
                            designed for a specific computer system   
                            or family of computer systems to          
                            facilitate the operation and maintenance  
                            of the computer system, and associated    
                            programs, and data.                       

  []{#GT .anchor}Technical  The security controls (i.e., safeguards   SP 800-53; FIPS
  Controls                  or countermeasures) for an information    200
                            system that are primarily implemented and 
                            executed by the information system        
                            through mechanisms contained in the       
                            hardware, software, or firmware           
                            components of the system.                 

  Technical non-repudiation The contribution of public key mechanisms SP 800-32
                            to the provision of technical evidence    
                            supporting a non-repudiation security     
                            service.                                  

  Tempest                   A name referring to the investigation,    FIPS 140-2
                            study, and control of unintentional       
                            compromising emanations from              
                            telecommunications and automated          
                            information systems equipment.            

  Template                  A biometric image data record.            FIPS 201

  Threat                    Any circumstance or event with the        SP 800-53;
                            potential to adversely impact agency      CNSSI-4009 Adapted
                            operations (including mission, functions, 
                            image, or reputation), agency assets, or  
                            individuals through an information system 
                            via unauthorized access, destruction,     
                            disclosure, modification of information,  
                            and/or denial of service.                 

  Threat                    Any circumstance or event with the        FIPS 200;
                            potential to adversely impact             CNSSI-4009 Adapted
                            organizational operations (including      
                            mission, functions, image, or             
                            reputation), organizational assets, or    
                            individuals through an information system 
                            via unauthorized access, destruction,     
                            disclosure, modification of information,  
                            and/or denial of service. Also, the       
                            potential for a threat-source to          
                            successfully exploit a particular         
                            information system vulnerability.         

  Threat Agent/Source       Either:\                                  SP 800-53
                            1) intent and method targeted at the      
                            intentional exploitation of a             
                            vulnerability; or\                        
                            2) a situation and method that may        
                            accidentally trigger a vulnerability.     

  Threat Analysis           The examination of threat sources against SP 800-27A
                            system vulnerabilities to determine the   
                            threats for a particular system in a      
                            particular operational environment.       

  Threat Assessment         Formal description and evaluation of      SP 800-53;
                            threat to an information system.          CNSSI-4009

  Threat Source             The intent and method targeted at the     FIPS 200
                            intentional exploitation of a             
                            vulnerability or a situation and method   
                            that may accidentally trigger a           
                            vulnerability.                            

  Threat Source             Either:\                                  SP 800-37
                            1) intent and method targeted at the      
                            intentional exploitation of a             
                            vulnerability; or\                        
                            2) a situation and method that may        
                            accidentally trigger a vulnerability.     
                            Synonymous with threat agent.             

  Token                     Something that the claimant possesses and SP 800-63
                            controls (typically a key or password)    
                            used to authenticate the claimant's       
                            identity.                                 

  Topology                  The physical, non-logical features of a   FIPS 201
                            card. A card may have either standard or  
                            enhanced topography.                      

  Total Risk                The potential for the occurrence of an    SP 800-16
                            adverse event if no mitigating action is  
                            taken (i.e., the potential for any        
                            applicable threat to exploit a system     
                            vulnerability).                           

  Tracking Cookie           A cookie placed on a user's computer to   SP 800-83
                            track the user's activity on different    
                            Web sites, creating a detailed profile of 
                            the user's behavior.                      

  Traffic Analysis          A form of passive attack in which an      SP 800-24
                            intruder observes information about calls 
                            (although not necessarily the contents of 
                            the messages) and makes inferences, e.g.  
                            from the source and destination numbers,  
                            or frequency and length of the messages.  

  Training (Information     Training strives to produce relevant and  SP 800-50
  Security)                 needed (information) security skills and  
                            competencies.                             

  Training Assessment       An evaluation of the training efforts.    SP 800-16

  Training Effectiveness    A measurement of what a given student has SP 800-16
                            learned from a specific course or         
                            training event.                           

  Training Effectiveness    Information collected to assist employees SP 800-16
  Evaluation                and their supervisors in assessing        
                            individual students' subsequent           
                            on-the-job performance, to provide trend  
                            data to assist trainers in improving both 
                            learning and teaching, and to be used in  
                            return-on-investment statistics to enable 
                            responsible officials to allocate limited 
                            resources in a thoughtful, strategic      
                            manner among the spectrum of IT security  
                            awareness, security literacy, training,   
                            and education options for optimal results 
                            among the workforce as a whole.           

  Transport Layer Security  See Secure Socket Layer and Transport     SP 800-63
  (TLS)                     Layer Security (SSL and TSL).             

  Triple DES                An implementation of the Data Encryption  SP 800-46
                            Standard (DES) algorithm that uses three  
                            passes of the DES algorithm instead of    
                            one as used in ordinary DES applications. 
                            Triple DES provides much stronger         
                            encryption than ordinary DES but it is    
                            less secure than AES.                     

  Trojan Horse              A non-self-replicating program that seems SP 800-61
                            to have a useful purpose, but in reality  
                            has a different, malicious purpose.       

  Trust Anchor              A public key and the name of a            SP 800-57
                            certification authority that is used to   
                            validate the first certificate in a       
                            sequence of certificates. The trust       
                            anchor public key is used to verify the   
                            signature on a certificate issued by a    
                            trust anchor certification authority. The 
                            security of the validation process        
                            depends upon the authenticity and         
                            integrity of the trust anchor. Trust      
                            anchors are often distributed as          
                            self-signed certificates.                 

  Trust List                The collection of trusted certificates    SP 800-32
                            used by Relying Parties to authenticate   
                            other certificates.                       

  Trusted Agent             Entity authorized to act as a             SP 800-32
                            representative of an Agency in confirming 
                            Subscriber identification during the      
                            registration process. Trusted Agents do   
                            not have automated interfaces with        
                            Certification Authorities.                

  Trusted Certificate       A certificate that is trusted by the      SP 800-32
                            Relying Party on the basis of secure and  
                            authenticated delivery. The public keys   
                            included in trusted certificates are used 
                            to start certification paths. Also known  
                            as a \"trust anchor\".                    

  Trusted Path              A mechanism by which a user (through an   SP 800-53
                            input device) can communicate directly    
                            with the security functions of the        
                            information system with the necessary     
                            confidence to support the system security 
                            policy. This mechanism can only be        
                            activated by the user or the security     
                            functions of the information system and   
                            cannot be imitated by untrusted software. 

  Trusted Path              A means by which an operator and a target FIPS 140-2;
                            of evaluation security function can       CNSSI-4009 Adapted
                            communicate with the necessary confidence 
                            to support the target of evaluation       
                            security policy.                          

  Trusted Timestamp         A digitally signed assertion by a trusted SP 800-32
                            authority that a specific digital object  
                            existed at a particular time.             

  Trustworthiness           The attribute of a person or organization SP 800-79
                            that provides confidence to others of the 
                            qualifications, capabilities, and         
                            reliability of that entity to perform     
                            specific tasks and fulfill assigned       
                            responsibilities.                         

  Trustworthy System        Computer hardware, software and           SP 800-32
                            procedures that\                          
                            1) are reasonably secure from intrusion   
                            and misuse;\                              
                            2) provide a reasonable level of          
                            availability, reliability, and correct    
                            operation;\                               
                            3) are reasonably suited to performing    
                            their intended functions; and\            
                            4) adhere to generally accepted security  
                            procedures.                               

  Tunneled Password         A protocol where a password is sent       SP 800-63
  Protocol                  through a protected channel. For example, 
                            the TLS protocol is often used with a     
                            verifier's public key certificate to\     
                            (1) authenticate the verifier to the      
                            claimant,\                                
                            (2) establish an encrypted session        
                            between the verifier and claimant, and\   
                            (3) transmit the claimant's password to   
                            the verifier. The encrypted TLS session   
                            protects the claimant's password from     
                            eavesdroppers.                            

  []{#GU                    A person gains logical or physical access SP 800-61
  .anchor}Unauthorized      without permission to a network, system,  
  Access                    application, data, or other resource.     

  Unauthorized Access       Occurs when a user, legitimate or         FIPS 191
                            unauthorized, accesses a resource that    
                            the user is not permitted to use.         

  Unauthorized Disclosure   An event involving the exposure of        SP 800-57;
                            information to entities not authorized    CNSSI-4009 Adapted
                            access to the information.                

  Unsigned data             Data included in an authentication token, FIPS 196
                            in addition to a digital signature.       

  Update (a Certificate)    The act or process by which data items    SP 800-32
                            bound in an existing public key           
                            certificate, especially authorizations    
                            granted to the subject, are changed by    
                            issuing a new certificate.                

  User                      Individual or (system) process authorized SP 800-53; FIPS
                            to access an information system.          200; CNSSI-4009

  User                      An individual or a process (subject)      FIPS 140-2
                            acting on behalf of the individual that   
                            accesses a cryptographic module in order  
                            to obtain cryptographic services.         

  User Initialization       A stage in the lifecycle of keying        SP 800-57
                            material; the process whereby a user      
                            initializes its cryptographic application 
                            (e.g., installing and initializing        
                            software and hardware).                   

  User Registration         A stage in the lifecycle of keying        SP 800-57
                            material; a process whereby an entity     
                            becomes a member of a security domain.    

  []{#GV .anchor}Valid Data A payload, an associated data string, or  SP 800-38C
  Element                   a nonce that satisfies the restrictions   
                            of the formatting function.               

  Validation                The process of demonstrating that the     FIPS 201;
                            system under consideration meets in all   INCITS/M1-040211
                            respects the specification of that        
                            system.                                   

  Verification              The process of affirming that a claimed   FIPS 201
                            identity is correct by comparing the      
                            offered claims of identity with           
                            previously proven information stored in   
                            the identity card or PIV system. See      
                            Identity Verification.                    

  Verified Name             A subscriber name that has been verified  SP 800-63
                            by identity proofing.                     

  Verifier                  An entity that verifies the claimant's    SP 800-63
                            identity by verifying the claimant's      
                            possession of a token using an            
                            authentication protocol. To do this, the  
                            verifier may also need to validate        
                            credentials that link the token and       
                            identity and check their status.          

  Verifier                  An entity which is or represents the      FIPS 196
                            entity requiring an authenticated         
                            identity. A verifier includes the         
                            functions necessary for engaging in       
                            authentication exchanges.                 

  Verifier Impersonation    An attack where the attacker impersonates SP 800-63
  Attack                    the verifier in an authentication         
                            protocol, usually to learn a password.    

  Victim                    A machine that is attacked.               SP 800-61

  Virtual Private Network   A virtual private network is a logical    SP 800-46
  (VPN)                     network that is established, at the       
                            application layer of the Open Systems     
                            Interconnection (OSI) model, over an      
                            existing physical network and typically   
                            does not include every node present on    
                            the physical network.                     

  Virus                     A self-replicating program that runs and  SP 800-61
                            spreads by modifying other programs or    
                            files                                     

  Virus Hoax                An urgent warning message about a         SP 800-61
                            nonexistent virus.                        

  Vulnerability             Weakness in an information system, system SP 800-53; FIPS
                            security procedures, internal controls,   200; CNSSI-4009
                            or implementation that could be exploited Adapted
                            or triggered by a threat source.          

  Vulnerability Assessment  Formal description and evaluation of the  SP 800-53;
                            vulnerabilities in an information system. CNSSI-4009

  []{#GW .anchor}Warez      A term widely used by hackers to denote   SP 800-46
                            illegally copied and distributed          
                            commercial software from which all copy   
                            protection has been removed. Warez often  
                            contains viruses, Trojans and other       
                            malicious code and thus is very risky to  
                            download and use (legal issues            
                            notwithstanding).                         

  Warm Site                 An environmentally conditioned workspace  SP 800-34
                            that is partially equipped with IT and    
                            telecommunications equipment to support   
                            relocated IT operations in the event of a 
                            significant disruption.                   

  Web Bug                   Tiny images, invisible to a user, placed  SP 800-46
                            on web sites in such a way that they      
                            allow third-parties to track use of web   
                            servers and collect information about the 
                            user, including IP address, Host name,    
                            browser type and version, operating       
                            system name and version, and web browser  
                            cookie.                                   

  Wired Equivalent Privacy  Wired Equivalent Privacy, a security      SP 800-46
  (WEP)                     protocol for wireless local area networks 
                            (WLANs) defined in the 802.11b standard.  
                            WEP was intended to provide the same      
                            level of security as that of a wired LAN. 

  Wireless Application      A standard for providing cellular         SP 800-48
  Protocol (WAP)            telephones, pagers, and other handheld    
                            devices with secure access to e-mail and  
                            text-based Web pages                      

  Worm                      A self-replicating, self-propagating,     SP 800-61
                            self-contained program that uses          
                            networking mechanisms to spread itself.   

  Write-Blocker             A device that allows investigators to     SP 800-72
                            examine media while preventing data       
                            writes from occurring on the subject      
                            media.                                    

  X.509 Certificate         The International Organization for        SP 800-57
                            Standardization/International             
                            Telecommunication Union Standardization   
                            Department (ISO/ITU-T) X.509 standard     
                            defined two types of certificates the     
                            X.509 public key certificate, and the     
                            X.509 attribute certificate. Most         
                            commonly (including this document), an    
                            X.509 certificate refers to the X.509     
                            public key certificate.                   

  X.509 Public Key          The public key for a user (or device) and SP 800-57
  Certificate               a name for the user (or device), together 
                            with some other information, rendered     
                            unforgeable by the digital signature of   
                            the certification authority that issued   
                            the certificate, encoded in the format    
                            defined in the ISO/ITU-T X.509 standard.  

  []{#GZ                    A method of erasing electronically stored FIPS 140-2
  .anchor}Zeroization       data, cryptographic keys, and CSPs by     
                            altering or deleting the contents of the  
                            data storage to prevent recovery of the   
                            data.                                     

  Zombie                    A program that is installed on a system   SP 800-83
                            to cause it to attack other systems.      
  ------------------------- ----------------------------------------- ------------------

#  

# Appendix B - NETWORK PERIMETER SECURITY STANDARD 

## Introduction 

The Department of the Interior (DOI) Network Perimeter Security Standard
specifies the minimum requirements for implementing perimeter security
at bureau Internet gateways, Virtual Private Exchange Points (VPX) and
internal security perimeters. This standard specifies the minimum
firewall architecture and configuration.

This standard is based on the basic philosophy of denying access to all
traffic unless specifically permitted. Minimum requirements are listed
in this standard. Bureaus may choose to add to the standards, but they
should take a risk-based approach.

Assurance testing requirements are provided in this standard to help
test and validate the security posture of critical systems.

This standard establishes minimum security requirements for securing DOI
wide area networks at the Internet access points, the Virtual Private
Exchange (VPX) access points and internal network security perimeters.
This standard is written to ensure that adequate protection is in place
to protect DOI data from intruders, file tampering, break in, and
service disruption directed at internal DOI sites from the Internet or
across bureau/office boundaries.

## References 

1.  OMB Circular A-130, Appendix III, Security of Federal Automated
    Information Resources

2.  NIST Special Publication 800-18, Guide for Developing Security Plans
    for Information Technology Systems

3.  NIST Special Publication 800-41, Guidelines on Firewalls and
    Firewall Policies

4.  NIST Special Publication 800-31, Intrusion Detection Systems

5.  CERT Carnegie Mellon, Security Practice, Deploying Firewalls

## Scope 

The scope of this standard is DOI-wide and specifically applies to the
bureau Internet gateways, VPX connections and internal perimeters.
Internet gateways provide Internet access to and from the major bureau
networks. They do not include remote connections that use Internet
Service Providers, such as remote LANs and "work at home" users.

The VPX is a common connection point between bureau wide area networks
and is located in Denver, Colorado. Internal perimeters are created
inside the bureau networks that have different risk levels. For example,
a law enforcement (LE) system may be hosted on a bureau wide area
network. The LE network might have different security requirements than
the general WAN and might use a firewall to isolate the LE LAN from the
bureau network.

## 

## Responsibilities

The responsibility for protecting DOI information resources from
unauthorized access is the responsibility of all DOI employees. This
standard ALSO applies to contractors, franchisees, and State and Tribal
constituencies that are provided network access by DOI.

Employees will access the Internet from the bureau wide area network
only through bureau Internet gateways. 'Backdoor' Internet connections
in the bureau wide area network are not allowed. Any form of
communication to or from workstations outside the internal (trusted)
network is strictly prohibited without review and authorization of the
Bureau Chief Information Security Officer (BCISO). This includes modems,
leased lines to other networks, etc. This does not preclude using ISPs
or other partners to connect remote field sites.

Each Bureau should form a Security Working Group (SWG) to address
network security. The purpose of the group is to identify risks
associated with the network, create/implement risk mitigation solutions
and resolve conflicts associated with implementing network security.
\[Note: bureaus may use a method other than forming a SWG to address
these issues. \]

Bureau Chief Information Officer (CIO):

1.  Is responsible for the overall development, coordination,
    interpretation and approval of IT security policy for the Bureau.

2.  Oversees compliance with Federal and Department policies,
    guidelines, and regulations governing IT security.

3.  Is responsible for reviewing and approving documents prepared by the
    Bureau Security Working Group for the purpose of maintaining network
    security.

4.  Is responsible for development, coordination, and interpretation of
    IT security policy with DOI.

5.  Has the authority to shutdown the Bureau/Office network to protect
    the sensitive and proprietary information and to protect the
    integrity of the Bureau/Office network from a cyber attack.

6.  Appoints the Bureau Chief Information Security Officer who acts as
    the Chairperson of the Security Working Group and directs the SWG in
    meeting its security responsibilities.

Bureau Chief Information Security Officer (BCISO) is responsible for:

1.  Chairing the Security Working Group.

2.  Overseeing the development and implementation of an overall network
    security plan for Bureau systems.

3.  Issuing security policy, guidelines and procedures.

4.  Providing oversight for the Bureau network security program.

Security Working Group (SWG) is responsible for:

1.  The development of Bureau IT network security policies that affect
    the entire Bureau.

2.  Providing recommendations to the CIO about network security issues.

3.  Performing the duties of the Quality Control board on firewall
    related issues.

## 

## Procedures

### Firewall Implementation Guidelines

-   Bureau firewalls will be configured using Industry "best practices"
    including but not limited to the items listed bellow. The firewall
    system will contain the minimum rules specified in Appendix A. Rules
    can be added at the Bureau's discretion, with approval of the SWG.

-   Backbone networks that have asymmetrical routes (i.e. can not be
    protected by stateful devices) must enable security controls on the
    routers. However, stateful security devices must be used at the
    network distribution points.

-   Each DOI network will use a robust and stateful "Firewall System"
    interposed between the Internet and the Bureau network. All Internet
    traffic from inside to outside, and vice-versa, must pass through
    the firewall implementation.

-   Perimeter security architecture for Internet connections will use a
    multi-layered architecture with two firewalls configured in a dual
    firewall design as specified in Appendix B. This configuration
    requires an external and internal firewall.

-   The DMZ (Demilatarized Zone) is the network between the two
    firewalls. The trusted, internal network is the network behind the
    second, internal firewall. See section 5.2 for more information. It
    is acceptable to use a service leg on the external firewall to host
    the DMZ network.

-   Access from the Internet to DOI public information systems must not
    make sensitive information or information systems vulnerable to
    compromise.

-   Where users are required to access internal systems and networks
    from, or across, the Internet, end-to-end encryption (minimum of 128
    bit) and strong authentication will be employed.

-   IP Forwarding between Network Interfaces Cards (NICs) on dual-homed
    firewalls will be disabled by default so that the firewall does not
    route during initialization or after a firewall failure.

-   The firewalls will be configured to deny all services not expressly
    permitted and will be regularly audited and monitored to detect
    intrusions or misuse.

-   The firewall will notify the firewall administrator(s) in near real
    time of any item that impacts the operation of the firewall. The
    firewall administrator will report incidents as per the DOI incident
    response policy.

-   Firewall software for Internet gateways will run on a dedicated
    computer. (This doesn't include Cisco routers that use the Firewall
    Feature Set.) All non-firewall related software, such as compilers,
    editors, communications software, etc., will be deleted or disabled.

-   In the event of a firewall failure, the firewall equipment must
    default to a configuration that denies all services to ensure that
    firewall rules are not bypassed. After recovering from the failure,
    the firewall should use the previously loaded configuration.

-   Source routing will be disabled on all firewalls and external
    routers. Source routing will not be allowed to pass the firewall.

-   Egress filtering will be implemented on border routers to ensure
    that packets do not leave the network with a source IP address other
    than that of the network.

-   The firewall will not accept traffic on its external interfaces that
    appear to be coming from internal network addresses, addressed to
    127.0.0.0/8 or 0.0.0.0.

-   The firewall will provide detailed logs of all sessions that are
    blocked by the firewall so that these logs can be reviewed for any
    anomalies. Logs must be kept for at least 90 days.

-   Log reports will be restricted to only authorized personnel.

-   New firewalls implementations will be tested in a laboratory
    environment before they are put into production.

-   Unless approved by the SWG, all in-bound services will be
    intercepted and processed by the firewall.

-   Appropriate firewall documentation will be maintained at all times.
    Such information will include but not be limited to the network
    diagram, including all IP addresses of all network devices, the IP
    addresses of relevant hosts of the Internet Service Provider (ISP)
    such as external news server, router, DNS server, etc. and all other
    configuration parameters such as packet filter rules, etc. Such
    documentation will be updated daily, if changes are made to the
    configuration.

-   The SWG and firewall administrator(s) will review the network
    security policy and maintenance procedures on a regular basis (every
    three months minimum). Where requirements for network connections
    and services have changed, the security policy will be updated and
    approved.

-   The firewall implementation (system software, configuration data,
    database files, etc.) must be backed up daily, weekly, and monthly
    so that in case of system failure, data and configuration files can
    be recovered. Backup files should be locked up so that the media is
    only accessible to the appropriate personnel.

-   Only the firewall administrator(s) will have privileges for updating
    system executables or other operating system software. Any major or
    significant modification of the firewall architecture or firewall
    software (such as changing firewall vendors) must be done by a
    firewall administrator(s) and requires the formal approval of the
    BCISO.

-   The firewall administrator(s) must evaluate each new release of the
    firewall software to determine if an upgrade is required. All
    security patches should be implemented in a timely manner.

-   All services and traffic to be authorized across the firewall
    implementation must be well documented. The information documented
    will include the business need, protocol used, inbound and/or
    outbound port assignments, known vulnerabilities, and risk
    mitigation statements. This information will be included in the
    perimeter security (or wide area network) security plan and/or risk
    assessment.

-   If application-level proxy firewalls are used, out-bound network
    traffic should appear as if the traffic had originated from the
    firewall (i.e. only the firewall is visible to outside networks).

-   The firewall will be physically secured behind locked doors,
    protected from natural disasters, have backup power and located in a
    room with proper environmental controls.

### DMZ Configuration

-   DOI networks will limit incoming access to data and systems from the
    Internet. This limit will be implemented via use of a Demilitarized
    Zone (DMZ), which is a part of the firewall architecture. Access
    from the DMZ to the internal network will not be permitted unless it
    is specifically required. (For example, a web application that
    accesses a backend database server that is located in the internal
    network is allowed.)

-   Reverse proxy devices may be used in the DMZ to create application
    virtual private networks. The proxy will intercept and analyze
    traffic destined to internal web servers. The proxy will block any
    abnormal traffic and log the event. (For example, the proxy must
    block Code Red scans.)

-   Application proxy servers may be used for outbound traffic, such as
    web or e-mail. If users are required to authenticate to access
    outbound services, the authentication mechanisms must be centralized
    and coordinated with Bureau and Department architecture groups.
    (Specifically, authentication must not require the system firewall
    administrators to operate and maintain a separate user directory
    from any national directories, such as Active Directory.)

-   Hosts residing in the DMZ should use host-based intrusion detection
    systems. At a minimum, they should use a file change detection
    system, such as Tripwire, to detect changes of critical operating
    system files.

**Network Information Dissemination**

Information regarding access to, or configuration of, DOI computer and
communication systems, such as dial-up modem phone numbers or network
diagrams, are considered sensitive but unclassified (SBU). This
information must not be posted on electronic bulletin boards, listed in
telephone directories, placed on business cards, or made available to
third-parties without the written permission of the BCISO.

### Registering Public Servers

All Internet facing devices that provide anonymous public access must be
registered with the Departments Chief Information Security Officer
(CISO). The BCISO will provide the following information for each
server:

-   Fully qualified domain name

-   IP address

-   System administrator contact information (name, phone #)

-   Open ports

-   Server purpose (web server, ftp server, DNS, etc.)

-   Operating System and version (Windows 2000 Server, Solaris, etc.)

The BCISO is responsible for reporting any changes to the CISO in
writing within 2 weeks of the change.

### Intrusion Detection 

Normal logging processes will be enabled on all host and server systems.
Alarm and alert functions, as well as logging, of any firewalls and
other network perimeter access control systems will be enabled.

At a minimum, each firewall system will have one Network based Intrusion
Detection System (IDS) located on the inside of the internal firewall.
Additional IDS equipment may be located in the DMZ and/or outside the
external firewall. IDS equipment must be hardened including the
following.

-   All unused services must be disabled.

-   ICMP must be disabled.

-   The IDS sensor must not be directly accessible from the Internet
    (e.g. users on the Internet must not be able to use secure shell to
    connect.)

-   All transmissions between the management station and the IDS sensor
    must be encrypted.

-   If dual NIC (network interface cards) are used, IP forwarding must
    not be enabled between interfaces.

IDS logs must be reviewed daily and any anomalies reported to the BCISO
as per the DOI incident response policy. IDS log files must be kept for
one month.

Automated IDS systems that adjust firewall rule sets dynamically can be
used, but administrators must monitor the systems to ensure that
unintentional denial of service (DoS) events do not occur. Any DoS
events must be reported as incidents using the DOI incident response
procedures.

### Network Sharing and Trust Relationships with Non-DOI Entities 

The bureau must approve all connections from the Bureau network to
external networks. Connections will be allowed only with external
networks that have been reviewed and found to have acceptable security
controls and procedures. All connections to approved external networks
will pass through firewalls that conform to this standard.

Connections from external networks to internal Bureau networks are
allowed, but must be reviewed and approved by the CIO. (For example, a
vendor may need to directly access internal computers for maintenance
purposes.) In this case, proper controls must be used to ensure that the
vendor cannot launch an internal attack. For example, any connections
from the external network to the internal network must be encrypted and
there should be a firewall in place to limit the access from the
remotely controlled computer to internal resources.

Bureaus may share networks using Virtual Private Networks. There must
not be any local connection behind the VPN and the hosting network. The
connection must be documented and include contact information, network
topology, network security controls and length of sharing agreement.
Bureaus must review their documents annually to ensure that the controls
are still in place and that the network sharing arrangement is still
required.

### Virtual Private Exchange (VPX)

The VPX provides a known path for network traffic between DOI Bureaus,
which limits the probability that Bureau-to-Bureau transmissions will be
intercepted. However, it can provide an attack path from one Bureau to
another, if a computer on a Bureau's internal network is compromised.
Therefore, the VPX must be considered to be at a different trust level
than internal Bureau networks and each Bureau must implement appropriate
security controls.

Bureaus must secure their Bureau network from the VPX using firewall
technology or appropriate router access control lists. Bureaus must deny
access to all traffic to and from the VPX unless expressly permitted. A
dual, sandwich firewall architecture is not required for VPX security.
Changes to the VPX firewall rule set must be coordinated between
Bureaus, approved by the BCISOs of the Bureaus involved and documented.

### 

### Other Perimeter Security Equipment

Other perimeter security equipment may be used, such as layer 2
switches, application layer switches, reverse proxies, proxies, VPN
concentrators and routers. This equipment must be properly secured,
hardened and kept fully patched to reduce the possibility of compromise.
Mandatory configuration parameters are listed below.

-   Management access should use encryption (minimum of 128 bit), if it
    is available. (For example, SSH or TLS should be used.)

-   Management access via Telnet must be limited to specific IP
    addresses and the device must not be accessed using Telnet from the
    Internet.

-   Users must be authenticated. Passwords must conform to DOI password
    policy.

-   Logging will be enabled and the logs must be kept for at least 30
    days.

-   Devices will be synced to the wide area network time standard.

The SWG or BCISO will approve all major configuration changes.

### Internal Security Perimeter

The Bureau SWG will identify internal systems that have different risk
levels than the general wide area network. These systems will be secured
from the internal bureau WANs using firewalls or other network security
devices. (e.g. routers with access control lists.) Aside from the
following exceptions, internal firewalls will be configured as described
in this standard.

-   Dual firewall architectures are not required for internal
    perimeters.

-   Firewall rule sets must be configured to deny access to all unless
    expressly permitted. This will be a different configuration than
    listed in Appendix A. The rule set will be specific to the system.

The system security officer and system owner are responsible for
determining the firewall rule set.

Internal firewall implementations will be coordinated with the BCISO.

## Network Assurance Testing

Each bureau must create a network vulnerability testing process and a
patch management process for hosts and devices that are exposed to the
Internet. The same processes should be applied to internal bureau
systems that have higher risk levels than typical workstations connected
to the wide area network. (For example, law enforcement systems,
financial systems, etc.)

### Network Vulnerability Testing

Bureaus will conduct network vulnerability tests to ensure that Internet
facing devices do not have exposed vulnerabilities. Systems must be
routinely scanned with a vulnerability scanner from the TRM. The
SANS/FBI Top 20 list must be used as a baseline for the tests. After
significant improvement is made reducing these vulnerabilities,
additional vulnerability tests must be added to the test procedures.

Internal network perimeters should also be tested. Scanning can be
conducted from a central location in the bureau wide area network to
simulate access of a typical workstation connected to the wide area
network. The same general procedures for testing Internet facing devices
can be used.

Testing must be done at least monthly and reports must be sent to the
system administrators and BCISO for remediation. System administrators
are responsible for remediating any discovered vulnerabilities as soon
as possible. The bureau's network assurance testing procedures must
include the following at a minimum:

-   Monthly vulnerability scans of Internet facing devices

-   Notification to system administrators that the scans will occur

-   Summary reports for the BCISO and system administrator including

-   IP address of device

-   Vulnerability discovered

-   Risk Level of Vulnerability

-   Status of vulnerability (recurring, new, etc.)

-   Workflow to allow system administrators to track vulnerabilities and
    mark false positives

-   Monthly report to the CISO (Departments Chief Information Security
    Officer) showing vulnerability trends. The reports must use a
    consistent format to allow monthly comparisons of the network
    security posture.

### Patches

Bureaus will test Internet facing hosts to ensure that the computer has
the appropriate patches installed. An automated tool such as the
Microsoft Baseline Security Analyzer or the Center for Internet Security
scoring tool must be used to verify the installed patches. Patches
should be tested in a non-production environment before they are applied
to production servers to ensure that the patches do not affect the
existing production applications. All system upgrades must be
documented.

## NETWORK PERIMETER SECURITY STANDARD - Appendix A

Minimum Firewall Rules

The following tables specify the **minimum** firewall rules for bureau
Internet gateways. They govern traffic that flows between the Internet,
DMZ and internal networks.

A waiver is **not** required to deviate from these rules. The bureau can
add (or remove) rules, but they must be based on sound, business reasons
and have an approval process to adopt them. Rules in addition to those
specified here must be included in the bureau WAN (wide area network)
security plan and addressed in the WAN risk assessment document.

The "Status" column indicates whether users can use the service and the
"Auth" column indicates whether any form of authentication is required.

Internet-DMZ Rules

These rules govern the communications between the Internet and the DMZ.
Access using these services must be limited to specific hosts.

+------+-------+-----+-------+-----+---------------------------------+
|      | Sta   |     |       |     |                                 |
|      | ndard |     |       |     |                                 |
+======+=======+=====+=======+=====+=================================+
| Ser  | Int   |     | DMZ   |     | Standard                        |
| vice | ernet |     | to    |     |                                 |
|      | to    |     | Int   |     |                                 |
|      | DMZ   |     | ernet |     |                                 |
+------+-------+-----+-------+-----+---------------------------------+
|      | S     | A   | S     | A   |                                 |
|      | tatus | uth | tatus | uth |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| FTP  | Yes   | Yes | No    | No  | FTP may not be used for the     |
|      |       |     |       |     | transmission of PII and/or      |
|      |       |     |       |     | sensitive information.          |
|      |       |     |       |     |                                 |
|      |       |     |       |     | FTP servers must reside in the  |
|      |       |     |       |     | DMZ or be proxied from the DMZ. |
|      |       |     |       |     |                                 |
|      |       |     |       |     | A C&A (major application) must  |
|      |       |     |       |     | be performed for each FTP       |
|      |       |     |       |     | server/service.                 |
+------+-------+-----+-------+-----+---------------------------------+
| SSH  | Yes   | No  | No    | No  | SSH is the preferred method of  |
|      |       |     |       |     | accessing a remote shell        |
|      |       |     |       |     | account.                        |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Incoming SSH must be restricted |
|      |       |     |       |     | to specific devices and not     |
|      |       |     |       |     | enabled on a network-wide       |
|      |       |     |       |     | basis.                          |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Users must authenticate for     |
|      |       |     |       |     | incoming services.              |
+------+-------+-----+-------+-----+---------------------------------+
| HTTP | Yes   | No  | No    | No  | All WWW servers accessible from |
|      |       |     |       |     | the Internet will be hosted in  |
|      |       |     |       |     | the bureau's DMZ.               |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Bureaus may proxy internal web  |
|      |       |     |       |     | sites with a proxy server       |
|      |       |     |       |     | located in the DMZ.             |
+------+-------+-----+-------+-----+---------------------------------+
| TLS  | Yes   | No  | No    | No  |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| N    | Yes   | Yes | Yes   | Yes | Requires two-factor             |
| otes |       |     |       |     | authentication and encryption   |
|      |       |     |       |     | of all associated traffic.      |
+------+-------+-----+-------+-----+---------------------------------+
| SMTP | Yes   | No  | Yes   | No  | SMTP is only allowed to and     |
|      |       |     |       |     | from specific Bureau SMTP       |
|      |       |     |       |     | servers.                        |
+------+-------+-----+-------+-----+---------------------------------+
| NNTP | Yes   | No  | Yes   | No  | No external access will be      |
|      |       |     |       |     | allowed to internal NNTP        |
|      |       |     |       |     | servers.                        |
+------+-------+-----+-------+-----+---------------------------------+
| DNS  | Yes   | No  | Yes   | No  |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| O    | No    | No  | No    | No  | Access to any other service not |
| ther |       |     |       |     | mentioned above will be denied  |
|      |       |     |       |     | in both directions.             |
+------+-------+-----+-------+-----+---------------------------------+

## NETWORK PERIMETER SECURITY STANDARD - DMZ-Internal Rules

These rules govern the communications between the DMZ and the internal
network. Access must be limited to specific hosts in the DMZ.

+-------+-------+-----+-------+-----+---------------------------------+
|       | Sta   |     |       |     |                                 |
|       | ndard |     |       |     |                                 |
+=======+=======+=====+=======+=====+=================================+
| Se    | Int   |     | DMZ   |     | Standard                        |
| rvice | ernal |     | to    |     |                                 |
|       | to    |     | Int   |     |                                 |
|       | DMZ   |     | ernal |     |                                 |
+-------+-------+-----+-------+-----+---------------------------------+
|       | S     | A   | S     | A   |                                 |
|       | tatus | uth | tatus | uth |                                 |
+-------+-------+-----+-------+-----+---------------------------------+
| FTP   | Yes   | Yes | No    | No  | FTP may not be used for the     |
|       |       |     |       |     | transmission of PII and/or      |
|       |       |     |       |     | sensitive information.          |
|       |       |     |       |     |                                 |
|       |       |     |       |     | A C&A (major application) must  |
|       |       |     |       |     | be performed for each FTP       |
|       |       |     |       |     | server/service.                 |
+-------+-------+-----+-------+-----+---------------------------------+
| T     | Yes   | No  | No    | No  | SSH is preferred.               |
| elnet |       |     |       |     |                                 |
+-------+-------+-----+-------+-----+---------------------------------+
| SSH   | Yes   | Yes | No    | No  | SSH is the preferred method of  |
|       |       |     |       |     | accessing a remote shell        |
|       |       |     |       |     | account.                        |
|       |       |     |       |     |                                 |
|       |       |     |       |     | Users must authenticate for     |
|       |       |     |       |     | incoming services.              |
+-------+-------+-----+-------+-----+---------------------------------+
| HTTP  | Yes   | No  | No    | No  |                                 |
+-------+-------+-----+-------+-----+---------------------------------+
| TLS   | Yes   | No  | No    | No  |                                 |
+-------+-------+-----+-------+-----+---------------------------------+
| Notes | Yes   | Yes | Yes   | Yes | Lotus Notes client to server is |
|       |       |     |       |     | allowed.                        |
|       |       |     |       |     |                                 |
|       |       |     |       |     | The client must authenticate to |
|       |       |     |       |     | the server and port encryption  |
|       |       |     |       |     | must be enabled (server         |
|       |       |     |       |     | setting).                       |
+-------+-------+-----+-------+-----+---------------------------------+
| SMTP  | Yes   | No  | Yes   | No  | SMTP is only allowed to and     |
|       |       |     |       |     | from specific Bureau SMTP       |
|       |       |     |       |     | servers.                        |
|       |       |     |       |     |                                 |
|       |       |     |       |     | Workstations will not be        |
|       |       |     |       |     | allowed to function as mail     |
|       |       |     |       |     | servers.                        |
+-------+-------+-----+-------+-----+---------------------------------+
| SQL   | Yes   | Yes | Yes   | Yes | Connections from a web server   |
|       |       |     |       |     | running a database application  |
|       |       |     |       |     | in the DMZ to an internal       |
|       |       |     |       |     | database are allowed.           |
|       |       |     |       |     |                                 |
|       |       |     |       |     | Connections must use            |
|       |       |     |       |     | authentication.                 |
+-------+-------+-----+-------+-----+---------------------------------+
| DNS   | Yes   | No  | Yes   | No  |                                 |
+-------+-------+-----+-------+-----+---------------------------------+
| Other | No    | No  | No    | No  | Access to any other service not |
|       |       |     |       |     | mentioned above will be denied  |
|       |       |     |       |     | in both directions.             |
+-------+-------+-----+-------+-----+---------------------------------+

## NETWORK PERIMETER SECURITY STANDARD - Internet-Internal Rules

These rules govern the communications between the Internet and the
internal network. Note that both the incoming and outgoing rules are to
deny all unless expressly permitted.

+------+-------+-----+-------+-----+---------------------------------+
|      | Sta   |     |       |     |                                 |
|      | ndard |     |       |     |                                 |
+======+=======+=====+=======+=====+=================================+
| Ser  | Int   |     | Int   |     | Standard                        |
| vice | ernet |     | ernal |     |                                 |
|      | to    |     | to    |     |                                 |
|      | Int   |     | Int   |     |                                 |
|      | ernal |     | ernet |     |                                 |
+------+-------+-----+-------+-----+---------------------------------+
|      | S     | A   | S     | A   |                                 |
|      | tatus | uth | tatus | uth |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| FTP  | No    | No  | Yes   | No  | FTP may not be used for the     |
|      |       |     |       |     | transmission of PII and/or      |
|      |       |     |       |     | sensitive information.          |
|      |       |     |       |     |                                 |
|      |       |     |       |     | A C&A (major application) must  |
|      |       |     |       |     | be performed for each FTP       |
|      |       |     |       |     | server/service.                 |
|      |       |     |       |     |                                 |
|      |       |     |       |     | FTP servers must reside in the  |
|      |       |     |       |     | DMZ or be proxied from the DMZ. |
+------+-------+-----+-------+-----+---------------------------------+
| Te   | No    | No  | Yes   | Yes | Telnet access will be allowed   |
| lnet |       |     |       |     | from the inside network to the  |
|      |       |     |       |     | outside network. However, note  |
|      |       |     |       |     | that transmissions are in the   |
|      |       |     |       |     | clear.                          |
|      |       |     |       |     |                                 |
|      |       |     |       |     | For telnet from the outside to  |
|      |       |     |       |     | the inside network VPN will be  |
|      |       |     |       |     | required.                       |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Telnet to remote network        |
|      |       |     |       |     | devices must be encrypted. SSH  |
|      |       |     |       |     | is preferred.                   |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Note that TN3270 sessions use   |
|      |       |     |       |     | telnet services.                |
+------+-------+-----+-------+-----+---------------------------------+
| SSH  | Yes   | Yes | Yes   | Yes | SSH is the preferred method of  |
|      |       |     |       |     | accessing a remote shell        |
|      |       |     |       |     | account.                        |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Incoming SSH must be restricted |
|      |       |     |       |     | to specific devices and not     |
|      |       |     |       |     | enabled on a network-wide       |
|      |       |     |       |     | basis.                          |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Users must authenticate for     |
|      |       |     |       |     | incoming services.              |
+------+-------+-----+-------+-----+---------------------------------+
| HTTP | No    | No  | Yes   | No  | All WWW servers accessible from |
|      |       |     |       |     | the Internet will be hosted in  |
|      |       |     |       |     | the bureau's DMZ.               |
|      |       |     |       |     |                                 |
|      |       |     |       |     | No inbound HTTP will be allowed |
|      |       |     |       |     | through the firewall.           |
+------+-------+-----+-------+-----+---------------------------------+
| TLS  | Yes   | Yes | Yes   | No  | Secure Sockets Layer sessions   |
|      |       |     |       |     | using client side certificates, |
|      |       |     |       |     | strong passwords or multifactor |
|      |       |     |       |     | authentication is required when |
|      |       |     |       |     | TLS sessions are to be passed   |
|      |       |     |       |     | through the bureau firewall.    |
+------+-------+-----+-------+-----+---------------------------------+
| N    | Yes   | Yes | Yes   | Yes | Requires two-factor             |
| otes |       |     |       |     | authentication and encryption   |
|      |       |     |       |     | of all associated traffic.      |
+------+-------+-----+-------+-----+---------------------------------+
| SMTP | Yes   | No  | Yes   | No  | SMTP is only allowed to and     |
|      |       |     |       |     | from specific Bureau SMTP       |
|      |       |     |       |     | servers.                        |
|      |       |     |       |     |                                 |
|      |       |     |       |     | Workstations will not be        |
|      |       |     |       |     | allowed to function as mail     |
|      |       |     |       |     | servers.                        |
+------+-------+-----+-------+-----+---------------------------------+
| NNTP | No    | No  | Yes   | No  | No external access will be      |
|      |       |     |       |     | allowed to internal NNTP        |
|      |       |     |       |     | servers.                        |
+------+-------+-----+-------+-----+---------------------------------+
| Fi   | No    | No  | Yes   | No  |                                 |
| nger |       |     |       |     |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| Go   | No    | No  | Yes   | No  |                                 |
| pher |       |     |       |     |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| W    | Yes   | No  | Yes   | No  |                                 |
| hois |       |     |       |     |                                 |
+------+-------+-----+-------+-----+---------------------------------+
| SQL  | No    | No  | Yes   | No  | Unencrypted and unauthenticated |
|      |       |     |       |     | direct connections from         |
|      |       |     |       |     | Internet hosts to internal      |
|      |       |     |       |     | databases are not allowed.      |
+------+-------+-----+-------+-----+---------------------------------+
| DNS  | Yes   | No  | Yes   | No  | All bureau DNS servers should   |
|      |       |     |       |     | be located in a DMZ.            |
+------+-------+-----+-------+-----+---------------------------------+
| O    | No    | No  | No    | No  | Access to any other service not |
| ther |       |     |       |     | mentioned above will be denied  |
|      |       |     |       |     | in both directions.             |
+------+-------+-----+-------+-----+---------------------------------+

## 

## 

## 

## 

## 

## 

## 

## 

## 

## 

## NETWORK PERIMETER SECURITY STANDARD - Appendix B -- Dual Firewall Architecture

Communications from the Internet to the Internal network must pass
through two firewalls. The DMZ may be either the network between the two
firewalls (a) or a third interface on the external firewall (b.)

![](media/image3.wmf)

#  

# Appendix C

## Wireless Security Technical Implementation Guide (Version 2.0, July 15, 2005)

### Introduction

Wireless communications offer organizations and users many benefits such
as portability and flexibility, increased productivity, and lower
installation costs. Wireless technologies cover a broad range of
differing capabilities oriented toward different uses and needs.
Wireless local area network (WLAN) devices, for instance, allow users to
move their laptops from place to place within their offices without the
need for wires and without losing network connectivity. Less wiring
means greater flexibility, increased efficiency, and reduced wiring
costs. Ad hoc networks, such as those enabled by Bluetooth, allow data
synchronization with network systems and application sharing between
devices. Bluetooth functionality also eliminates cables for printer and
other peripheral device connections. Handheld devices such as personal
digital assistants (PDA) and cell phones allow remote users to
synchronize personal databases and provide access to network services
such as wireless e-mail, Web browsing, and Internet access. Moreover,
these technologies can offer dramatic cost savings and new capabilities
to diverse applications ranging from retail settings to manufacturing
shop floors to first responders.

However, risks are inherent in any wireless technology. Some of these
risks are similar to those of wired networks; some are exacerbated by
wireless connectivity; some are new. Perhaps the most significant source
of risks in wireless networks is that the technology's underlying
communications medium, the airwave, is open to intruders, making it the
logical equivalent of an Ethernet port in the parking lot.

This security technical implementation guide (STIG) follows the National
Institute of Standards and Technology (NIST) Special Publication (SP)
800-48; *Wireless Network Security - 802.11, Bluetooth, and Handheld
Devices.* Security standards for the 802.11 series of wireless Ethernet
protocols developed by the Institute of Electrical and Electronics
Engineers (IEEE), Bluetooth ad-hoc networking technology, and handheld
devices such as smart phones, tablets, and Internet-enabled Personal
Digital Assistants are outlined below.

### WLAN Security Features

802.11 WLANs provide a number of rudimentary security mechanisms that
can be effective for protecting against curious, unauthorized users who
try to access an organization\'s WLAN resources. Unfortunately, numerous
deficiencies in these security mechanisms - and in the 802.11 WLAN
protocols themselves - limit their effectiveness against a determined
adversary. Against such an opponent, an organization\'s spectrum of risk
ranges from Denial-of-Service (DoS) attacks at best, to the complete
compromise of wired and wireless networks at worst.

The major security features of 802.11 WLANs consist of Wi-Fi Protected
Access (WPA), Wired Equivalent Privacy (WEP) encryption and Media Access
Control (MAC) address filtering.

Wi-Fi Protected Access Encryption

Wi-Fi Protected Access (WPA) has been designed to replace the older
Wireless Encryption Privacy (WEP) encryption mechanism. It provides
improved data encryption, which was weak in WEP, and to provide user
authentication, which was for the most part missing in WEP. WPA utilizes
its Temporal Key Integrity Protocol (TKIP) for improved data encryption.
TKIP addresses all of the known vulnerabilities in WEP and implements
802.1x and the Extensible Authentication Protocol (EAP) to strengthen
user authentication. The second generation of WPA security is WPA2 based
on the final IEEE 802.11i amendment to the 802.11 standard and is
eligible for FIPS 140-2 compliance. WPA2 provides a stronger encryption
mechanism through Advanced Encryption Standard (AES), which is a
requirement for some corporate and government users.

### Wired Equivalent Privacy Encryption

Wired Equivalent Privacy (WEP) encryption was designed to provide a
modest level of confidentiality across an 802.11 WLAN, similar to that
provided by a traditional wired Ethernet network. (With a wired Ethernet
network, for example, users not connected to the LAN are unable to
communicate on the LAN.) Unfortunately, design and implementation flaws
in WEP negate the minimal security that it was intended to provide.
These flaws potentially allow a determined adversary to compromise in
seconds the encryption keys used on a heavily utilized WLAN.

Despite WEP\'s weaknesses, WEP does provide an essential measure of
security for limiting unauthorized access to the WLAN and its data.

### MAC Address Filtering

All 802.11 network cards are uniquely identified by a MAC (Media Access
Control) address, provided by the card\'s vendor at the time of
manufacture. WLAN access points can be programmed with a list of MAC
addresses for those client computers that are permitted to access the
access point and, therefore, the WLAN. If the list does not have the MAC
address of a client computer\'s network card, the client cannot
associate with the access point. Unfortunately, MAC address filtering
does not provide significant security, as it is possible for a malicious
user to steal an authorized network card\'s MAC address and impersonate
that authorized network card. Note that because the address list must be
kept up-to-date, MAC address filtering entails considerable
administrative overhead. Still, MAC address filtering provides some
security by preventing WLAN access from network cards used by less
determined, or casual, unauthorized users.

### Enhancing WLAN Security

The usefulness of 802.11 WLANs is undercut by their inherent security
deficiencies. As such, additional security measures must be taken to
minimize security exposures. Mechanisms such as network
compartmentalization, rapid WEP rekeying, and the use of Virtual Private
Networks (VPNs) and physical controls can bolster security to some
extent.

### Network Compartmentalization

Treating 802.11 WLANs as untrusted networks and segregating them from
internal, wired networks are important first steps in limiting an
organization\'s security exposure from deploying WLANs. WLANs should be
separated in much the same way that an organization uses firewalls to
separate its internal networks from the Internet.

### Rapid WEP Rekeying

Among the ongoing stopgap, incremental improvements to WEP are rapid WEP
rekeying mechanisms such as the Temporal Key Integrity Protocol (TKIP).
TKIP generates a new WEP encryption key each time a certain amount of
user data is transmitted. Because TKIP utilizes WEP, TKIP is vulnerable
to the same attacks as WEP. However, TKIP dramatically reduces both the
window for launching an attack against WEP, as well as the time in which
discovered WEP keys are useful to an attacker.

### Virtual Private Networks (VPNs)

Third-party Virtual Private Networks (VPNs) offer a possible means for
mitigating the poor authentication and confidentiality mechanisms
provided by the 802.11 WLAN protocols. VPN solutions can be applied to
WLANs in much the same way that they are applied to securing
point-to-point Internet communications. Depending on need, other
point-to-point encryption and authentication solutions, such as Secure
Shell (SSH), may also be suitable for helping to secure WLAN traffic.

### Physical Controls

Due to the nature of 802.11 WLANs, security controls for them must
extend outside the physical boundaries of an organization, for example
to the parking lot, in order to defend against intruders attempting to
intercept or inject wireless traffic. Alert security guards and staff,
combined with restricted access to a WLAN\'s physical components -
antennas, access points, cables, etc. - are key components of a secure
WLAN, and should not be ignored or underestimated.

Wireless access points must be physically located where there are
appropriate physical access controls preventing unauthorized users from
accessing the access point so as to prevent malicious or
unauthorized/unintentional tampering with device(s) and must not be
located in a "common area".

### Summary

Despite the significant security risks, many organizations are deploying
802.11 WLANs as a means of enhancing productivity through mobility.
Fortunately, many steps can be taken to significantly reduce the risks
of deploying 802.11 WLANs. The next chapter outlines these measures.

### Intended Audience

The Intended Audience for this publication is personnel responsible for
deploying and maintaining the security of 802.11 wireless Ethernet
devices and related infrastructure within an organization. The following
personnel typically use the standards provided in this publication:

-   *Information Systems Personnel* consists of organizational members
    who are assigned tasks to support and maintain operations, along
    with supporting and maintaining the health of the network and
    network elements. Their involvement in understanding the security
    policies and procedures that are enforced by the organization is
    critical, since they are required to conform to the standards and
    encourage their acceptance by the user community.

-   *Security Administrators* typically include personnel that are
    dedicated to perform security-related tasks across an
    organization\'s infrastructure. These tasks include the issuance of
    user accounts, creation and segregation of user communities (for
    example, users and groups), and management of security controls. In
    addition, they are involved with the development of policies and
    procedures related to the operations of the organization.

-   *System and Network Administrators* are responsible for operating
    and running the network and related network elements. In addition to
    their long list of other tasks, ensuring availability, integrity,
    and security are key responsibilities. Thus, their familiarity with
    asset protection standards is essential in maintaining conformance
    to organizational standards.

-   *Security Auditors* are involved in maintaining conformance to the
    standards, organizational policies, and procedures through
    inspection reviews. Knowledge of the organizational guidelines is
    essential to their work.

-   *Business Managers* consist of business executives who regularly
    interact with the above personnel or who seek to broaden their
    knowledge of Information Security issues.

To comprehend and properly implement the requirements described in this
publication, the reader should have an adequate level of understanding
of 802.11 wireless Ethernet, networking protocols and concepts, as well
as basic security concepts (for example, authentication, permissions,
and exploits).

### Naming Conventions

Requirements and suggested considerations are identified in this
publication through the use of the RQ and SC symbols, respectively.

A *requirement (RQ)* symbol indicates a requirement related to an 802.11
wireless Ethernet security control that **must be** implemented for
establishing a base level of security. A *suggested considerations*
*(SC)* builds upon stated requirements to provide enhanced assurance for
environments that need a higher level of security.

For both RQs and SCs, the number following the symbol (for example,
RQ-*5*) distinguishes one requirement from another. This numbering
method helps personnel to reference specific requirements during
implementation, or when auditing the respective technology. It also
provides an effective means to reference and locate specific
requirements across this system\'s publications.

### Requirements

### Introduction

This chapter discusses the security standards required to provide a base
level of protection for 802.11 wireless Ethernet devices. The objectives
of this STIG are:

1.  Protect the confidentiality and integrity of the data during
    transmission when required;

2.  Protect the physical network from unauthorized access from the
    wireless access point connected to the physical network.

The protections are grouped according to the following asset protection
standards:

-   Physical Access

-   System Access

-   Remote Access

-   Encryption

-   Integrity Protection

-   Information Handling

-   Auditing

-   Availability Protection

-   Anti-Virus

The recommendations made in this guide are generally applicable across
all 802.11 wireless Ethernet devices conforming to the presently
available 802.11, 802.11a, and 802.11b protocol standards. The
information in this guide should also apply to devices conforming to the
forthcoming 802.11g protocol standards. Consideration is also given to
current and draft security-related extensions to the 802.11 protocols,
such as 802.1x and 802.11i, where applicable.

Note that it may not be possible to implement some of the
recommendations made in this guide to all 802.11-compliant products.
This is due to differences in vendor implementations or lack of support
for optional portions of the 802.11 protocol specifications.

The sections on Bluetooth and Handheld Devices are also broken down into
RQ and SC but under the following headings:

-   Management

-   Technical

-   Operational

As with the WLAN information, an appendix (D and E) provides a security
checklist for the requirements and suggested considerations.

### Physical Access

Physical security is a critical element of an overall security program.
Without physical security, virtually all other safeguards can be
rendered useless. For example, a malicious user might gain access to an
organization\'s systems, unplug them, and walk out the door with them.
Lesser degrees of unwanted physical access can also lead to system and
network compromise.

With 802.11 Wireless Local Area Networks (WLANs), physical security
concerns are potentially of greater issue than with other systems an
organization deploys. Due to the nature of wireless networking, security
controls often must extend outside of an organization\'s perimeter -
such as to the parking lot or sidewalk - to protect against malicious
users that may be trying to intercept or introduce network traffic.

The following requirements define general baseline standards for
protecting the hardware assets that comprise an organization\'s 802.11xx
WLAN deployment:

**RQ-1** Antennas and related cabling supporting 802.11 WLANs must be
kept in a secure area where access is restricted to authorized
personnel. Wireless access points must be physically located where there
are appropriate physical access controls preventing unauthorized users
from accessing the access point so as to prevent malicious or
unauthorized/unintentional tampering with device(s) and must not be
located in a "common area". If a malicious user gains access to the
antennas, network security measures can in many cases be circumvented.
Such circumvention can occur as a result of re-positioning antennas,
replacing antennas, or installing amplification devices so that
malicious users can more easily access an organization\'s network from
outside of the organization\'s premises.

**RQ-2** WLAN access points must be kept in a secured closet or
enclosure where access is restricted to authorized personnel. If a
malicious user can gain access to the access point, he might be able to
circumvent all access point and network security measures. This can be
done through the wholesale replacement of the access point, through
password recovery mechanisms, or by replacing or resetting device
configurations. It is also possible to replace access point operating
systems with malicious code. Such code, for example, could send a
malicious user a copy of all data passing through an access point via
the Internet.

**RQ-3** WLAN-enabled client stations must be protected from loss or
theft; gaining access to a client may allow an unauthorized user
unrestricted access to an organization\'s network. This concern is not
unique to WLAN-enabled clients, but also applies to any client
configured to remotely access an organization\'s network, such as via a
dial-up Virtual Private Network (VPN).

**RQ-4** Loss or theft of a WLAN-enabled client station or network card
must be immediately reported to the network security team or other
appropriate, designated group within an organization that may take
appropriate measures. Such measures include revoking client station or
network card access to the network via Media Access Control (MAC)
filtering or changing Wired Equivalent Privacy (WEP) encryption keys.

**RQ-5** Physical security teams, such as the security guards in a
building, must be educated on general wireless security risks and
instructed to watch for interlopers with antennas, laptops, personal
digital assistants, or similar equipment, who may be loitering in
lobbies, parking lots, or sidewalks to intercept or interfere with
transmissions.

**RQ-6** Physical security teams must be instructed to watch for
unauthorized, rogue WLAN access points that may be installed. Such
access points may be installed by employees with good or bad motives, or
by malicious users seeking an easy method of access into an
organization\'s network. In the latter case, it is not uncommon to
install hidden access points in common areas such as conference rooms or
lobbies.

**SC-1** Access to secured facilities, closets, or enclosures should be
controlled and logged. For facilities and closets, mechanisms such as an
electronic key card system can accomplish this. For enclosures, sign-out
procedures with keys can be implemented. Access logs should be regularly
reviewed for compromise or for abnormal access patterns.

**SC-2** Secured facility, closet, or lock box access lists should be
regularly audited to ensure that people with keys or key cards do still
require access.

**SC-3** Security teams should conduct wireless site surveys of their
organization to identify and locate unauthorized WLAN access points.
When looking for unauthorized wireless access points, be cure to
consider all characteristics including SSID (Service Set Identifier),
WEP use, and MAC address. Pointers to site survey tools can be found in
the Appendix in the section 802.11 Wireless Ethernet Security Tools.

### System Access

Managing system access, like controlling physical access, is a critical
part of an organization\'s Information Security program. WLAN system
access is governed through the identification and authentication of
devices or users that interact with a given system such as an 802.11
WLAN, or specific WLAN components. Unlike more robust access policies
seen with operating systems, authorization to access WLAN resources is
implicit upon successful authentication.

Unfortunately, present-day 802.11 WLAN implementations complicate the
effective management of system access, due to deficiencies and
limitations in the native 802.11 identification and authentication
mechanisms.

Despite these deficiencies, steps can be taken to enhance system access
security from the perspectives of both WLAN devices and administrative
users that configure the WLAN.

### Identification

The identification process provides a means for devices, networks, or
users to convey their identities. A pre-determined identifier (for
example, a user ID or SSID) is used to distinguish one device, network,
or user from another.

WLAN

SSIDs are used to identify 802.11 WLANs, and allow a WLAN client station
to associate with a specific WLAN, or service set, in the event that
multiple service sets are available. Irrespective of encryption
settings, SSID information is transmitted across the WLAN in plain text
for all within range to receive it - regardless of whether the recipient
is authorized or not.

**RQ-7** The SSID used to identify a WLAN must be changed from the
vendor default. Although it is trivial to discover the SSID assigned to
a WLAN, default SSIDs are often an indicator that a WLAN has not been
secured and may be sufficient enticement for the curious to investigate.

**RQ-8** SSIDs must not provide potentially useful information to
malicious users. Do not set SSIDs to values such as your organization\'s
name, address, floor, or department. For example, an SSID of
\"MegaCorp - 4th floor - finance\" may provide an attractive target.

**SC-4** Access point responses to broadcast SSID probe requests (that
is, the \"ANY\" SSID) should be disabled, if possible. Disabling
responses to broadcast probe requests will prevent access points from
being seen by some - but not all - site survey tools. Additionally,
disabling broadcast probe requests may cause some access points to
obscure their SSID name when transmitting 802.11 management frames.

**SC-5** Despite the potential benefit of operating in this mode,
disabling responses to broadcast SSID probe requests violates the 802.11
protocol specification. This causes difficulties with Windows XP and
other applications or operating systems that expect a response to
broadcast SSID probe requests.

Note that not responding to broadcast probe requests does not eliminate
SSID transmissions in their entirety, and does not prevent the existence
of an access point from being discovered by passive site survey tools
such as Kismet or passive sniffers such as AiroPeek.

Also note that not all vendors provide a mechanism to disable responses
to broadcast SSID probe requests. A sample of vendors that do provide a
mechanism to disable responses to broadcast SSID probe requests refer to
it as \"Broadcast WLAN Service Area\" (3Com), \"Closed Network\"
(Agere/Lucent), \"Broadcast SSID\" (Cisco), \"SSID Broadcasting\"
(Linksys), or \"Broadcast ESSID\" (Symbol).

WLAN client stations should have the SSID they seek to associate with
hard-coded in their configuration instead of automatically scanning for
any available access point to associate with. Explicitly setting the
SSID is required when WLAN SSID broadcasts have been disabled as in
SC-4. It can also help the client station to avoid establishing
associations with unintended access points.

### Client Station or User

The original 802.11 WLAN protocols did not provide a mechanism for
identifying the individual WLAN client station or user that was
attempting to access the WLAN. However, a recent extension to the 802.11
protocols does allow for the identification of individual WLAN clients
stations or users. This extension is known as 802.1x - Port-base Network
Access Control. Another option for providing client station or user
identification is through the use of a Virtual Private Network (VPN).

Note that if neither 802.1x nor VPN mechanisms are used to provide for
individual client station or user identification, then the following
requirements are likely not applicable.

**RQ-9** Each user account - whether it represents a person or a client
station - must have a unique account identifier that identifies one, and
only one, entity within the organization. This uniqueness must be
maintained even if two identically named users (for example, John Doe in
network engineering, and John Doe in marketing) will never have an
account within the same administrative context or network.

**RQ-10** User communities or working groups must not share a single
user ID for WLAN access. Each user must access the WLAN by using his
unique user ID to ensure accurate accounting of user access and actions.

**RQ-11** All users must have a meaningful description and naming
convention for the purpose of effortless identification and tracking.
Meaningful descriptions minimize the chance of accidental administrative
actions such as deactivating the wrong user. They also simplify the
interpretation of auditing reports, and can assist in forensic analysis.

Note that \"security through obscurity,\" such as using confusing,
cryptic, or intentionally misleading naming conventions, does not
present a significant obstacle to a malicious user. However, such
schemes can greatly impair the ability of authorized users to properly
use and manage a WLAN.

**RQ-12** All WLANs require every user be uniquely identified by
employing his user ID prior to gaining access to the WLAN.

**RQ-13** Accounts must be deactivated within 24 hours, if not sooner,
of notification of a status change (for example, employee termination or
change in job, or if a WLAN client station is lost or stolen).

**RQ-14** Unused, dormant accounts or accounts of terminated employees
must be disabled, and subsequently deleted, according to organizational
policy.

**SC-6** If possible, user identification should be performed instead of
client station identification. Identifying individual users provides for
better auditing, particularly in situations where multiple users may
share the same client station.

WLAN Access Point Administration

Few WLAN access points support the concept of named administrative
accounts. However, the following recommendations apply to those access
points that do support named administrative accounts.

**RQ-15** If the WLAN access point\'s management interface supports the
identification of individual users, the applicable requirements outlined
above for Client Station or User must be followed.

**RQ-16** Unused, vendor-supplied, default accounts must be disabled or
deleted, as provided for by the WLAN access point\'s management
interface. In cases where default accounts are disabled or cannot be
deleted, those accounts should be assigned a strong password (see RQ-23
below).

### Authentication

Identification alone does not prove that a client station or user should
be granted access to a WLAN access point or network. Instead, that
identity must be confirmed through the use of a pre-defined secret, such
as a password, or by verifying some other trusted credential such as a
digital certificate or Kerberos ticket. The process of verifying the
secret in conjunction with the user ID is known as authentication.

### WLAN

Client stations must first authenticate themselves to WLAN access points
before being able to associate with, and communicate over, the WLAN. The
following recommendations can help limit access to the WLAN to only
authorized client stations.

**RQ-17** \"Open System\" authentication must not be used and must be
disabled. Open System authentication is a null authentication method
that grants any requesting WLAN client station access to the WLAN.

**RQ-18** \"Shared Key\" authentication must be used. Shared Key
authentication is implemented using a challenge-response system that
attempts to mutually authenticate the WLAN client station and access
point using any one of the WEP encryption keys shared between the client
station and access point. See WEP (Wired Equivalent Privacy) and
Enhanced 802.11i Encryption below for more information on WEP and on
generating WEP encryption keys.

Note that the Shared Key authentication mechanism is irreparably broken.
As such, any sufficiently motivated attacker can authenticate to the
WLAN by exploiting a design flaw in the Shared Key authentication
mechanism. Despite this significant weakness, Shared Key authentication
provides a greater barrier to entry as compared to Open System
authentication. At present, there are no other authentication methods
available.

**RQ-19** MAC address filtering must be used. MAC address filtering
allows for a list of valid WLAN client station MAC addresses to be
specified. This list is commonly stored on either the access point
itself, or on a RADIUS server that is consulted by the access point.
WLAN client station addresses not on this list are not allowed to
associate with the WLAN. Some vendors refer to MAC address filtering as
MAC address authentication.

Note that a sufficiently motivated attacker can easily circumvent MAC
address filtering by impersonating the MAC address of an authorized
client station. Since MAC addresses are transmitted in plain text as
part of every transmission, learning valid MAC addresses is trivial
through the use of a network sniffer.

### Client Station or User

The original 802.11 WLAN protocols did not provide a mechanism for
identifying the individual WLAN client station or user that was
attempting to access the WLAN. However, a recent extension to the 802.11
protocols does allow for the identification of individual WLAN clients
stations or users. This extension is known as 802.1x - Port-base Network
Access Control. Another option for providing client station or user
identification is through the use of a Virtual Private Network (VPN).

Depending upon the 802.1x or VPN implementation, authentication may be
based on a password, digital certificate, Kerberos ticket, or other
credential.

For password-based authentication systems, the strength and secrecy of
the password is critical to overall system security. Weak, easily
guessed, or commonly known passwords dramatically decrease security, and
potentially allow a malicious user easy access.

If password-based 802.1x or VPN mechanisms provide for individual client
station or user authentication, then the following baseline requirements
can significantly increase the level of effort required for a malicious
user to compromise user passwords and subsequently gain access to the
WLAN.

**RQ-20** Each client station or user must use his unique individual
client or user identifier when authenticating. Multiple client stations
or people must not share a single, common identifier.

**RQ-21** All WLAN access points or VPN gateways must require and
authenticate a valid client station or user ID prior to granting access
to the WLAN or VPN.

**RQ-22** If supported, each and every account must be assigned a
password.

**RQ-23** If passwords are supported, then passwords must be in full
compliance with DOI's password policy.

**RQ-24** If passwords are supported, periodic password changes must be
enforced. The older a password is, the more likely that it has been
compromised by accident or through malicious intent. Changing passwords
on a regular basis ensures that even if a malicious user did obtain
access to the WLAN or VPN using a compromised password, then the
password will only be valid for a finite time.

**RQ-25** If passwords are supported, periodic password changes must be
required at least every 60 days, and must be enforced by the
authentication server, if applicable.

**RQ-26** Grace logins after a required password change must be limited
to three, and must be enforced by the authentication server, if
applicable.

**RQ-27** A maximum of three consecutive login failures must be
permitted before the WLAN disconnects the user.

**RQ-28** If passwords are supported, passwords must not be reused. If
applicable, password reuse limits must be enforced by the authentication
server. Disallowing password reuse prevents users from \"cycling\" or
repeating their passwords when periodic changes are enforced.

**RQ-29** To avoid the compromise of one system from compromising other
systems, users must not use the same password for WLAN or VPN access
that they use elsewhere (for example, NetWare, UNIX, NT, e-mail).
Likewise, the same password should not be used across WLANs or VPNs
having different assurance requirements.

**SC-7** When a higher level of assurance is required than that which
passwords can provide, strong authentication methods such as token-based
authentication should be considered.

WLAN Access Point Administration

Authentication security standard requirements for administrators (that
is, users that can operate with privileges to configure the system)
follow the same baseline requirements as for users. However, given the
greater capabilities available to administrators, more stringent
standards are required in some areas, as defined below.

**RQ-30** All WLAN access points must require and authenticate a valid
password prior to granting privileged access to the access point.

**RQ-31** All default WLAN access point passwords must be changed and
assigned a strong password as outlined above in RQ-23.

**RQ-32** Passwords must be longer than eight characters in length.

**RQ-33** Periodic password changes must be required at least every 60
days.

##### Remote Access

Remote access security is critical in any networked system, and
particularly for 802.11 WLAN devices. After all, a misplaced or
ill-configured wireless access point can expose confidential corporate
network resources to attackers who may be miles away. Making matters
worse, inherent weaknesses and defects in the 802.11 protocols make
802.11 WLANs attractive - and easy - targets for malicious users. Strong
802.11 WLAN security measures, therefore, are needed to protect against
such risks.

The following aspects of remote access security are discussed in the
sections below:

-   Radio Frequency (RF) Transmission Considerations

-   Network Compartment**a**lization

-   WLAN Access Point Network Services

-   802.1x - Port-based Network Access Control

-   Radio Frequency (RF) Transmission Considerations

-   802.11 WLAN devices contain a radio transmitter and receiver that
    operate in either of two standard bands - the 2.4 GHz ISM
    (Industrial, Scientific, and Medial) band for 802.11, 802.11b, and
    802.11g devices, or the 5 GHz U-NII (Unlicensed National Information
    Infrastructure) band for 802.11a devices. Regardless of frequency,
    802.11 WLAN devices operate without regard for the boundaries of an
    organization\'s office space. Indeed, point-to-point WLAN
    transmissions have been carried to distances in excess of 15 miles
    with appropriate equipment. Even typical office WLAN transmissions
    can frequently be received up to a half-mile away by an interloper
    with a directional antenna.

Given the unbounded nature of WLANs, the first step to securing them is
through understanding and proper deployment of radio frequency (RF)
equipment.

**RQ-34** RF and transmission characteristics of 802.11 WLAN must not be
considered or relied upon as security features. Some vendors have
claimed that 802.11\'s ultra-high transmission frequency and use of
Direct Sequence Spread Spectrum (DSSS), Frequency Hopping Spread
Spectrum (FHSS), or Orthogonal Frequency Division Multiplexing (OFDM)
modulation makes it nearly impossible and cost-prohibitive for a
malicious user to intercept or fabricate 802.11 WLAN traffic. In fact,
the opposite is true. Anyone with a low-cost, off-the-shelf 802.11
wireless Ethernet card, and readily available software, can intercept or
inject data if other precautions are not taken.

**RQ-35** Point-to-Point 802.11 WLAN connections must not be considered
or relied upon as secure simply due to their so-called point-to-point
nature. Although transmissions are typically more tightly focused in
point-to-point connections, a malicious user in the vicinity of the
transmission path can still intercept or inject data if other
precautions are not taken.

**RQ-36** Wireless access points with dedicated, omni-directional
antenna must be located in such a way so as to minimize RF coverage
outside of the intended transmission area. For example, place wireless
access points towards the center of a building and not along the outer
perimeter.

**RQ-37** Appropriate antenna and polarization must be selected for use
with wireless access points so as to reduce stray RF transmission.
Selecting the correct antenna and polarization can reduce signal
strength by 100-fold outside of the intended transmission area. As an
added benefit, proper choice of antennas can make the WLAN less
susceptible to interference.

### Network Compartmentalization

802.11 WLANs are inherently insecure, and can literally provide an
attacker with an easy back door into an organization\'s network. To
protect against this, WLANs must be segregated from an organization\'s
internal network.

**RQ-38** 802.11 WLANs must be treated as a non-trusted network, similar
to the Internet. As a non-trusted network, all wireless access points
must be segregated from the organization\'s internal network using a
firewall and IDS according to the DOI Network Perimeter Security
Standard. Configurations of the devices are to be in accordance with
standards in use for any device separating the Internet from the DOI
network.

**RQ-39** Network segregation must not be performed using Virtual LANs
(VLANs), and must instead be done through the physical separation of
dedicated network equipment and wiring. 802.11 WLANs provide link-level,
layer 2 access to the attached network, providing the means for
malicious WLAN devices to launch layer 2 attacks. VLANs have proven to
be susceptible to layer 2 attacks, potentially allowing an attacker to
cross from an \"external\" VLAN onto an \"internal\" VLAN.

**RQ-40** All users must securely authenticate themselves to the gateway
prior to gaining access to the internal corporate LAN, the Internet, or
any other network. Sure authentication mechanisms include those provided
by a VPN, Secure Sockets Layer (SSL)-encrypted gateway login page, or
Secure Shell (SSH) login to a bastion host.

**RQ-41** Access through the gateway must be restricted to only those
network destinations, protocols, and services that are required, thereby
limiting the possible attack vectors from the external WLAN to the
internal network. For example, if WLAN users will only ever access the
corporate e-mail server, then the WLAN does not need access to the
finance department\'s file server.

Note that such restrictions should also be imposed upon connections
originating from VPN connections.

WLAN Access Point Network Services

Every system connected to a network is subject to attacks. These attacks
range from surveillance for a given vulnerability, to attempts to gain
unauthorized access, to Denial of Service (DoS) attacks designed to
render the system useless. Given the variety of attacks that a system is
potentially subject to, it is necessary to institute controls to reduce
the chance of successful assaults.

**RQ-42** All network services listening on a WLAN access point\'s
wireless network interface must be disabled or have access denied from
wireless network addresses, if possible. In particular, access point
management services should never be accessible via the wireless
interface.

**RQ-43** All unnecessary network services listening on a WLAN access
point\'s wired network interface must be disabled, if possible.
Generally speaking, the only service(s) that may need to be running are
those supporting the access point management server.

### Management Server Interfaces

WLAN access points often provide several different management server
interfaces to facilitate access point and WLAN configuration. Not all
interfaces are created equally from a security perspective, however, and
some can lead to a compromise of the WLAN.

**RQ-44** Unused management server interfaces must be disabled or have
access otherwise restricted, if possible. Many access points provide
multiple configuration interfaces such as serial console port, Telnet,
File Transfer Protocol (FTP), Simple Network Management Protocol (SNMP)
(see below), and Trivial File Transfer Protocol (TFTP).

**RQ-45** If possible, access to management server interfaces must be
restricted to specific hosts only, such as the corporate WLAN access
point management station.

**RQ-46** If available, encrypted protocols must be used when
communicating with WLAN management servers to enhance confidentiality
and provide data integrity. For example, HTTPS must be used in lieu of
HTTP, and SSH must be used in lieu of Telnet.

**RQ-47** All access to the management server interfaces must be
authenticated.

**SC-8** All WLAN access point configuration should be done via the
dedicated serial console interface, if available and feasible.

Network-based management interfaces are prone to man-in-the-middle
attacks, in which an attacker inserts himself between the management
station and the WLAN access point, allowing him to see or modify all the
data. Man-in-the-middle attacks can be accomplished by spoofing the
Address Resolution Protocol (ARP) that maps layer 3 IP addresses to
their corresponding layer 2 MAC address. While traditional wired
Ethernet network segments are also susceptible to ARP spoofing, the
danger is greater on 802.11 WLANs due to inherent security deficiencies.

See the Data Integrity section below for more information on ARP
spoofing protections.

**SC-9** Embedded HTTP management servers should not be used. Embedded
HTTP management interfaces have historically proven to pose large
security risks, including weak authentication mechanisms, flawed state
mechanisms, and susceptibility to the numerous flaws in common Web
browsers such as Microsoft\'s Internet Explorer.

### Simple Network Management Protocol (SNMP)

SNMP can be used to remotely monitor and configure WLAN access points.
Unfortunately, the SNMP protocol was not initially designed with
security in mind and is a frequent conduit of attack. Generally
speaking, enabling remote configuration via SNMP almost guarantees
compromise of the access point, and should not be used. SNMP traps,
which are sent when errors or specific events occur on the network,
should also be avoided, but are preferable to providing on-demand access
to the SNMP Management Information Base.

The requirements presented in this section do not imply an endorsement
of SNMP. Instead, this section offers security requirements for
organizations that do choose to implement SNMP.

**RQ-48** SNMP must be disabled if it is not required and is not being
used. Even with SNMP disabled, the safeguards presented in this
section - particularly with regard to setting strong community strings -
must be implemented.

**RQ-49** The latest version of the SNMP protocol supported by both
device and management stations must be implemented, and support for
earlier versions of SNMP disabled. SNMP versions to be used, in order of
preference are:

1.  SNMPv3 with authentication and privacy

2.  SNMPv3 with authentication only

3.  SNMPv2p with MD5 authentication

All other versions of SNMP, including SNMPv3 with no authentication and
no privacy, SNMPv2c, and SNMPv.

**RQ-50** Pre-defined community strings such as \"public\" or
\"private\" must be removed.

**RQ-51** SNMP community strings and passwords must consist of long,
difficult-to-guess values that reflect the same principles of strong
user passwords discussed in RQ-23.

**RQ-52** Different community strings or passwords must be used for each
WLAN access point within an organization. This requirement is
particularly critical if read-write access to WLAN access points is
provided via SNMP, as a malicious user who gleans one community string
can lead to the compromise of every access point within the
organization.

**RQ-53** The use of SNMP must be limited to the minimum functionality
required. For example, if only read-only access to a portion of the
Management Information Base (MIB) is needed, read-write capability to
the entire MIB must not be enabled. Conscious efforts must be made to
avoid read-write capabilities due to the significant risk of a complete
compromise of the access point.

**RQ-54** If SNMP is required and such configuration is supported,
agents must be configured to only accept SNMP requests from specific
hosts, such as the corporate SNMP management station.

**SC-10** SNMP should not be used.

**SC-11** If supported, all SNMP communication should be authenticated
and encrypted between the access point and management station. SNMPv3
with authentication and privacy satisfies this requirement.

### 802.1x - Port-based Network Access Control

In a rush to enhance the security of 802.11 WLANs, the 802.1x standard
for enhancing the security of port-based wired network devices, such as
Ethernet switches, was hastily adapted to the WLAN environment. The
intent for 802.1x in the WLAN environment was to provide enhanced client
station or user authentication, and network access control, as well as
to facilitate dynamic WEP rekeying. Some vendors introduced proprietary
protocols derived from 802.1x for reasons of market timing. One such
example is Cisco\'s Lightweight Extensible Authentication Protocol
(LEAP).

Unfortunately, 802.1x does not fit cleanly into the 802.11 WLAN model
and, as such, introduces a new set of security vulnerabilities such as
802.1x\'s susceptibility to DoS and man-in-the-middle-attacks, as well
as the potential for providing a false sense of security. Ironically,
the original 802.1x specification explicitly states that 802.1x should
not be used in the manner that is employed in the WLAN environment. Even
more ironic is that WEP is the mechanism that prevents 802.1x from
completely falling apart.

In the final analysis, however, the benefit of dynamic WEP keying
provided by 802.1x outweighs the risks of implementing 802.1x port-based
network access control. The following recommendations can help to
mitigate the risks presented by 802.1x.

**RQ-55** If supported by the WLAN access point, 802.1x or similar (for
example, LEAP) must be used to provide for dynamic WEP keying.

**RQ-56** 104-bit WEP encryption must be used. WEP encryption can help
prevent an attacker from hijacking 802.1x sessions.

**RQ-57** 802.1x re-authentication must be done no less than once every
30 minutes, or as required for WEP encryption. See WEP (Wired Equivalent
Privacy) and Enhanced 802.11i Encryption below for more information on
WEP re-keying.

The need for WEP rekeying aside, frequent re-authentication is required
in an effort to synchronize the state between 802.11 client station
associations and 802.1x sessions. Without attempting to re-authenticate,
802.1x has no way of knowing if a WLAN client station is still
associated with the WLAN and is still making use of WLAN resources.

Infrequent or no re-authentication periods can increase the window of
opportunity for an attacker to hijack established sessions.

Re-authentication should be transparent to the end user under most
802.1x implementations, because the client station, or supplicant,
typically caches authentication credentials.

### Encryption

Encryption, when used appropriately, is an essential tool for ensuring
data confidentiality. Appropriate encryption methods allow data to be
safely and securely conveyed in a public environment, without
considerably increasing the risk that unintended recipients will
compromise the data.

### WEP (Wired Equivalent Privacy) and Enhanced 802.11i Encryption

802.11 WLANs provide a native encryption mechanism known as WEP, or
Wired Equivalent Privacy. The original design goal of WEP was to provide
a level of confidentiality similar to that of traditional wired Ethernet
networks. Unfortunately, significant design and implementation flaws
have left WEP vulnerable to a number of different methods of compromise.
To help mitigate these flaws, several incremental improvements have been
introduced as short-term stopgap measures. These improvements consist of
both proprietary vendor extensions and ratified standards.

Despite the significant deficiencies in WEP, WEP is still a critical
element in controlling access to WLANs themselves. It also helps protect
against security deficiencies in 802.1x, and at least minimally helps to
protect the confidentiality of data transmitted across the WLAN. While
the use of WEP will not deter a determined malicious user from accessing
the WLAN or its data, it will effectively block the curious from such
access.

To address WEP\'s shortcomings, new encryption standards are being
developed under the auspices of the 802.11i MAC Enhancements for
Enhanced Security task group. While some of the planned security
standards will likely require new WLAN hardware, an incremental
improvement to WEP known as the Temporal Key Integrity Protocol (TKIP)
should only require a firmware upgrade. TKIP enhances security by
generating a new encryption key for every 10,000 packets of data
transmitted. TKIP is fully backwards-compatible with WEP and, as such,
is also vulnerable to many of the same attacks to which WEP is
vulnerable.

It should be noted that, even with WEP or TKIP enabled, only user data
is encrypted. WLAN control frames, management frames, and all header
information are always transmitted unauthenticated in plain text.

**RQ-58** Default, vendor-supplied WEP keys must be changed.

**RQ-59** WEP encryption - or TKIP encryption as defined by 802.11i -
must be enabled.

**RQ-60** WLAN access points must disable Open Authentication and reject
unencrypted data packets when WEP is enabled. Some WLAN implementations
are capable of simultaneously operating with and without WEP enabled at
the same time, often by running in Open Authentication mode with WEP
encryption enabled. Operating in such a mode can greatly simplify the
task of cracking WEP encryption keys, because WLAN devices will transmit
broadcast information in both encrypted and plain text formats.

**RQ-61** WLAN client stations must reject unencrypted data packets when
WEP is enabled. Doing so guards against associating with access points,
such as rogue access points, which do not have WEP encryption enabled.

**RQ-62** 40-bit WEP key generators are flawed and must not be used. The
WEP key generators found in most WLAN products take an ASCII phrase as
input and produce a 10-byte hexadecimal string as output. While the
output is technically a 40-bit WEP key, flaws in the generation
mechanism reduce the effective strength of the key to 21-bit. Modern
computers can brute-force the entire 21-bit key space in seconds.

**RQ-63** 104-bit WEP must be used in lieu of 40-bit WEP if all WLAN
devices support 104-bit WEP. Using 104-bit WEP makes it virtually
impossible to brute force WEP encryption keys. Unfortunately, other WEP
attack vectors can still reveal the WEP encryption keys.

Note that vendor marketing materials often call 40-bit WEP encryption
64-bit WEP encryption. Likewise, 104-bit WEP encryption is often called
128-bit WEP encryption. In each case, 24-bits of key material are
transmitted across the WLAN in plain text, effectively reducing the
encryption strength to 40-bits or 104-bits, respectively.

**RQ-64** WEP Plus must be used, if available. WEP Plus is a proprietary
modification to WEP found in Agere System\'s ORiNOCO WLAN products. WEP
Plus avoids using the so-called weak keys that many WEP cracking
programs like AirSnort rely upon. WEP Plus is backwards compatible with
WEP, but WLAN access points or client stations not supporting WEP Plus
still generate weak keys, potentially exposing the entire WLAN to
compromise.

**RQ-65** Dynamic per-user or per-session WEP encryption keys must be
used, if available.

Traditional 802.11 WLAN implementations typically only support static
WEP encryption keys that are shared across all WLAN participants.
However, the introduction of 802.1x and similar vendor-specific
implementations provide for WEP keys to be assigned dynamically, often
on a per-user or per-session basis. This enables issuing a unique WEP
encryption key to each user or, preferably, each session.

**RQ-66** WEP encryption keys must be changed on a regular basis.
Deficiencies in WEP require the changing of WEP encryption keys very,
very frequently to ensure confidentiality. Recent research suggests that
WEP encryption keys should be changed anywhere from once every second to
once every 10 minutes, depending upon the amount of traffic transmitted
using a given WEP encryption key.

Clearly, such rapid key change is only feasible when using products that
support automated keying mechanisms, such as provided by 802.1x. WEP
encryption keys should still be regularly changed on WLAN products that
do not support automated keying, perhaps on a weekly or monthly basis.
For more information on key management issues, see SC-13 below.

Note that changing WEP encryption keys does not eliminate WEP\'s
fundamental vulnerabilities. However, frequent enough rekeying does
effectively prevent an attacker from successfully learning the WEP
encryption keys, assuming that a sufficiently strong key was used (for
example, a 104-bit key that is not based on dictionary words).

### Session Encryption

The majority of network communication protocols do not natively provide
encryption of transmitted data. The lack of native encryption means a
malicious user can use a packet sniffer to capture all user data
transmitted across a network, including the contents of sensitive
configuration files and authentication passwords.

Session encryption becomes even more important in a WLAN environment, as
network transmissions are broadcast for all within radio range to
receive, and WEP encryption has far too many flaws to entrust with it
the confidentiality of sensitive data.

**RQ-67** If supported, all WLAN access point management traffic must be
encrypted.

**RQ-68** All data transmitted across the WLAN must be encrypted using a
proven, higher-level encryption protocol that ensures data
confidentiality. Such protocols include SSL, SSH, and IP Security
(IPSec) VPN tunnels.

### Integrity Protection

Maintaining the integrity of WLAN access points and client stations,
including both firmware and configuration, is critical to the overall
security of an organization. Without controls in place to ensure
integrity, accidental or malicious corruption, random errors, and
omissions can lead to the compromise of the WLAN and all information
that passes through it.

### WLAN Integrity

In order to ensure the integrity of the WLAN and the data traversing it,
new security vulnerabilities must be quickly identified and patched.

**RQ-69** WLAN access point and client station firmware must be
regularly updated to fix security vulnerabilities or critical bugs that
have been found, and to take advantage of new security or management
features that have been added.

**SC-12** WLAN administrators should stay current on firmware patches
and WLAN security announcements so that security holes and other
critical bugs can be patched on a timely basis. Suggested resources
include:

-   802.11b WLAN Wireless Security and Information
    ([http://wireless.pasadena.net](http://wireless.pasadena.net/))

-   The Unofficial 802.11 Security Web Page
    (<http://www.drizzle.com/~aboba/IEEE>)

-   WLAN-related USENET news group (<news:alt.internet.wireless>)

Note that a USENET NNTP (Network News Transfer Protocol) news feed is
required to access this group.

### Data Integrity

The 802.11 WLAN protocols provide little to no assurance that the
integrity of data transmitted across the WLAN is maintained. Without
additional safeguards beyond those provided by the 802.11 protocols,
data transmitted across the WLAN is subject to tampering, forgery, and
replay attacks. Data may also be subject to man-in-the-middle attacks as
a result of ARP spoofing.

**RQ-70** All data transmitted across the WLAN must be encapsulated in a
higher-level protocol that protects against man-in-the-middle attacks,
ensures data integrity, protects against forgery, and prevents replay
attacks. Such protocols include SSL, SSH, and IPSec VPN tunnels.

### Client Station and Server Integrity

WLANs are inherently untrusted networks. As such, all client stations
and support devices (for example, a DHCP (Dynamic Host Configuration
Protocol) server or router) attached to the WLAN must take precautions
to protect themselves from attack across that WLAN.

**RQ-71** WLAN client stations and support servers must be secured.
Recommendations for securing various operating system platforms are
described in other META Security Group Asset Protection Standards
documents.

**RQ-72** Users must be made aware of the potential for DoS attacks
against the WLAN, and instructed in appropriate organizational policy
for reporting such attacks. Even if all of the recommendations in this
Asset Protection Standards guide are followed, a malicious user can
still trivially launch DoS attacks against the WLAN, because 802.11
control and management frames are always transmitted unauthenticated in
plain text. These properties allow a malicious user to, for example,
repeatedly disconnect users from the WLAN.

### Information Handling

Information handling concerns how information assets are dealt with
based on their classification and compartmentalization requirements.
Specific information handling requirements will vary from organization
to organization.

**SC-13** To facilitate the update of shared WEP encryption keys used in
a traditional 802.11 WLAN, administrators should distribute new keys to
an organization\'s WLAN user population whenever WEP encryption keys
need to be changed. Some vociferously argue that WEP encryption keys
should be kept a closely guarded secret of the administrative team, and
that end users should never know what the WEP encryption keys are. It
should be noted, however, that the user community already has access to
shared WEP encryption keys. The keys are stored on all WLAN client
stations in a recoverable format - usually in plain text - so that they
may be used when communicating over the WLAN. The benefit of a
user-involved key replacement method typically outweighs the alternative
of WEP encryption keys that are never or rarely changed, due to the
arduous task of the administrative staff having to visit each and every
WLAN client station within an organization in order to make the changes.

**SC-14** Privacy-sensitive organizations may want to reconsider the use
of WLANs, as a malicious user can use passive RF sniffing to track a
client station\'s movement throughout the WLAN - even if WEP or other
encryption is used, because client address information is always
transmitted as plain text.

### Auditing

While prevention of security violations is a common goal across all
organizations, it is not possible to provide \"100 percent guaranteed
security\". The next best thing to prevention, then, is detection.
Auditing provides such a mechanism to detect and identify actual and
attempted security violations. When regularly monitored, audit logs can
also provide insight into security problems that may be building,
allowing an organization to prevent problems before they cause damage.
In the event of an intrusion, unaltered audit records can also be used
for forensic purposes.

In addition, auditing can be a useful diagnostic tool to help overcome
operational or performance problems through review of stored diagnostic
messages and through trend analysis.

Note that extensive auditing may impact performance and consume large
quantities of storage space. Therefore, it is recommended that
additional resources (for example, disk space) be allocated to overcome
such potential problems. Administrative staff should tailor the
following auditing standards to accommodate site-specific requirements,
where appropriate.

**RQ-73** If supported by WLAN access points or 801.x authentication
servers, the following minimum set of events must be audited:

-   Administrative account logon and logoff success and failure.

-   Access point configuration changes.

-   Attempts to connect to access point management interfaces from
    unauthorized stations.

-   All WLAN authentication attempts, whether successful or not.

**RQ-74** Authorized personnel must regularly review log files to ensure
signs of security violations are detected, and appropriate action is
taken.

**RQ-75** Logs must be stored on alternate media (for example, backed up
to tape) prior to reinitializing log files.

**RQ-76** Log files must be retained for a minimum of 30 days.

**SC-15** Additional auditing should also be performed for interesting
events, such as:

Repeated WLAN probe requests for the broadcast SSID \"ANY\" when client
stations use a hard-coded SSID. Such requests may indicate a malicious
user searching for access points.

Unauthorized SSIDs may appear, indicating a rogue access point. Large
quantities of 802.11 disassociate management frames or 802.1x EAP
failure messages. These may indicate a WLAN DoS attack is in progress.

**SC-16** Centralized logging and alerting across all organizational
WLAN access points and authentication servers should be implemented.

**SC-17** Security-related logs should be archived on read-only media,
such as CD-R, then secured, and retained indefinitely.

### Availability Protection

Business continuity and disaster recovery from system failures is an
important component of any Information Security program. As such, there
is a need to develop requirements to address issues related to WLAN
disaster and recovery procedures, regardless of whether the failure is
temporary or catastrophic. Since the area of disaster recovery is very
extensive, the following guidelines provide only a minimum set of
recommendations for protecting WLAN infrastructure devices and their
configuration data.

Organizations typically devise detailed recovery plans that may involve
a series of data, hardware, or interconnect redundancy, as well as
related tactics for disaster recovery.

### Redundancy

WLANs may provide a business-critical connection between users and the
corporate network, or between disparate networks through the use of
point-to-point connections. In either case, even minor outages can cause
great inconvenience, if not great financial loss. Redundant WLAN access
point or bridge deployments, however, can help mitigate the risk of
outages.

**SC-18** For mission-critical access points or point-to-point
connections, multiple devices should be deployed on non-overlapping
channels. In the event of device failure, WLAN client stations or
point-to-point bridges can be configured to automatically seek out
another available channel using the same SSID and WEP encryption keys.

### Critical System Parameter Recovery Information

This section provides a list of administrative items that should be
maintained at all times to provide ease of management and to aid in case
of system failure, recovery, or reconfiguration. Typically, this
information is stored electronically in a versioned and dated format. It
provides not only current information, but also details about the
specific commands or directions for either refreshing or obtaining
additional information about a given item. The following suggested
requirements should be tailored to meet an organization\'s specific
needs.

**RQ-77** Identification of the WLAN access point firmware version and
feature set that is installed, if applicable.

**SC-19** Identification of the access point serial number, hardware
manufacturer, model name, vendor contact information, and applicable
warranty information, in order to speed repair.

**SC-20** Identification of the person or group, including contact
information, responsible for access point administration and
maintenance. At a minimum, this should list people with administrative
privileges.

**SC-21** Identification of all dependent resources provided by other
servers or devices (for example, RADIUS authentication servers).

**SC-22** A copy of the company security policy and procedures
applicable to users and WLAN administrators.

### Data Backup and Recovery

Despite the most diligent security measures, disasters can happen,
ranging from natural or other disasters to a flash RAM failure that
deletes critical WLAN access point configuration data. Organizations
need to be prepared to handle data loss and subsequent recovery.

**RQ-78** A WLAN access point and related systems configuration data
backup and recovery plan must be established to protect against
configuration data loss. For access points that do not directly support
saving configuration data, critical parameters must be manually copied
down and backed up.

**RQ-79** The backup and recovery process must be tested to ensure that
it will work in practice.

**RQ-80** Backup frequency must be commensurate with the value of
configuration data to be protected and the rate at which it changes.

**RQ-81** Because backups can contain full copies of all configuration
information contained within the access point, including sensitive
passwords and encryption keys, backup media must be protected with the
same degree of diligence as the access point itself.

**SC-23** Secure, off-site backup storage can mitigate the risk of
disaster and should be strongly considered by every kind of enterprise.
Off-site storage can be as simple as keeping a regular set of backup
media in a secure location such as a bank\'s safety deposit box.

### Power Protection

Power fluctuations and complete outages can cause WLAN access points to
crash, possibly leading to irreparable data loss, and most certainly
causing, at minimum, a network outage. Uninterruptible Power Supplies
(UPS) provide power conditioning to smooth power fluctuations, and a
battery-backed power source that allows access points to withstand a
complete power failure for at least a short time.

**SC-24** UPS should be provided for WLAN access points considered to be
\"mission critical\".

**SC-25** If using a UPS, it should be capable of supplying power at
full load for at least 15 minutes.

### Anti-Virus

802.11 WLAN access points are not directly susceptible to known Trojan
horses, viruses, and worms. However, infection of a WLAN access point
management workstation with a Trojan horse, virus, or worm could well
lead to the compromise of the WLAN itself. Likewise, WLAN clients can be
infected. As such, anti-virus software deployed upon both management
workstations and WLAN clients provide a necessary defense against
malicious code.

**RQ-82** Client-based anti-virus software must be installed, and must
be capable of scanning files on-demand or in the background as clients
download, read, or write them. Such an anti-virus package would be
installed directly on the client, and would often act as an integral
part of the client operating system.

**RQ-83** Anti-virus software must be configured to send virus
notification messages or log files to the system administrator, if
applicable, in addition to the user.

**RQ-84** Anti-virus signatures, if applicable, must be regularly
updated.

### Bluetooth

This section provides the requirements and suggested considerations for
implementing Bluetooth technology - an ad hoc networking technology, a
relatively new paradigm of wireless communications in which no fixed
infrastructure exists such as base stations or access points. In ad hoc
networks, devices maintain random network configurations formed "on the
fly," relying on a system of mobile routers connected by wireless links
that enable devices to communicate with each other. Devices within an ad
hoc network control the network configuration, and they maintain and
share resources. Ad hoc networks are similar to peer-to-peer (P2P)
networking in that they both use decentralized networking, in which the
information is maintained at the end user location rather than in a
centralized database. However, ad hoc and P2P networks differ in that
P2P networks rely on a routing mechanism to direct information queries,
whereas ad hoc networks rely on the device hardware to request and share
the information.

Ad hoc networks allow devices to access wireless applications, such as
address book synchronization and file sharing applications, within a
wireless personal area network (PAN). When combined with other
technologies, these networks can be expanded to include network and
Internet access. Bluetooth devices that typically do not have access to
network resources but that are connected in a Bluetooth network with an
802.11 capable device can achieve connection within the corporate
network as well as reach out to the Internet.

Bluetooth has three different modes of security. Each Bluetooth device
can operate in one mode only at a particular time. The three modes are
the following:

-   **Security Mode 1** - Non-secure mode

-   **Security Mode 2 -** Service-level enforced security mode

-   **Security Mode 3 -** Link-level enforced security mode

In Security Mode 1, a device will not initiate any security procedures.
In this non-secure mode, the security functionality (authentication and
encryption) is completely bypassed. In effect, the Bluetooth device in
Mode 1 is in a "promiscuous" mode that allows other Bluetooth devices to
connect to it. This mode is provided for applications for which security
is not required, such as exchanging business cards.

In Security Mode 2, the service-level security mode, security procedures
are initiated after channel establishment at the Logical Link Control
and Adaptation Protocol (L2CAP) level. L2CAP resides in the data link
layer and provides connection-oriented and connectionless data services
to upper layers. For this security mode, a security manager (as
specified in the Bluetooth architecture) controls access to services and
to devices. The centralized security manager maintains polices for
access control and interfaces with other protocols and device users.
Varying security polices and "trust" levels to restrict access may be
defined for applications with different security requirements operating
in parallel. Therefore, it is possible to grant access to some services
without providing access to other services. Obviously, in this mode, the
notion of authorization---that is the process of deciding if device A is
allowed to have access to service X - is introduced.

In Security Mode 3, the link-level security mode, a Bluetooth device
initiates security procedures before the channel is established. This is
a built-in security mechanism, and it is not aware of any application
layer security that may exist. This mode supports authentication
(unidirectional or mutual) and encryption. These features are based on a
secret link key that is shared by a pair of devices. To generate this
key, a pairing procedure is used when the two devices communicate for
the first time.

### Link Key Generation---Bluetooth Bonding

The link key is generated during an initialization phase, while two
Bluetooth devices that are communicating are "associated" or "bonded."
Per the Bluetooth specification, two associated devices simultaneously
derive link keys during the initialization phase when a user enters an
identical PIN into both devices. After initialization is complete,
devices automatically and transparently authenticate and perform
encryption of the link. It is possible to create a link key using higher
layer key exchange methods and then import the link key into the
Bluetooth modules. The PIN code used in Bluetooth devices can vary
between 1 and 16 bytes. The typical 4-digit PIN may be sufficient for
some applications; however, longer codes may be necessary.

### Management

**RQ-85** Perform a risk assessment to understand the value of the
assets in the bureau needing protection.

**RQ-86** Take a complete inventory of all Bluetooth-enabled wireless
devices.

**SC-26** Develop a bureau policy addressing the use of
Bluetooth-enabled devices.

**SC-27** Ensure users are fully trained in computer security awareness
and the risks associated with Bluetooth.

**SC-28** Ensure handheld or small Bluetooth devices are protected from
theft and are turned off during all hours when they are not used.

### Technical

**RQ-87** Choose PIN codes sufficiently long (maximum length possible),
random, and avoid all weak PINs.

**RQ-88** Ensure no Bluetooth device is defaulting to the zero PIN.

**RQ-89** Configure Bluetooth devices to delete PINs after
initialization to ensure PIN entry is required every time and PINs are
not stored in memory after power removal.

**SC-29** Set Bluetooth devices to the lowest necessary and sufficient
power level so transmission remains within secure perimeter.

**SC-30** Ensure the Bluetooth "bonding" environment is secure from
eavesdroppers.

### Operational

**RQ-90** Ensure combination keys are used instead of unit keys.

**RQ-91** Invoke link encryption for all Bluetooth connections
regardless of how needless encryption may seem (i.e. no Security Mode
1).

**RQ-92** Ensure encryption is enabled on every link in the
communication chain.

**RQ-93** Make use of Security Mode 2 in controlled and well-understood
environments.

**RQ-94** Ensure device mutual authentication for all accesses.

**RQ-95** Enable encryption for all broadcast transmissions (Encryption
Mode 3)

**RQ-96** Configure encryption key sizes to the maximum allowable.

**RQ-97** Establish a "minimum key size" for any key negotiation
process.

**RQ-98** Ensure portable devices with Bluetooth interfaces are
configured with a password to prevent unauthorized access if lost or
stolen.

**RQ-99** Install antivirus software and fully test and deploy software
Bluetooth patches and upgrades regularly.

**SC-31** Deploy intrusion detection agents on the wireless part of the
network to detect suspicious behavior or unauthorized access and
activity.

### Handheld Devices

Wireless handheld devices range from simple one- and two-way text
messaging devices to Internet-enabled Personal Digital Assistants (PDA),
tablets, and smart phones. These devices are no longer viewed as coveted
gadgets for early technology adopters. Instead they have become
indispensable tools and competitive business advantages for the mobile
work force. The use of these devices introduces new security risks to an
agency's existing network. Moreover, as these devices begin having their
own IP addresses, the devices themselves can become the targets of
attacks. Handheld devices have different capabilities and different uses
from those of desktop and laptop computers.

Although handheld devices have not generally been viewed as posing
security threats, their increased computing power and the ease with
which they can access networks and exchange data with other handheld
devices introduce new security risks to an agency's computing
environment. As handheld devices begin supporting more networking
capabilities, network administrators must carefully assess the risks
they introduce into their existing computing environment.

### Management

**RQ-100** Ensure users know where to report a lost or stolen device.

**RQ-101** Enable a "power-on" password for each handheld device.

**RQ-102** Ensure desktop application-mirroring software is
password-protected.

**RQ-103** Install antivirus software on all handheld devices.

**SC-32** Conduct ongoing, random security audits to monitor and track
devices.

**SC-33** Label all handheld devices with the owner and agency's
information.

**SC-34** Ensure devices are stored securely when left unattended.

**SC-35** Ensure proper password management (aging, complexity, etc.)
for all handheld devices.

**SC-36** Store data on backup storage modules in encrypted form.

**SC-37** Ensure all devices have timeout mechanisms automatically
prompting the user for a password after a period of inactivity.

### Technical

**RC-104** Ensure a user can be securely authenticated when operating
locally and remotely.

**RC-105** Use FIPS 140-2 compliant encryption and password protection
utilities for the protection of sensitive data files and applications.

**SC-38** Use enterprise security applications to manage handheld device
security.

**SC-39** When disposing of handheld devices that will no longer be used
by the agency, clear configuration settings to prevent the disclosure of
sensitive network information.

### Checklist for WLANs

### Requirements (RQ)

#### Physical Access

+-------------+--------------------------------------------------------+
| ####        | #### Antennas and related cabling supporting 802.11 W  |
| \[  \] RQ-1 | LANs must be kept in a secure area where access is res |
|             | tricted to authorized personnel. Wireless access point |
|             | s must be physically located where there are appropria |
|             | te physical access controls preventing unauthorized us |
|             | ers from accessing the access point so as to prevent m |
|             | alicious or unauthorized/unintentional tampering with  |
|             | device(s) and must not be located in a "common area".  |
+-------------+--------------------------------------------------------+
| ####        | #### WLAN acc                                          |
| \[  \] RQ-2 | ess points must be kept in a secured closet or enclosu |
|             | re where access is restricted to authorized personnel. |
+-------------+--------------------------------------------------------+
| ####        | #### WLAN-enabled client stations must be protecte     |
| \[  \] RQ-3 | d from loss or theft; gaining access to a client may a |
|             | llow an unauthorized user unrestricted access to an or |
|             | ganization\'s network. This concern is not unique to W |
|             | LAN-enabled clients, but also applies to any client co |
|             | nfigured to remotely access an organization\'s network |
|             | , such as via a dial-up Virtual Private Network (VPN). |
+-------------+--------------------------------------------------------+
| ####        | #### Lo                                                |
| \[  \] RQ-4 | ss or theft of a WLAN-enabled client station or networ |
|             | k card must be immediately reported to the network sec |
|             | urity team or other appropriate, designated group with |
|             | in an organization that may take appropriate measures. |
+-------------+--------------------------------------------------------+
| ####        | #### Physical securit                                  |
| \[  \] RQ-5 | y teams, such as the security guards in a building, mu |
|             | st be educated on general wireless security risks and  |
|             | instructed to watch for interlopers with antennas, lap |
|             | tops, personal digital assistants, or similar equipmen |
|             | t, who may be loitering in lobbies, parking lots, or s |
|             | idewalks to intercept or interfere with transmissions. |
+-------------+--------------------------------------------------------+
| ####        | #### Physical                                          |
| \[  \] RQ-6 | security teams must be instructed to watch for unautho |
|             | rized, rogue WLAN access points that may be installed. |
+-------------+--------------------------------------------------------+

### System Access

#### Identification

##### WLAN

+-------------+--------------------------------------------------------+
| #####       | ##### The SSID used to id                              |
| \[  \] RQ-7 | entify a WLAN must be changed from the vendor default. |
+-------------+--------------------------------------------------------+
| #####       | Do not set SSIDs to values such as your                |
| \[  \] RQ-8 | organization\'s name, address, floor, or department.   |
+-------------+--------------------------------------------------------+

##### Client Station or User

+-------------+--------------------------------------------------------+
| #####       | ##### Each user accou                                  |
| \[  \] RQ-9 | nt - whether it represents a person or a client statio |
|             | n - must have a unique account identifier that identif |
|             | ies one, and only one, entity within the organization. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### User communities or working groups               |
| [  \] RQ-10 | must not share a single user ID for WLAN access. Each  |
|             | user must access the WLAN by using his unique user ID. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### All users must ha                                |
| [  \] RQ-11 | ve a meaningful description and naming convention for  |
|             | the purpose of effortless identification and tracking. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### All WLANs mus                                    |
| [  \] RQ-12 | t require that every user be uniquely identified by em |
|             | ploying a user ID prior to gaining access to the WLAN. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### Accounts must be deactivated withi               |
| [  \] RQ-13 | n 24 hours, if not sooner, of notification of a status |
|             |  change (for example, employee termination or change i |
|             | n job, or if a WLAN client station is lost or stolen). |
+-------------+--------------------------------------------------------+
| ##### \     | ##### Unused, dormant accounts or acco                 |
| [  \] RQ-14 | unts of terminated employees must be disabled, and sub |
|             | sequently deleted, according to organizational policy. |
+-------------+--------------------------------------------------------+

##### WLAN Access Point Administration

+-------------+--------------------------------------------------------+
| ##### \     | ##### If the WLAN access poin                          |
| [  \] RQ-15 | t\'s management interface supports the identification  |
|             | of individual users, the applicable requirements outli |
|             | ned above for Client Station or User must be followed. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### Unus                                             |
| [  \] RQ-16 | ed, vendor-supplied, default accounts must be disabled |
|             |  or deleted, as provided for by the WLAN access point\ |
|             | 's management interface. In cases where default accoun |
|             | ts are disabled or cannot be deleted, those accounts s |
|             | hould be assigned a strong password (see RQ-23 below). |
+-------------+--------------------------------------------------------+

#### Authentication

##### WLAN

+-------------+--------------------------------------------------------+
| ##### \     | ##### \"Open System\"                                  |
| [  \] RQ-17 |  authentication must not be used and must be disabled. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### \"Shared Key\" authentication must be used.      |
| [  \] RQ-18 |                                                        |
+-------------+--------------------------------------------------------+
| ##### \     | ##### MAC                                              |
| [  \] RQ-19 | (Media Access Control) address filtering must be used. |
+-------------+--------------------------------------------------------+

##### Client Station or User

+-------------+--------------------------------------------------------+
| ##### \     | #                                                      |
| [  \] RQ-20 | #### Each client station or user must use a unique ind |
|             | ividual client or user identifier when authenticating. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### All WLAN access points or VPN gateways           |
| [  \] RQ-21 | must require and authenticate a valid client station o |
|             | r user ID prior to granting access to the WLAN or VPN. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### If supporte                                      |
| [  \] RQ-22 | d, each and every account must be assigned a password. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### If passwords are supported, then passwords       |
| [  \] RQ-23 | must be in full compliance with DOI's password policy. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### If passwords are                                 |
| [  \] RQ-24 | supported, periodic password changes must be enforced. |
+-------------+--------------------------------------------------------+
| ##### \     | ####                                                   |
| [  \] RQ-25 | # If passwords are supported, periodic password change |
|             | s must be required at least every 60 days, and must be |
|             |  enforced by the authentication server, if applicable. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### Grace logins after a required                    |
| [  \] RQ-26 |  password change must be limited to three, and must be |
|             |  enforced by the authentication server, if applicable. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### A maximum of three consecutive login failures m  |
| [  \] RQ-27 | ust be permitted before the WLAN disconnects the user. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### If passwords are supported, passw                |
| [  \] RQ-28 | ords must not be reused. If applicable, password reuse |
|             |  limits must be enforced by the authentication server. |
+-------------+--------------------------------------------------------+
| ##### \     | ##### To avoid the compromise of one syst              |
| [  \] RQ-29 | em from compromising other systems, users must not use |
|             |  the same password for WLAN or VPN access that they us |
|             | e elsewhere (for example, NetWare, UNIX, NT, e-mail).  |
|             | Likewise, the same password should not be used across  |
|             | WLANs or VPNs having different assurance requirements. |
+-------------+--------------------------------------------------------+

##### WLAN Access Point Administration

  -------------- --------------------------------------------------------
  \[  \] RQ-30   All WLAN access points must require and authenticate a
                 valid password prior to granting privileged access to
                 the access point.

  \[  \] RQ-31   All default WLAN access point passwords must be changed
                 and assigned a strong password as outlined above in
                 RQ-23.

  \[  \] RQ-32   Passwords must be longer than eight characters in
                 length.

  \[  \] RQ-33   Periodic password changes must be required at least
                 every 60 days.
  -------------- --------------------------------------------------------

#### Remote Access

#### Radio Frequency (RF) Transmission Considerations

  -------------- --------------------------------------------------------
  \[  \] RQ-34   RF and transmission characteristics of 802.11 WLAN must
                 not be considered or relied upon as security features.

  \[  \] RQ-35   Point-to-Point 802.11 WLAN connections must not be
                 considered or relied upon as secure simply due to their
                 so-called point-to-point nature.

  \[  \] RQ-36   Wireless access points with dedicated, omni-directional
                 antenna must be located in such a way so as to minimize
                 RF coverage outside of the intended transmission area.

  \[  \] RQ-37   Appropriate antenna and polarization must be selected
                 for use with wireless access points so as to reduce
                 stray RF transmission.
  -------------- --------------------------------------------------------

#### Network Compartmentalization

  -------------- --------------------------------------------------------
  \[  \] RQ-38   802.11 WLANs must be treated as a non-trusted network,
                 similar to the Internet. As a non-trusted network, all
                 wireless access points must be segregated from the
                 organization\'s internal network using a gateway device,
                 such as a firewall, with appropriate configuration
                 rules.

  \[  \] RQ-39   Network segregation must not be performed using Virtual
                 LANs (VLANs), and must instead be done through the
                 physical separation of dedicated network equipment and
                 wiring.

  \[  \] RQ-40   All users must securely authenticate themselves to the
                 gateway prior to gaining access to the internal
                 corporate LAN, the Internet, or any other network.

  \[  \] RQ-41   Access through the gateway must be restricted to only
                 those network destinations, protocols, and services that
                 are required. Such restrictions should also be imposed
                 upon connections originating from VPN connections. WLAN
                 Access Point Network Services.
  -------------- --------------------------------------------------------

#### WLAN Access Point Network Services

  -------------- --------------------------------------------------------
  \[  \] RQ-42   All network services listening on a WLAN access point\'s
                 wireless network interface must be disabled or have
                 access denied from wireless network addresses, if
                 possible. In particular, access point management
                 services should never be accessible via the wireless
                 interface.

  \[  \] RQ-43   All unnecessary network services listening on a WLAN
                 access point\'s wired network interface must be
                 disabled, if possible. Generally speaking, the only
                 service(s) that may need to be running are those
                 supporting the access point management server.
  -------------- --------------------------------------------------------

#### Management Server Interfaces

  -------------- --------------------------------------------------------
  \[  \] RQ-44   Unused management server interfaces must be disabled or
                 have access otherwise restricted, if possible.

  \[  \] RQ-45   If possible, access to management server interfaces must
                 be restricted to specific hosts only, such as the
                 corporate WLAN access point management station.

  \[  \] RQ-46   If available, encrypted protocols must be used when
                 communicating with WLAN management servers to enhance
                 confidentiality and provide data integrity.

  \[  \] RQ-47   All access to the management server interfaces must be
                 authenticated.
  -------------- --------------------------------------------------------

#### Simple Network Management Protocol (SNMP)

+-------------+--------------------------------------------------------+
| \[  \]      | SNMP must be disabled if not required and is not being |
| RQ-48       | used.                                                  |
+-------------+--------------------------------------------------------+
| \[  \]      | The latest version of the SNMP protocol supported by   |
| RQ-49       | both device and management stations must be            |
|             | implemented, and support for earlier versions of SNMP  |
|             | disabled. SNMP versions to be used, in order of        |
|             | preference are:                                        |
|             |                                                        |
|             | SNMPv3 with authentication and privacy                 |
|             |                                                        |
|             | SNMPv3 with authentication only                        |
|             |                                                        |
|             | SNMPv2p with MD5 authentication                        |
|             |                                                        |
|             | All other versions of SNMP, including SNMPv3 with no   |
|             | authentication and no privacy, SNMPv2c, and SNMPv are  |
|             | not allowed.                                           |
+-------------+--------------------------------------------------------+
| \[  \]      | Pre-defined community strings such as \"public\" or    |
| RQ-50       | \"private\" must be removed.                           |
+-------------+--------------------------------------------------------+
| \[  \]      | SNMP community strings and passwords must consist of   |
| RQ-51       | long, difficult-to-guess values that reflect the same  |
|             | principles of strong user passwords discussed in       |
|             | RQ-23.                                                 |
+-------------+--------------------------------------------------------+
| \[  \]      | Different community strings or passwords must be used  |
| RQ-52       | for each WLAN access point within an organization.     |
|             | This requirement is particularly critical if           |
|             | read-write access to WLAN access points is provided    |
|             | via SNMP.                                              |
+-------------+--------------------------------------------------------+
| \[  \]      | The use of SNMP must be limited to the minimum         |
| RQ-53       | functionality required.                                |
+-------------+--------------------------------------------------------+
| \[  \]      | If SNMP is required and such configuration is          |
| RQ-54       | supported, agents must be configured to only accept    |
|             | SNMP requests from specific hosts, such as the         |
|             | corporate SNMP management station.                     |
+-------------+--------------------------------------------------------+

#### 802.1x - Port-based Network Access Control

  -------------- --------------------------------------------------------
  \[  \] RQ-55   If supported by the WLAN access point, 802.1x or similar
                 (for example, LEAP) must be used to provide for dynamic
                 WEP keying.

  \[  \] RQ-56   104-bit WEP encryption must be used. WEP encryption can
                 help prevent an attacker from hijacking 802.1x sessions.

  \[  \] RQ-57   802.1xx re-authentication must be done no less than once
                 every 30 minutes, or as required for WEP encryption.
  -------------- --------------------------------------------------------

### Encryption

#### Encryption WEP (Wired Equivalent Privacy) and Enhanced 802.11i

  -------------- --------------------------------------------------------
  \[  \] RQ-58   Default, vendor-supplied WEP keys must be changed.

  \[  \] RQ-59   WEP encryption - or TKIP encryption as defined by
                 802.11i - must be enabled.

  \[  \] RQ-60   WLAN access points must disable Open Authentication and
                 reject unencrypted data packets when WEP is enabled.

  \[  \] RQ-61   WLAN client stations must reject unencrypted data
                 packets when WEP is enabled.

  \[  \] RQ-62   40-bit WEP key generators are flawed and must not be
                 used.

  \[  \] RQ-63   104-bit WEP must be used in lieu of 40-bit WEP if all
                 WLAN devices support 104-bit WEP.

  \[  \] RQ-64   WEP Plus must be used, if available.

  \[  \] RQ-65   Dynamic per-user or per-session WEP encryption keys must
                 be used, if available.

  \[  \] RQ-66   WEP encryption keys must be changed on a regular basis.
  -------------- --------------------------------------------------------

#### Session Encryption

  -------------- --------------------------------------------------------
  \[  \] RQ-67   If supported, all WLAN access point management traffic
                 must be encrypted.

  \[  \] RQ-68   All data transmitted across the WLAN must be encrypted
                 using a proven, higher-level encryption protocol that
                 ensures data confidentiality.
  -------------- --------------------------------------------------------

#### Integrity Protection

#### WLAN Integrity

  -------------- --------------------------------------------------------
  \[  \] RQ-69   WLAN access point and client station firmware must be
                 regularly updated to fix security vulnerabilities or
                 critical bugs that have been found, and to take
                 advantage of new security or management features that
                 have been added.

  -------------- --------------------------------------------------------

#### Data Integrity

  -------------- --------------------------------------------------------
  \[  \] RQ-70   All data transmitted across the WLAN must be
                 encapsulated in a higher-level protocol that protects
                 against man-in-the-middle attacks, ensures data
                 integrity, protects against forgery, and prevents replay
                 attacks.

  -------------- --------------------------------------------------------

#### Client Station and Server Integrity

  -------------- --------------------------------------------------------
  \[  \] RQ-71   WLAN client stations and support servers must be
                 secured.

  \[  \] RQ-72   Users must be made aware of the potential for DoS
                 attacks against the WLAN, and instructed in appropriate
                 organizational policy for reporting such attacks.
  -------------- --------------------------------------------------------

#### Auditing

+-------------+--------------------------------------------------------+
| \[  \]      | If supported by WLAN access points or 801.x            |
| RQ-73       | authentication servers, the following minimum set of   |
|             | events must be audited:                                |
|             |                                                        |
|             | Administrative account logon and logoff success and    |
|             | failure.                                               |
|             |                                                        |
|             | Access point configuration changes.                    |
|             |                                                        |
|             | Attempts to connect to access point management         |
|             | interfaces from unauthorized stations.                 |
|             |                                                        |
|             | All WLAN authentication attempts, whether successful   |
|             | or not.                                                |
+-------------+--------------------------------------------------------+
| \[  \]      | Authorized personnel must regularly review log files   |
| RQ-74       | to ensure signs of security violations are detected,   |
|             | and appropriate action is taken.                       |
+-------------+--------------------------------------------------------+
| \[  \]      | Logs must be stored on alternate media (for example,   |
| RQ-75       | backed up to tape) prior to reinitializing log files.  |
+-------------+--------------------------------------------------------+
| \[  \]      | Log files must be retained for a minimum of 30 days.   |
| RQ-76       |                                                        |
+-------------+--------------------------------------------------------+

### Availability Protection

#### Critical System Parameter Recovery Information

  -------------- --------------------------------------------------------
  \[  \] RQ-77   Identification of the WLAN access point firmware version
                 and feature set that is installed, if applicable.

  -------------- --------------------------------------------------------

#### Data Backup and Recovery

  -------------- --------------------------------------------------------
  \[  \] RQ-78   A WLAN access point and related systems configuration
                 data backup and recovery plan must be established to
                 protect against configuration data loss. For access
                 points that do not directly support saving configuration
                 data, critical parameters must be manually copied down
                 and backed up.

  \[  \] RQ-79   The backup and recovery process must be tested to ensure
                 that it will work in practice.

  \[  \] RQ-80   Backup frequency must be commensurate with the value of
                 configuration data to be protected and the rate at which
                 it changes.

  \[  \] RQ-81   Because backups can contain full copies of all
                 configuration information contained within the access
                 point, including sensitive passwords and encryption
                 keys, backup media must be protected with the same
                 degree of diligence as the access point itself.
  -------------- --------------------------------------------------------

#### Anti-Virus

  -------------- --------------------------------------------------------
  \[  \] RQ-82   Client-based anti-virus software must be installed, and
                 must be capable of scanning files on-demand or in the
                 background as clients download, read, or write them.

  \[  \] RQ-83   Anti-virus software must be configured to send virus
                 notification messages or log files to the system
                 administrator, if applicable, in addition to the user.

  \[  \] RQ-84   Anti-virus signatures, if applicable, must be regularly
                 updated.
  -------------- --------------------------------------------------------

### Suggested Considerations 

#### Physical Access

  -------------- --------------------------------------------------------
  \[  \] SC-1    Access to secured facilities, closets, or enclosures
                 should be controlled and logged.

  \[  \] SC-2    Secured facility, closet, or lock box access lists
                 should be regularly audited to ensure that people with
                 keys or key cards do still require access.

  \[  \] SC-3    Security teams should conduct wireless site surveys of
                 their organization to identify and locate unauthorized
                 WLAN access points.
  -------------- --------------------------------------------------------

#### System Access

#### Identification

##### WLAN

+-------------+--------------------------------------------------------+
| \[  \] SC-4 | Access point responses to broadcast SSID probe         |
|             | requests (that is, the \"ANY\" SSID) should be         |
|             | disabled, if possible. Disabling responses to          |
|             | broadcast probe requests will prevent access points    |
|             | from being seen by some - but not all - site survey    |
|             | tools. Additionally, disabling broadcast probe         |
|             | requests may cause some access points to obscure their |
|             | SSID name when transmitting 802.11 management frames.  |
+-------------+--------------------------------------------------------+
| \[  \] SC-5 | Despite the potential benefit of operating in this     |
|             | mode, disabling responses to broadcast SSID probe      |
|             | requests violates the 802.11 protocol specification.   |
|             | This causes difficulties with Windows XP and other     |
|             | applications or operating systems that expect a        |
|             | response to broadcast SSID probe requests.             |
|             |                                                        |
|             | WLAN client stations should have the SSID they seek to |
|             | associate with hard-coded in their configuration       |
|             | instead of automatically scanning for any available    |
|             | access point to associate with. Explicitly setting the |
|             | SSID is required when WLAN SSID broadcasts have been   |
|             | disabled as in SC-4. It can also help the client       |
|             | station to avoid establishing associations with        |
|             | unintended access points.                              |
+-------------+--------------------------------------------------------+

#### Client Station or User

  -------------- --------------------------------------------------------
  \[  \] SC-6    If possible, user identification should be performed
                 instead of client station identification.

  -------------- --------------------------------------------------------

#### Authentication

##### Client Station or User

  -------------- --------------------------------------------------------
  \[  \] SC-7    When a higher level of assurance is required than that
                 which passwords can provide, strong authentication
                 methods such as token-based authentication should be
                 considered.

  -------------- --------------------------------------------------------

### Remote Access

#### Management Server Interfaces

  -------------- --------------------------------------------------------
  \[  \] SC-8    All WLAN access point configuration should be done via
                 the dedicated serial console interface, if available and
                 feasible.

  \[  \] SC-9    Embedded HTTP management servers should not be used.
  -------------- --------------------------------------------------------

### Simple Network Management Protocol (SNMP)

  -------------- --------------------------------------------------------
  \[  \] SC-10   SNMP should not be used.

  \[  \] SC-11   If supported, all SNMP communication should be
                 authenticated and encrypted between the access point and
                 management station.
  -------------- --------------------------------------------------------

#### Integrity Protection

#### WLAN Integrity

+-------------+--------------------------------------------------------+
| \[  \]      | WLAN administrators should stay current on firmware    |
| SC-12       | patches and WLAN security announcements so that        |
|             | security holes and other critical bugs can be patched  |
|             | on a timely basis. Suggested resources include:        |
|             |                                                        |
|             | 802.11b WLAN Wireless Security and Information:\       |
|             | [http:/                                                |
|             | /wireless.pasadena.net](http://wireless.pasadena.net/) |
|             |                                                        |
|             | The Unofficial 802.11 Security Web Page:\              |
|             | <http://www.drizzle.com/~aboba/IEEE>                   |
|             |                                                        |
|             | WLAN-related USENET news group:\                       |
|             | <news:alt.internet.wireless>                           |
|             |                                                        |
|             | Note that a USENET NNTP (Network News Transfer         |
|             | Protocol) news feed is required to access this group.  |
+-------------+--------------------------------------------------------+

#### Information Handling

  -------------- --------------------------------------------------------
  \[  \] SC-13   To facilitate the update of shared WEP encryption keys
                 used in a traditional 802.11 WLAN, administrators should
                 distribute new keys to an organization\'s WLAN user
                 population whenever WEP encryption keys need to be
                 changed.

  \[  \] SC-14   Privacy-sensitive organizations may want to reconsider
                 the use of WLANs, as a malicious user can use passive RF
                 sniffing to track a client station\'s movement
                 throughout the WLAN - even if WEP or other encryption is
                 used, because client address information is always
                 transmitted as plain text.
  -------------- --------------------------------------------------------

#### Auditing

  -------------- --------------------------------------------------------
  \[  \] SC-15   Additional auditing should also be performed for
                 interesting events, such as: Repeated WLAN probe
                 requests for the broadcast SSID \"ANY\" when client
                 stations use a hard-coded SSID. Such requests may
                 indicate a malicious user searching for access points,
                 unauthorized SSIDs that may appear, possibly indicating
                 a rogue access point, and large quantities of 802.11
                 disassociate management frames or 802.1x EAP failure
                 messages.

  \[  \] SC-16   Centralized logging and alerting across all
                 organizational WLAN access points and authentication
                 servers should be implemented.

  \[  \] SC-17   Security-related logs should be archived on read-only
                 media, such as CD-R, then secured, and retained
                 indefinitely.
  -------------- --------------------------------------------------------

#### Availability Protection

#### Redundancy

  -------------- --------------------------------------------------------
  \[  \] SC-18   For mission-critical access points or point-to-point
                 connections, multiple devices should be deployed on
                 non-overlapping channels. In the event of device
                 failure, WLAN client stations or point-to-point bridges
                 can be configured to automatically seek out another
                 available channel using the same SSID and WEP encryption
                 keys.

  -------------- --------------------------------------------------------

#### Critical System Parameter Recovery Information

This section provides a list of administrative items that should be
maintained at all times to provide ease of management and to aid in case
of system failure, recovery, or reconfiguration.

  -------------- --------------------------------------------------------
  \[  \] SC-19   Identification of the access point serial number,
                 hardware manufacturer, model name, vendor contact
                 information, and applicable warranty information, in
                 order to speed repair.

  \[  \] SC-20   Identification of the person or group, including contact
                 information, responsible for access point administration
                 and maintenance. At a minimum, this should list people
                 with administrative privileges.

  \[  \] SC-21   Identification of all dependent resources provided by
                 other servers or devices (for example, RADIUS
                 authentication servers).

  \[  \] SC-22   A copy of the company security policy and procedures
                 applicable to users and WLAN administrators.
  -------------- --------------------------------------------------------

#### Data Backup and Recovery

  -------------- --------------------------------------------------------
  \[  \] SC-23   Secure, off-site backup storage can mitigate the risk of
                 disaster and should be strongly considered by every kind
                 of enterprise.

  -------------- --------------------------------------------------------

#### Power Protection

  -------------- --------------------------------------------------------
  \[  \] SC-24   UPS should be provided for WLAN access points considered
                 to be \"mission critical\".

  \[  \] SC-25   If using a UPS, it should be capable of supplying power
                 at full load for at least 15 minutes.
  -------------- --------------------------------------------------------

### Wireless Ethernet Security Tools

The following tools can be used to assess the security of an
organization\'s 802.11 WLAN deployment.

#### 802.11 Protocol Decoding

Protocol decoding tools, more commonly known as packet sniffers, allow
raw, low-level network traffic to be captured and studied. Each of the
tools on this list is 802.11-aware, and is capable of capturing 802.11
management and control traffic in addition to user data.

-   Aerosol (Windows, Free)\
    http://www.sec33.com/sniph/aerosol.php

-   AiroPeek (Windows, Commercial)\
    <http://www.wildpackets.com/products/airopeek>

-   Ethereal (FreeBSD, Linux, Free)\
    [http://www.ethereal.com](http://www.ethereal.com/)

-   Kismet (Linux, Free)\
    [http://www.kismetwireless.net](http://www.kismetwireless.net/)

-   Sniffer Wireless (Windows, Commercial)\
    <http://www.sniffer.com/products/sniffer-wireless>

-   TCPDump (Most UNIX platforms, Free)\
    [http://www.tcpdump.org](http://www.tcpdump.org/)

#### Site Survey

Site survey tools can be used to quickly identify 802.11 WLAN access
points operating within range of the client that is running the site
survey tool.

-   APSniff (Windows 2000, Free)\
    <http://www.bretmounet.com/ApSniff>

-   bsd-airtools (FreeBSD, NetBSD, and OpenBSD, Free)\
    <http://www.dachb0den.com/projects/bsd-airtools.html>

-   Kismet (Linux, Free)\
    [http://www.kismetwireless.net](http://www.kismetwireless.net/)

-   Mini Stumbler (Pocket PC, Free)\
    [http://www.netstumbler.org](http://www.netstumbler.org/)

-   Network Stumbler (Windows, Free)\
    [http://www.netstumbler.org](http://www.netstumbler.org/)

-   Sniffer Wireless (Windows)\
    http://www.sniffer.com

-   Wavemon (Linux, Free)\
    <http://www.jm-music.de/projects.html>

-   WaveStumbler (Windows, Linux, Free)\
    http://www.cqure.net/tools08.html

-   Wlantools (Linux, Free)\
    <http://www.sublimation.org/security/localarchive/802.11/0day.html>

#### WEP Decryption

WEP decryption tools can be used to either exploit known flaws in WEP
encryption to decode network traffic, or to conduct brute-force attacks
to determine the WEP encryption key.

-   AirSnort (Linux, Free)\
    [http://airsnort.shmoo.com](http://airsnort.shmoo.com/)

-   bsd-airtools (FreeBSD, NetBSD, and OpenBSD, Free)\
    <http://www.dachb0den.com/projects/bsd-airtools.html>

-   WEPCrack (Linux, Free)\
    [http://wepcrack.sourceforge.net](http://wepcrack.sourceforge.net/)

-   WEP Tools (Linux, Free)\
    <http://www.lava.net/~newsham/wlan>

### Checklist for Bluetooth

#### Requirements (RQ)

#### Management

  -------------- --------------------------------------------------------
  \[ \] RQ-85    Perform a risk assessment to understand the value of the
                 assets in the bureau needing protection.

  \[ \] RQ-86    Take a complete inventory of all Bluetooth-enabled
                 wireless devices.
  -------------- --------------------------------------------------------

#### Technical

  -------------- --------------------------------------------------------
  \[ \] RQ-87    Choose PIN codes sufficiently long (maximum length
                 possible), random, and avoid all weak PINs.

  \[ \] RQ-88    Ensure no Bluetooth device is defaulting to the zero
                 PIN.

  \[ \] RQ-89    Configure Bluetooth devices to delete PINs after
                 initialization to ensure PIN entry is required every
                 time and PINs are not stored in memory after power
                 removal.
  -------------- --------------------------------------------------------

#### Operational

  -------------- --------------------------------------------------------
  \[ \] RQ-90    Ensure combination keys are used instead of unit keys.

  \[ \] RQ-91    Invoke link encryption for all Bluetooth connections
                 regardless of how needless encryption may seem (i.e. no
                 Security Mode 1).

  \[ \] RQ-92    Ensure encryption is enabled on every link in the
                 communication chain.

  \[ \] RQ-93    Make use of Security Mode 2 in controlled and
                 well-understood environments.

  \[ \] RQ-94    Ensure device mutual authentication for all accesses.

  \[ \] RQ-95    Enable encryption for all broadcast transmissions
                 (Encryption Mode 3).

  \[ \] RQ-96    Configure encryption key sizes to the maximum allowable.

  \[ \] RQ-97    Establish a "minimum key size" for any key negotiation
                 process.

  \[ \] RQ-98    Ensure portable devices with Bluetooth interfaces are
                 configured with a password to prevent unauthorized
                 access if lost or stolen.

  \[ \] RQ-99    Install antivirus software and fully test and deploy
                 software Bluetooth patches and upgrades regularly.
  -------------- --------------------------------------------------------

#### Suggested Considerations

#### Management

  -------------- --------------------------------------------------------
  \[ \] SC-26    Develop a bureau policy addressing the use of
                 Bluetooth-enabled devices.

  \[ \] SC-27    Ensure users are fully trained in computer security
                 awareness and the risks associated with Bluetooth.

  \[ \] SC-28    Ensure handheld or small Bluetooth devices are protected
                 from theft and are turned off during all hours when they
                 are not used.
  -------------- --------------------------------------------------------

#### Technical

  -------------- --------------------------------------------------------
  \[ \] SC-29    Set Bluetooth devices to the lowest necessary and
                 sufficient power level so transmission remains within
                 secure perimeter.

  \[ \] SC-30    Ensure the Bluetooth "bonding" environment is secure
                 from eavesdroppers.
  -------------- --------------------------------------------------------

#### Operational

  -------------- --------------------------------------------------------
  \[ \] SC-31    Deploy intrusion detection agents on the wireless part
                 of the network to detect suspicious behavior or
                 unauthorized access and activity.

  -------------- --------------------------------------------------------

### Checklist for Handhelds

#### Requirements (RQ)

#### Management

  -------------- --------------------------------------------------------
  \[ \] RQ-100   Ensure users know where to report a lost or stolen
                 device.

  \[ \] RQ-101   Enable a "power-on" password for each handheld device.

  \[ \] RQ-102   Ensure desktop application-mirroring software is
                 password-protected.

  \[ \] RQ-103   Install antivirus software on all handheld devices.
  -------------- --------------------------------------------------------

#### Technical

  -------------- --------------------------------------------------------
  \[ \] RC-104   Ensure a user can be securely authenticated when
                 operating locally and remotely.

  \[ \] RC-105   Use FIPS 140-2 compliant encryption and password
                 protection utilities for the protection of sensitive
                 data files and applications
  -------------- --------------------------------------------------------

### Suggested Considerations 

#### Management

  -------------- --------------------------------------------------------
  \[ \] SC-32    Conduct ongoing security audits to monitor and track
                 devices.

  \[ \] SC-33    Label all handheld devices with the owner and agency's
                 information.

  \[ \] SC-34    Ensure devices are stored securely when left unattended.

  \[ \] SC-35    Ensure proper password management (aging, complexity,
                 etc.) for all handheld devices.

  \[ \] SC-36    Store data on backup storage modules in encrypted form.

  \[ \] SC-37    Ensure all devices have timeout mechanisms automatically
                 prompting the user for a password after a period of
                 inactivity.
  -------------- --------------------------------------------------------

#### Technical

  -------------- --------------------------------------------------------
  \[ \] SC-38    Use enterprise security applications to manage handheld
                 device security.

  \[ \] SC-39    When disposing of handheld devices that will no longer
                 be used by the agency, clear configuration settings to
                 prevent the disclosure of sensitive network information.
  -------------- --------------------------------------------------------

#  

# Appendix D

## Disk and Data Sanitization Policy, Guidance, and Procedures (September 2007)

### PURPOSE

This document establishes and defines the policy for all Department of
the Interior (DOI) bureaus and offices (federal and contractor
employees) who have a requirement to dispose of or reuse unclassified
computer storage media that contains Sensitive Security Information
(SSI) or For Official Use Only (FOUO) information. This policy does not
pertain to any computer storage media that contains Classified (i.e.,
Secret, Top Secret) information.

DOI bureau and office employees and support contractors shall take
reasonable and appropriate steps to control NAS, Mission Support, and
Administrative computer storage media through its entire lifecycle
commensurate with the sensitivity of its associated data.

Such controls include protecting, accounting for, properly storing,
backup and disposal of the computer storage media in accordance with
applicable DOI Orders.

The guidance and procedures contained in this document will be followed
when re-appropriating or disposing of computer storage media that
contain For Official Use Only (FOUO) and/or Sensitive But Unclassified
information (SBU), and systems identified having completed a Privacy
Impact Assessment (PIA).

Prior to executing any procedure that deletes data or the destruction of
computer storage media, the Regional Property Disposal Official (PDO)
must be notified.

### SCOPE

These procedures for the sanitization of computer storage media are
intended to protect against reasonable attempts to recover any data that
may have been stored on the media. These procedures pertain to data
(sensitive or otherwise) contained on computer storage media (e.g., hard
disk drives (HDD), disk drives (zip disks, memory sticks and floppy
disks), optical disc storage (compact disks (CD), DVD, (Digital
Versatile Disc)).

Computer storage media located at DOI site(s) that is owned or managed
by other government agencies (i.e., DoD, FBI) will follow the procedures
and /or guidelines for reusing or destroying storage media dictated by
that particular agency. If the computer storage media is DOI-owned but
contains sensitive information owned by an outside agency (i.e., DoD),
then the media sanitization procedures directed by the outside agency
must be followed. If the DOI division Information System Security
Officer (ISSO) determines that the outside agency's media sanitization
procedures are better than or are equally effective as the procedures
outlined in this document, then no other action is necessary. If the
outside agency's procedures are unknown or less stringent, then the
procedures outlined in this document should be followed. These
procedures also apply to all computer storage media containing data
owned by the DOI, including media that are contractor- and
vendor-owned/managed.

### BACKGROUND

In order for the DOI to assure confidentiality, integrity and
availability of information assets it is important to have documented
policies and procedures that govern the receipt, removal and destruction
of computer storage media. This document provides recommended procedures
to protect such data when disposing of or reusing computer storage
media. These procedures do not pertain to computer storage media
containing classified, (i.e., Secret, Top Secret, Confidential)
information. Refer to DOI Order 1600.2D, Safeguarding Controls and
Procedures for Classified National Security Information and Sensitive
Unclassified Information.

### REFERENCES

-   NIST Special Publication 800-88, *Guidelines for Media
    Sanitization*.

-   NIST Special Publication 800-53, *Recommended Security Controls for
    Federal Information Systems,* require information or media be
    purged, overwritten, degaussed, or destroyed when disposed or used
    elsewhere.

-   NIST Special Publication 800-53A, *Guide for Assessing the Security
    Controls in Federal Information Systems*.

-   NIST Special Publication 800-36, *Guide to Selecting Information
    Technology Security Products*; Section 5.9, Media Sanitizing.

-   NIST Special Publication 800-64, Security Considerations in the
    Information System Development Life Cycle; Section 2.3.5.2, Media
    Sanitization.

### RESPONSIBILITIES

The BCISOs are responsible for establishing and maintaining any
bureau/office level IT security policies to further augment the policies
contained within this handbook or that are needed to address IT security
issues unique to their respective organization as appropriate. Updates
to the contents of this policy handbook will be performed on a yearly
basis to be responsive to technology changes and changes in the
Information System Security (ISS) threat environment. Recommendations
for changes are to be sent to the ITST for review and update.

The ISSO's are responsible for implementing this policy within their
organizations and ensuring that the processes and procedures are
integrated into existing system lifecycle management activities.

### EXPLANATION OF SECURITY RISKS

The surplus, transfer, trade-in, disposal of computers, or replacement
of computer storage media, and computer software could create security
risks for the agency information assets. These risks are related to the
unauthorized release of sensitive and/or confidential information that
might be stored on the hard disks and other storage media, and the
potential violation of software license agreements. It should be noted
that all agency computer storage media, especially those containing
sensitive and/or confidential data, shall have all data securely
removed, as specified by this policy, before a computer system is
surplused, transferred, traded-in, otherwise disposed of, or before the
computer storage media is replaced.

### Guidance

#### Disposal Guidance

It is important to recognize that when files are deleted from computer
storage media using operating system commands designed to delete data or
format disks they do not, in fact, remove all the data. Commands like,
"del, delete, rm, drag_to_trash" only free up the space that the deleted
files consumed. Most of the actual file data remains on the computer
storage media. There are a number of forensics products that can read
this data and produce a clear picture of what data had been stored in
the files prior to deletion. Therefore, unless vendor supplied operating
system commands and utilities have been specifically designed to
sanitize media, they should not be used for this purpose.

It is expected that system owners and their local property
administrators will be responsible for ensuring that all computer
storage media turned in for recycling or transfer to a third-party will
be properly sanitized before leaving DOI's possession. Local property
administrators should be prepared to either sanitize the media
themselves (and keep a record of the activity) or else contract with a
vendor that specializes in media sanitization.

If the equipment is leased, refer to the terms in the leasing/license
agreements. Leased equipment, in most cases, must be returned to the
leasing company with the original operating system installed. This also
applies where the original operating system has been upgraded during the
course of the equipment's lease.

#### Software License Liability

Without proper documentation, equipment operating systems may not be
transferred with the equipment. Few application licenses are
transferable. Unless an organization's software asset management
procedures are able to identify and document licenses that are eligible
for transfer, the best practice is to sanitize the computer storage
media. Always read the End User License Agreement (EULA)/ Software
License Agreement before transferring equipment with software installed.

In general most EULAs allow permanently transfer all of individual
rights under the applicable EULA, provided no copies are retained, and
that all of the Product (including all components, updates, the media
and printed materials, any upgrades, and the EULA) are transferred. If
the Product is an upgrade, any transfer must include all prior versions
of the Product. If the Product is received as part of a subscription,
any transfer must include all prior deliverables of Product and all
other subscription deliverables.

Always read and comply with the software End User License Agreement
(EULA)/Software License Agreement before transferring computers with
software installed.

#### Sanitization Guidance

The following procedures should be followed when agency computer storage
media is transferred for sale, transfer to another organization, or
disposal by other means.

-   Before computer storage media is transferred, all sensitive and/or
    confidential program or data files on any computer storage media
    should be completely erased or otherwise made unreadable unless
    there is specific intent to transfer the particular software or data
    to the recipient according to procedure outlined in NIST SP 800-88;

-   The computer storage media should be relocated to a designated,
    secure storage area within the organization until the data can be
    erased;

-   The computer storage media of surplus equipment should be securely
    erased within 30 days after replacement; and

-   Whenever licensed software is resident on any computer storage media
    being transferred, traded-in, disposed of, or the hard drive is
    replaced, the terms of the End User License Agreement (EULA)/
    Software License Agreement will be followed.

After the sanitization of the hard drive is complete, the process should
be certified and a written record maintained using a form which
describes the legal penalty for falsification of statements per 18 USC
1001.

#### Sanitization Types for Hard Drives 

There are three recommended methods for the sanitization of hard drives:

1.  Overwriting;

2.  Degaussing; and

3.  Physical destruction

The best method to be used for sanitization depends upon the operability
of the hard drive.

Operable hard drives that will be reused must be overwritten prior to
disposition. If the operable hard drive is to be removed from service
completely, it must be physically destroyed or degaussed; and

If the hard drive is inoperable or has reached the end of its useful
life, it must be physically destroyed or degaussed.

#### Sanitization By Overwriting 

Overwriting is an approved method for sanitization of hard disk drives.
Overwriting of data means replacing previously stored data on a drive or
disk with a predetermined pattern of meaningless information. This
effectively renders the data unrecoverable. The sanitization software
product used for the overwriting process should meet the following
specifications:

-   The data should be properly overwritten with a pattern;

-   Sanitization should not be considered complete until six overwrite
    passes of the three cycles and a verification pass is completed;

-   The software should have the capability to overwrite the entire hard
    disk drive, independent of any BIOS or firmware capacity limitation
    that the system may have, making it impossible to recover any
    meaningful data;

-   The software should have the capability to overwrite using a minimum
    of six passes of the three cycles of data patterns on all sectors,
    blocks, tracks, and any unused disk space on the entire hard disk
    medium; and,

-   The software should have a method to verify that all data has been
    removed.

If data is \"successfully\" overwritten, even one pass of pseudorandom
data, it can be considered as unrecoverable for all practical purposes.
For example, it may take many hours to overwrite all sectors on a disk
just once.

#### Sanitization By Degaussing 

Degaussing is the use of an external de-magnetizer designed to reduce
any magnetic flux recorded on the media. It is accomplished by producing
alternating currents to create an electro magnetic field that will
reverse magnetize all fields on the surface. Due to the variation of
media formats and their corresponding magnetic densities, a correct and
effective degaussing process is often difficult to achieve. Degaussing
is an acceptable and effective method and is far more appropriate for
tape, diskettes, or removable media than it is for fixed hard disk
drives.

The following recommended standards and procedures may be followed when
hard drives are degaussed:

-   Follow the product manufacturer's directions carefully. It is
    essential to determine the appropriate rate of coercivity for
    degaussing;

-   Shielding materials (cabinets, mounting brackets), which may
    interfere with the degausser's magnetic field, should be removed
    from the hard drive before degaussing; and

-   Hard disk platters should be in a horizontal direction during the
    degaussing process.

#### Sanitization By Physical Destruction 

Hard drives should be destroyed when they are defective or cannot be
repaired or sanitized for reuse.

Physical destruction should be accomplished to an extent that precludes
any possible further use of the hard drive. This destruction can be
accomplished by removing the hard drive from the cabinet, removing any
steel shielding materials and/or mounting brackets and then cutting the
electrical connection to the hard drive unit.

Disassemble the Head Disk Assembly and remove the platters from the
spindle. Once the platters have been physically removed, score several
lines with a metallic instrument and scrape off the magnetic media
substrate material coating on the platter. Dispose the platter and Head
Disk Assembly in separate containers.

#### File Sanitization

File sanitization involves securely removing specific files from
computer storage media while generally leaving the operating system and
supporting programs in place.

If the overwrite software, such as Erase 5.7, is used on a small number
of files then it will not take long to overwrite XX times. This option
could be considered for highly sensitive files, however you need to
consider the possibility that backup or working copies of those files
may exist elsewhere on the computer storage media.

The following files should be considered for removal:

##### Computer-Created Files

  ----------------------------------- -----------------------------------
  Backup files                        Log files

  Configuration files                 Printer spool files

  Cookies                             Swap files

  Hidden files                        System files

  History files                       Temporary files
  ----------------------------------- -----------------------------------

##### User-Created Files

  ----------------------------------- -----------------------------------
  Address books                       E-mail files

  Audio/video files                   Image/graphic files

  Calendars                           Internet bookmarks/favorites

  Database files                      Spreadsheet files

  Documents or text files             
  ----------------------------------- -----------------------------------

### Recommended Guidance for the Sanitization of Other Computer Storage Media

#### CD/DVD, Tape and Diskette Destruction

Sensitive data that is stored on CD/DVDs must be destroyed by defacing
the medium; the physically scratching with a sharp object the labeled
side of the CD/DVD. This will remove reflective coding underneath the
CD/DVD label, which will make the CD/DVD unreadable by the CD/DVD drive.
Scratching in either a spiral pattern or a series of scratches forming a
square will ensure the discs are not usable. Media shredders are
recommended.

Tape, if not reused can be cut and disposed, diskettes floppy platter
should be removed and cut into several pieces and disposed.

#### Other Media and Devices 

Finally, in addition to overwriting fixed disks, floppy and zip disks,
CD\'s, there are other media that pose privacy/security risks. For
example, network devices, routers, PDA\'s (hand held Personal Digital
Assistants) can have agency information stored as personal data or
configuration information. Prior to transfer or disposal this data or
configuration information should be cleared manually and by someone who
understands the device(s) in question. If sensitive data cannot be
removed then the device must be physically destroyed.

For cell phone devices cancel subscription service, delete phonebook
data, archived email and message data, and remove memory chips if
possible.

#### Verification 

After erasing is complete, using software that c perform verification of
the surface on the drive to be sure that the last overwriting pass was
performed properly and data residing on drive matches data written by
the erasing process. Verification is a long process and a percentage of
the surface can be specified and verification can be turned off
completely.

#### Perform Backups

There is no possible way of recovering files easily once they have been
overwritten by disk erasing software. Considerable precautions must be
taken to ensure the required data has been transferred before the disk
is erased. Take whatever backups are considered reasonable for the
circumstances.

#### Record Keeping Management

Appropriate record keeping will provide greater certainty that the
correct disks have been erased. The computer storage media requiring
secure erasure should be adequately labeled so everyone involved can
refer to them accurately. Comply with the department's Records
Management policy to ensure no personnel records are destroyed by this
process and that records are retained for the periods specified by the
policy. The original user of each computer should certify that all
needed information has been recovered before handing it over. File the
records in the official record keeping system for the workplace.

#### Procedures for Sanitizing Hard Disks 

Before leaving the agency, workstations delivered to excess property or
transferred to another user shall be sanitized using one of the
following procedures.

##### Intel compatible processor based systems (Regardless of the OS installed on the drive) 

1.  Remove the computer from the network.

2.  Remove all boot-up and BIOS passwords.

3.  Download the KillDisk\* from Lsoft Technologies utility to a
    bootable floppy disk.

4.  Reboot the system from the floppy drive containing KillDisk, and
    follow instructions on the screen. Instructions are included in the
    file.

The number of passes is determined by the sensitivity of the data being
deleted. Again, it may take many hours to overwrite all sectors on a
disk just once. It has been noted that it took more than 12 hours to
complete one pass of a 13GB drive. This will probably be the factor that
determines how many overwrites to perform. For most of the non-sensitive
files it will be sufficient to overwrite the disk just once. For
sensitive data it\'s a question of how valuable the data on the drive
is.

Reformat the system and load a bootable operating system (i.e., DOS or
Windows) to ensure that the system is no longer useable before being
surplused.

Do not add boot-up and BIOS passwords.

If the computer will not boot and/or all its internal hard drives are
not immediately accessible by sanitizing software, the hard drives shall
be rendered permanently inoperative via physical or magnetic
destruction. The system unit shall be marked as containing a
non-functional hard drive.

# Appendix E -- Certification and Request for Determination of Non-Sensitive Data 

Memorandum

To: Michael Howell

> Department Chief Information Officer

From: \< Bureau Designated Approving/Accrediting Authority \>

Subject: Certification and Request for Determination of Non-Sensitive
Data

Acknowledging the requirements set forth in OMB memorandum M-06-16 and
the September 8, 2006 OCIO memorandum *Clarification Regarding
Protection of Personally Identifiable (PII) Information and Department
Sensitive Information*, I hereby certify, based on the information
provided to me, that the mobile/portable/remote computer(s)/device(s)
identified in the attached document(s) contain only
**[non-sensitive]{.underline}** data and have appropriate management,
operational and/or technical controls in place to prevent DOI sensitive
data from being introduced into the computer(s)/devices(s).

I understand and acknowledge the risks that DOI sensitive information
may pose if it is inadvertently or accidentally introduced into the
mobile/portable/remote computer(s)/device(s) identified. Based on the
policies and procedures I have implemented, I believe the probability of
such an event occurring has been adequately reduced and I accept the
associated and attendant residual risks. Based upon my certification and
the evidence accompanying this request, I am requesting your approval of
this determination that the specified computer(s)/device(s) contain only
non-sensitive data thereby relieving the requirement for those systems
to be encrypted.

Appended to this certification and request is a list of the
mobile/portable/remote computer(s)/device(s) for which a determination
is being requested. Also accompanying this request is a copy of the
signed "Request for Non-Sensitive Data Determination and Acknowledgement
of Non-Sensitive Data Requirements" for each of the identified devices.

Contingent upon your approval, my organization will:

-   maintain this document, as well as your response, as an official
    record associated with the subject computer(s)/device(s) until final
    disposition and appropriate disposal of the computer(s)/device(s);

-   track usage of the computer(s)/devices(s) to ensure continued
    compliance with applicable data protection policies and the
    conditions of this request;

-   review all information on the computer(s)/device(s) for sensitive
    data at least annually and more frequently if necessary;

-   ensure that the "Request for Non-Sensitive Data Determination and
    Acknowledgement of Non-Sensitive Data Requirements" form is updated,
    re-signed, and re-authorized whenever any information provided on
    the form changes and at least annually thereafter; and

-   ensure that this document is revised and re-submitted for my
    signature, and your approval, whenever any information provided
    regarding this request changes and at least annually thereafter.

Designated Approving/Accrediting Authority Date

Chief Information Officer, DOI Date

Approved:

Disapproved:

+-------+----------+---------------+---------------+------------------+
| \<    |          |               |               |                  |
| Burea |          |               |               |                  |
| u/Off |          |               |               |                  |
| ice\> |          |               |               |                  |
+-------+----------+---------------+---------------+------------------+
| Make  | Model    | Serial Number | Asset Tag     | Authorized       |
|       |          |               | Number        | User(s)          |
|       |          |               |               |                  |
|       |          |               | (or           |                  |
|       |          |               | equivalent if |                  |
|       |          |               | available)    |                  |
+-------+----------+---------------+---------------+------------------+
| The   |          |               |               |                  |
| foll  |          |               |               |                  |
| owing |          |               |               |                  |
| is an |          |               |               |                  |
| ex    |          |               |               |                  |
| ample |          |               |               |                  |
| entry |          |               |               |                  |
| for a |          |               |               |                  |
| s     |          |               |               |                  |
| ingle |          |               |               |                  |
| compu |          |               |               |                  |
| ter/d |          |               |               |                  |
| evice |          |               |               |                  |
| ass   |          |               |               |                  |
| igned |          |               |               |                  |
| to a  |          |               |               |                  |
| s     |          |               |               |                  |
| ingle |          |               |               |                  |
| user  |          |               |               |                  |
+-------+----------+---------------+---------------+------------------+
| D     |          |               |               | User Name        |
| evice |          |               |               |                  |
| #1    |          |               |               |                  |
+-------+----------+---------------+---------------+------------------+
| The   |          |               |               |                  |
| foll  |          |               |               |                  |
| owing |          |               |               |                  |
| is an |          |               |               |                  |
| ex    |          |               |               |                  |
| ample |          |               |               |                  |
| entry |          |               |               |                  |
| for a |          |               |               |                  |
| s     |          |               |               |                  |
| ingle |          |               |               |                  |
| compu |          |               |               |                  |
| ter/d |          |               |               |                  |
| evice |          |               |               |                  |
| ass   |          |               |               |                  |
| igned |          |               |               |                  |
| to    |          |               |               |                  |
| mul   |          |               |               |                  |
| tiple |          |               |               |                  |
| users |          |               |               |                  |
|       |          |               |               |                  |
| (     |          |               |               |                  |
| e.g., |          |               |               |                  |
| s     |          |               |               |                  |
| ingle |          |               |               |                  |
| compu |          |               |               |                  |
| ter/d |          |               |               |                  |
| evice |          |               |               |                  |
| desig |          |               |               |                  |
| nated |          |               |               |                  |
| for   |          |               |               |                  |
| s     |          |               |               |                  |
| hared |          |               |               |                  |
| mo    |          |               |               |                  |
| bile/ |          |               |               |                  |
| porta |          |               |               |                  |
| ble/r |          |               |               |                  |
| emote |          |               |               |                  |
| comp  |          |               |               |                  |
| uting |          |               |               |                  |
| use   |          |               |               |                  |
| by    |          |               |               |                  |
| more  |          |               |               |                  |
| than  |          |               |               |                  |
| one   |          |               |               |                  |
| user) |          |               |               |                  |
+-------+----------+---------------+---------------+------------------+
| D     |          |               |               | User Name #1     |
| evice |          |               |               |                  |
| #2    |          |               |               | User Name #2     |
|       |          |               |               |                  |
|       |          |               |               | User Name #3     |
|       |          |               |               |                  |
|       |          |               |               | User Name #4     |
|       |          |               |               |                  |
|       |          |               |               | User Name #5     |
+-------+----------+---------------+---------------+------------------+
| The   |          |               |               |                  |
| foll  |          |               |               |                  |
| owing |          |               |               |                  |
| is an |          |               |               |                  |
| ex    |          |               |               |                  |
| ample |          |               |               |                  |
| entry |          |               |               |                  |
| for   |          |               |               |                  |
| mul   |          |               |               |                  |
| tiple |          |               |               |                  |
| co    |          |               |               |                  |
| mpute |          |               |               |                  |
| rs/de |          |               |               |                  |
| vices |          |               |               |                  |
| ass   |          |               |               |                  |
| igned |          |               |               |                  |
| to    |          |               |               |                  |
| mul   |          |               |               |                  |
| tiple |          |               |               |                  |
| users |          |               |               |                  |
|       |          |               |               |                  |
| (     |          |               |               |                  |
| e.g., |          |               |               |                  |
| a     |          |               |               |                  |
| pool  |          |               |               |                  |
| of    |          |               |               |                  |
| co    |          |               |               |                  |
| mpute |          |               |               |                  |
| rs/de |          |               |               |                  |
| vices |          |               |               |                  |
| desig |          |               |               |                  |
| nated |          |               |               |                  |
| for   |          |               |               |                  |
| s     |          |               |               |                  |
| hared |          |               |               |                  |
| mo    |          |               |               |                  |
| bile/ |          |               |               |                  |
| porta |          |               |               |                  |
| ble/r |          |               |               |                  |
| emote |          |               |               |                  |
| comp  |          |               |               |                  |
| uting |          |               |               |                  |
| use   |          |               |               |                  |
| by    |          |               |               |                  |
| more  |          |               |               |                  |
| than  |          |               |               |                  |
| one   |          |               |               |                  |
| user) |          |               |               |                  |
+-------+----------+---------------+---------------+------------------+
| D     |          |               |               | User Name #1     |
| evice |          |               |               |                  |
| #3    |          |               |               | User Name #2     |
|       |          |               |               |                  |
| D     |          |               |               | User Name #3     |
| evice |          |               |               |                  |
| #4    |          |               |               | User Name #4     |
|       |          |               |               |                  |
| D     |          |               |               | User Name #5     |
| evice |          |               |               |                  |
| #5    |          |               |               |                  |
|       |          |               |               |                  |
| D     |          |               |               |                  |
| evice |          |               |               |                  |
| #6    |          |               |               |                  |
|       |          |               |               |                  |
| D     |          |               |               |                  |
| evice |          |               |               |                  |
| #7    |          |               |               |                  |
+-------+----------+---------------+---------------+------------------+

Memorandum

To: \< Bureau Chief Information Officer \>

Through: \< Bureau Chief Information Security Officer \>

From: \< Requesting User name \>

Subject: Request for Non-Sensitive Data Determination and
Acknowledgement of Non-Sensitive Data Requirements

#### Background:

The Office of Management and Budget (OMB) requires the encryption of all
data on mobile/portable computers/devices containing agency information
unless the information is determined to be non-sensitive, in writing, by
Interior's Deputy Secretary or an individual he/she may designate in
writing. Encryption provides assurances that, in the event a
mobile/portable/ remote computer/device is lost or stolen, the recovery
of sensitive information is extremely difficult, if not impossible.

#### Applicability:

I understand that all of the OMB and DOI data protection requirements
relating to encryption are required until the Department CIO approves
the determination that the information residing on the
mobile/portable/remote computer/device is **NOT** sensitive. I also
understand that the requirement for encryption is no longer required
only upon receipt of a signed approval, in writing from the Department's
CIO.

The following mobile/portable/remote computer(s)/device(s) (is/are)
covered under this request:

+-----------+-------------+--------------------+----------------------+
| Make      | Model       | Serial Number      | Asset Tag Number     |
|           |             |                    |                      |
|           |             |                    | (or equivalent if    |
|           |             |                    | available)           |
+-----------+-------------+--------------------+----------------------+
|           |             |                    |                      |
+-----------+-------------+--------------------+----------------------+
|           |             |                    |                      |
+-----------+-------------+--------------------+----------------------+

#### 

#### Responsibilities: 

I understand that it is **[my]{.underline}** responsibility to ensure
that **NO** sensitive information is introduced into the
computer(s)/device(s) listed above and that I must contact my Bureau
Chief Information Security Officer any time I have doubts as to the
sensitivity of information **[BEFORE]{.underline}** the information is
introduced into the device(s). Finally, I understand that I must
immediately notify my Bureau Chief Information Security Officer if I
believe sensitive information might have been introduced into the
computer(s)/device(s). To quote Secretary Kempthorne, "If in doubt . . .
don't."

#### Penalties:

I understand that actions for noncompliance shall be handled in
accordance with Departmental and Bureau personnel policies and the DOI
Personnel Handbook on Charges and Penalty Selection for Disciplinary and
Adverse Actions. In the case where adverse disciplinary action is
contemplated, supervisors shall consult the Human Resources Office
immediately.

I also understand that contractors are expected to comply with all
Federal and DOI applicable policies, procedures, and guidelines. Failure
to do so could result in removal of access to DOI systems to removal
from the contract to criminal prosecution where appropriate.

#### Certification:

I certify that the computer(s)/devices(s) identified in Part 2 of this
request contain **NO** sensitive information. I further certify that I
will not knowingly introduce sensitive information into the identified
computer(s)/devices(s). I acknowledge my responsibilities regarding the
protection of sensitive information and understand them fully. I further
understand my responsibilities associated with the use and care of the
computer(s)/device(s) entrusted to me under this request. Finally, I
understand the types of information that are considered to be Personally
Identifiable Information (PII) and that such information is also
considered to be sensitive information that must **NOT** be introduced
into the computer(s)/devices(s) covered by this request.

Requesting User Date

Recommend:

Approval:

Disapproval:

Bureau Chief Information Security Officer, *\<bureau\>* Date

Recommend:

Approval:

Disapproval:

Chief Information Officer, *\<bureau\>* Date

NOTE 1: Additional Requesting User blocks must be added to support
multiple users of a single system. **ALL users that have access to the
above computer(s)/device(s) must sign this document.**

NOTE 2: Additional approval or recommendation blocks may be added by the
bureaus as they deem appropriate to support their internal process(es).

[^1]: OMB Memorandum M-07-19, FY 2007 Reporting Instructions for the
    Federal Information Security Management Act and Agency Privacy
    Management

[^2]: see <http://csrc.nist.gov/fdcc/>

[^3]: see <http://nvd.nist.gov/ncp.cfm> or <http://checklists.nist.gov/>

[^4]: see <http://nvd.nist.gov/>

[^5]: see <http://csrc.nist.gov/>

[^6]: <http://nvd.nist.gov/scap.cfm>

[^7]: <http://nvd.nist.gov/tools.cfm>

[^8]: see <http://www.us-cert.gov/> and <http://www.kb.cert.org/vuls/>

[^9]: see <https://portal.us-cert.gov/>

[^10]: see <http://nvd.nist.gov/> and <http://csrc.nist.gov/>

[^11]: <http://www.doi.gov/ocio/privacy>

[^12]: <http://uscode.house.gov/download/pls/15C7.txt>

[^13]: http://www.mydoi.doi.net/ocio/directives.html

[^14]: see <http://www.us-cert.gov/> and <http://www.kb.cert.org/vuls/>

[^15]: see <https://portal.us-cert.gov/>

[^16]: see <http://nvd.nist.gov/> and <http://csrc.nist.gov/>