diff --git a/README.md b/README.md index afabdbf..5152e83 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ They can be used as stand-alone documents. But the structure is designed to be best suited for use with the [`jupiter-policy-builder` CLI][builder] and the **policies** app on the **[JupiterOne][j1]** platform. -These are used internally at JupiterOne / LifeOmic Security. +These are used internally at JupiterOne Security. [j1]: https://jupiterone.com/features/policy-builder/ [builder]: https://github.com/JupiterOne/jupiter-policy-builder @@ -201,3 +201,14 @@ and is therefore under HIPAA regulation and has adopted HITRUST CSF. The JSON documents for those four frameworks are included strictly because of our internal usage and shown as examples. Using those requires that you have obtained necessary end-user license for the framework for your own organization. + +### Scripts + +`parse_oscal.py` + +The scripts included in this repository take a well-maintained source on the web and transform it into a format that the Compliance App can parse to provide a baseline or standard to application users. Most of them require arguments, and need to be run manually before creating a PR to merge updates into the main branch. So, the general process is: +1. Clone the repository, or pull updates from the main branch +2. Checkout a branch on which to build your updates +3. Run the script, providing the necessary arguments (run with -h to figure out what those are) +4. Add the changed files to a commit and push it to the origin for review +5. Once reviewed, merge and update in the app itself. \ No newline at end of file diff --git a/parse_oscal.py b/parse_oscal.py new file mode 100755 index 0000000..bbec09d --- /dev/null +++ b/parse_oscal.py @@ -0,0 +1,236 @@ +#!/usr/bin/env python + +import argparse, json, re, requests, sys + +# based on OSCAL v1.0.4 + +def createArgumentParser(): + parser = argparse.ArgumentParser( + prog = 'OSCAL Parser and Converter', + description = 'Given an input URL that points to a JSON version of an OSCAL baseline/standard file and an output path/filename, parse the OSCAL into a format that the JupiterOne compliance app can read and use.', + usage = 'Both a URL and a destination file name/path are required as this script needs an input (the URL) and an output (the destination filepath)' + ) + parser.add_argument('-u', '--url', required=True, help="The URL of where the JSON version of the OSCAL file baseline/standard that you want parsed exists. e.g.: https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog.json") + parser.add_argument('-o', '--output', required=True, help="The path and filename of the output for this parser, such as templates/standards/fedramp/v5/fedramp-moderate.json") + return parser + + +def getOSCAL(url: str): + response = requests.get(url) + if response.status_code == 200: + return response.json() + +def parseGroups(groupsList: list) -> dict: + #print('parseGroups') + domainsDict = {} + for group in groupsList: + key = group['id'] + #print('Group key: {}'.format(key)) + domainsDict[key] = {'text': group['title']} + #print("domainsDict[{}]['text']: {}".format(key, group['title'])) + if 'controls' in group: + domainsDict[key].update(parseControls(group['controls'])) + return domainsDict + +def parseProps(propsList: list) -> str: + for prop in propsList: + if prop['name'] == 'label': + return prop['value'] + +def parseControls(controlsList: list) -> dict: + #print('parseControls') + controlsDict = {} + for control in controlsList: + key = parseProps(control['props']) + #print('Control key: {}'.format(key)) + controlsDict[key] = {'text': control['title']} + #print("controlsDict[{}]['text']: {}".format(key, control['title'])) + paramsDict = {} + if 'params' in control: + unresolvedParamsDict = parseParams(control['params']) + paramsDict = resolveVars(unresolvedParamsDict, unresolvedParamsDict) + if 'parts' in control: + controlsDict[key].update(resolveVars(paramsDict, parseParts(control['parts']))) + if 'controls' in control: + controlsDict[key]['controls'] = parseControls(control['controls']) + return controlsDict + +def parseParts(partsList: list) -> dict: + #print('parseParts') + partsDict = {} + for part in partsList: + key = None + if part['name'] == 'statement': + #print('part is a statement') + if 'props' in part: + #print('found props in part') + key = parseProps(part['props']) + #print('part key: {}'.format(key)) + else: + #print('no props in part') + key = part['name'] + #print('part key: {}'.format(key)) + partsDict[key] = {} + # recurse as necessary + if 'parts' in part: + #print('found parts in part') + if 'prose' in part: + #print('found prose in part that has parts') + partsDict[key]['text'] = part['prose'] + #print("partsDict[{}]['text']: {}".format(key, part['prose'])) + else: + #print('no prose in part that has parts') + key = part['name'] + #print('part key: {}'.format(key)) + partsDict[key] = {} + #print('recurse to resolve parts in part') + partsDict[key].update(parseParts(part['parts'])) + else: + #print('no parts in part') + key = part['name'] + #print('part key: {}'.format(key)) + partsDict[key] = part['prose'] + elif part['name'] == 'item': + #print('part is an item') + key = '' + if 'props' in part: + key = parseProps(part['props']) + else: + key = part['title'] + #print('part key: {}'.format(key)) + partsDict[key] = {} + if 'parts' in part: + #print('found parts in part') + if 'prose' in part: + partsDict[key]['text'] = part['prose'] + #print("partsDict[{}]['text']: {}".format(key, part['prose'])) + #print('recurse to resolve parts in part') + partsDict[key].update(parseParts(part['parts'])) + else: + #print('part is a simple item') + #print('partsDict[{}]: {}'.format(key, part['prose'])) + partsDict[key] = part['prose'] + elif part['name'] == 'guidance': + #print('part is guidance') + key = part['name'] + #print('part key: {}'.format(key)) + partsDict[key] = part['prose'] + return partsDict + +def resolveVars(valuesDict: dict, varsDict: dict) -> dict: + OSCAL_var_pattern = re.compile(r'(?P{{\s*insert:\s*param,\s*(?P.*?)\s*}})') + for key, value in varsDict.items(): + if isinstance(value, dict): + #print('value is a dict, recursing...') + varsDict[key] = resolveVars(valuesDict, value) + else: + #print('Checking "{}"'.format(value)) + matcherator = OSCAL_var_pattern.finditer(value) + for match in matcherator: + #print('Replacing "{}" in "{}" with "{}"'.format(match['entire_var'], varsDict[key], valuesDict[match['var_name']])) + varsDict[key] = re.sub(match['entire_var'], valuesDict[match['var_name']], varsDict[key]) + #print('varsDict[{}]: {}'.format(key, varsDict[key])) + return varsDict + +def parseParams(paramList : list) -> dict: + paramDict = {} + for param in paramList: + key = param['id'] + if 'constraints' in param: + paramDict[key] = ', '.join([constraint['description'] for constraint in param['constraints']]) + if 'select' in param: + paramDict[key] = re.sub(r'Selection:\s*', '', paramDict[key]) + elif 'select' in param: + if 'how-many' in param['select']: + paramDict[key] = "{{{{ {}: {} }}}}".format(param['select']['how-many'].replace('-', ' '), ', '.join(param['select']['choice'])) + else: + paramDict[key] = '{{{{ {} }}}}'.format(' OR '.join(param['select']['choice'])) + elif 'guidelines' in param: + guidelineText = ', '.join(guideline['prose'] for guideline in param['guidelines']) + paramDict[key] = "{{{{ {} - {} }}}}".format(param['label'], guidelineText) + elif 'label' in param: + paramDict[key] = '{{{{ {} }}}}'.format(param['label']) + return paramDict + +def dictSubValue(oldDict: dict, pattern, newValue: str) -> dict: + newDict = {} + for key, value in oldDict.items(): + if isinstance(value, dict): + value = dictSubValue(value, pattern, newValue) + elif isinstance(value, list): + value = listSubValue(value, pattern, newValue) + elif isinstance(value, str): + value = pattern.sub(newValue, value) + newDict[key] = value + return newDict + +def listSubValue(oldList: dict, pattern, newValue: str) -> list: + newList = [] + for element in oldList: + if isinstance(element, list): + element = listSubValue(element, oldValue, newValue) + elif isinstance(element, dict): + element = dictSubValue(element, oldValue, newValue) + elif isinstance(element, str): + element = pattern.sub(newValue, element) + newList.append(element) + return newList + +def removeBookmarks(domainsDict: dict) -> dict: + BOOKMARK_pattern = re.compile(r'\(#.+?\)') + return dictSubValue(domainsDict, BOOKMARK_pattern, '') + +def buildSummary(someDict: dict, indent: int = 0) -> str: + summaryStr = '' + for key, value in someDict.items(): + #print('key: {}'.format(key)) + if isinstance(value, dict): + #print('value is a dict, recurse') + summaryStr += '\n{} {}'.format(key, buildSummary(value, indent)) if key != 'text' and key != 'statement' else '\n{}'.format(buildSummary(value, indent)) + elif key != 'guidance': + #print('value: {}'.format(value)) + summaryStr += '\n{} {}'.format(key, value) if key != 'text' and key != 'statement' else '\n{}'.format(value) + # remove leading line feed before returning constructed string + return re.sub(r'^\n', '', summaryStr, count=1) + +def createSecurityPolicyTemplate(domainsDict: dict) -> list: + domainsList = [] + for domain, domainDict in domainsDict.items(): + listDict = { + 'title': domainDict['text'], + 'controls': [] + } + controlsList = [] + for controlKey, controlDict in domainDict.items(): + # key is either text (str), statement (dict), guidance (str), or controls (dict) + if controlKey != 'text': + dictToAppend = { + 'ref': controlKey, + 'title': controlDict['text'], + 'summary': buildSummary(controlDict), + 'guidance': controlDict['guidance'] if 'guidance' in controlDict else '' + } + controlsList.append(dictToAppend) + listDict['controls'] = controlsList + domainsList.append(listDict) + return domainsList + +p = createArgumentParser() +args = p.parse_args() +OSCAL_JSON = getOSCAL(args.url) +catalog = OSCAL_JSON['catalog'] +domainsDict = {} +domainsDict = parseGroups(catalog['groups']) +domainsDict = removeBookmarks(domainsDict) +#print(json.dump(domainsDict, sys.stdout, ensure_ascii=True, indent=4, sort_keys=False)) + +securityPolicyDict = { + 'standard': catalog['metadata']['title'], + 'version': re.search(r'(?PRev\s*\w+)', catalog['metadata']['title'])['version'], + 'basedOn': catalog['metadata']['version'], + 'webLink': args.url, + 'domains': createSecurityPolicyTemplate(domainsDict) +} + +with open(args.output, 'w') as out_file: + json.dump(securityPolicyDict, out_file, ensure_ascii=True, indent=4, sort_keys=False) \ No newline at end of file diff --git a/templates/standards/fedramp/v5/fedramp-high.json b/templates/standards/fedramp/v5/fedramp-high.json index 25a850d..ed6a790 100644 --- a/templates/standards/fedramp/v5/fedramp-high.json +++ b/templates/standards/fedramp/v5/fedramp-high.json @@ -1,2198 +1,1244 @@ { - "standard": "FedRAMP High", - "version": "NIST 800-53r4", - "basedOn": "NIST 800-53r4", - "webLink": "https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx", - "domains": [ - { - "title": "ACCESS CONTROL", - "controls": [ - { - "ref": "AC-1", - "title": "Access Control Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the access control policy and associated access controls; and\n b. Reviews and updates the current:\n 1. Access control policy **at least annually**; and\n 2. Access control procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "AC-2", - "title": "Account Management", - "summary": "The organization:\n a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];\n b. Assigns account managers for information system accounts;\n c. Establishes conditions for group and role membership;\n d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;\n e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;\n f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];\n g. Monitors the use of, information system accounts;\n h. Notifies account managers:\n 1. When accounts are no longer required;\n 2. When users are terminated or transferred; and\n 3. When individual information system usage or need-to-know changes;\n i. Authorizes access to the information system based on:\n 1. A valid access authorization;\n 2. Intended system usage; and\n 3. Other attributes as required by the organization or associated missions/business functions;\n j. Reviews accounts for compliance with account management requirements **monthly for privileged accessed, every six (6) months for non-privileged access**; and\n k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group." - }, - { - "ref": "AC-2 (1)", - "title": "Account Management | Automated System Account Management", - "summary": "The organization employs automated mechanisms to support the management of information system accounts." - }, - { - "ref": "AC-2 (2)", - "title": "Account Management | Removal of Temporary / Emergency Accounts", - "summary": "The information system automatically [Selection: removes; disables] temporary and emergency accounts after **Selection: disables**." - }, - { - "ref": "AC-2 (3)", - "title": "Account Management | Disable Inactive Accounts", - "summary": "The information system automatically disables inactive accounts after **35 days for user accounts**." - }, - { - "ref": "AC-2 (4)", - "title": "Account Management | Automated Audit Actions", - "summary": "The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies **organization and/or service provider system owner**." - }, - { - "ref": "AC-2 (5)", - "title": "Account Management | Inactivity Logout", - "summary": "The organization requires that users log out when **inactivity is anticipated to exceed Fifteen (15) minutes**." - }, - { - "ref": "AC-2 (7)", - "title": "Account Management | Role-Based Schemes", - "summary": "The organization:\n(a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;\n(b) Monitors privileged role assignments; and\n(c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate." - }, - { - "ref": "AC-2 (9)", - "title": "Account Management | Restrictions on Use of Shared Groups / Accounts", - "summary": "The organization only permits the use of shared/group accounts that meet **organization-defined need with justification statement that explains why such accounts are necessary**." - }, - { - "ref": "AC-2 (10)", - "title": "Account Management | Shared / Group Account Credential Termination", - "summary": "The information system terminates shared/group account credentials when members leave the group." - }, - { - "ref": "AC-2 (11)", - "title": "Account Management | Usage Conditions", - "summary": "The information system enforces [Assignment: organization-defined circumstances and/or usage conditions] for [Assignment: organization-defined information system accounts]." - }, - { - "ref": "AC-2 (12)", - "title": "Account Management | Account Monitoring / Atypical Usage", - "summary": "The organization:\n (a) Monitors information system accounts for [Assignment: organization-defined atypical use]; and\n (b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "AC-2 (13)", - "title": "Account Management | Disable Accounts for High-Risk Individuals", - "summary": "The organization disables accounts of users posing a significant risk within **one (1) hour** of discovery of the risk." - }, - { - "ref": "AC-3", - "title": "Access Enforcement", - "summary": "The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies." - }, - { - "ref": "AC-4", - "title": "Information Flow Enforcement", - "summary": "The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Assignment: organization-defined information flow control policies]." - }, - { - "ref": "AC-4 (8)", - "title": "Information Flow Enforcement | Security Policy Filters", - "summary": "The information system enforces information flow control using [Assignment: organization-defined security policy filters] as a basis for flow control decisions for [Assignment: organization-defined information flows]." - }, - { - "ref": "AC-4 (21)", - "title": "Information Flow Enforcement | Physical / Logical Separation of Information Flows", - "summary": "The information system separates information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization- defined required separations by types of information]." - }, - { - "ref": "AC-5", - "title": "Separation of Duties", - "summary": "The organization:\n a. Separates [Assignment: organization-defined duties of individuals];\n b. Documents separation of duties of individuals; and\n c. Defines information system access authorizations to support separation of duties." - }, - { - "ref": "AC-6", - "title": "Least Privilege", - "summary": "The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions." - }, - { - "ref": "AC-6 (1)", - "title": "Least Privilege | Authorize Access To Security Functions", - "summary": "The organization explicitly authorizes access to **all functions not publicly accessible and all security-relevant information not publicly available**." - }, - { - "ref": "AC-6 (2)", - "title": "Least Privilege | Non-Privileged Access for Nonsecurity Functions", - "summary": "The organization requires that users of information system accounts, or roles, with access to **all security functions**, use non- privileged accounts or roles, when accessing nonsecurity functions." - }, - { - "ref": "AC-6 (3)", - "title": "Least Privilege | Network Access To Privileged Commands", - "summary": "The organization authorizes network access to **all privileged commands** only for [Assignment: organization-defined compelling operational needs] and documents the rationale for such access in the security plan for the information system." - }, - { - "ref": "AC-6 (5)", - "title": "Least Privilege | Privileged Accounts", - "summary": "The organization restricts privileged accounts on the information system to [Assignment:\norganization-defined personnel or roles]." - }, - { - "ref": "AC-6 (7)", - "title": "Least Privilege | Review of User Privileges", - "summary": "The organization:\n (a) Reviews [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and\n (b) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs." - }, - { - "ref": "AC-6 (8)", - "title": "Least Privilege | Privilege Levels for Code Execution", - "summary": "The information system prevents **any software except software explicitly documented** from executing at higher privilege levels than users executing the software." - }, - { - "ref": "AC-6 (9)", - "title": "Least Privilege | Auditing Use of Privileged Functions", - "summary": "The information system audits the execution of privileged functions." - }, - { - "ref": "AC-6 (10)", - "title": "Least Privilege | Prohibit Non-Privileged Users From Executing Privileged Functions", - "summary": "The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures." - }, - { - "ref": "AC-7", - "title": "Unsuccessful Logon Attempts", - "summary": "The information system:\n a. Enforces a limit of **not more than three (3)** consecutive invalid logon attempts by a user during a **fifteen (15) minutes**; and\n b. Automatically [Selection: locks the account/node for an **locks the account/node for a minimum of three (3) hours or until unlocked by an administrator**; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded." - }, - { - "ref": "AC-7 (2)", - "title": "Unsuccessful Logon Attempts | Purge / Wipe Mobile Device", - "summary": "The information system purges/wipes information from **mobile devices as defined by organization policy** based on **three (3)** after [Assignment: organization-defined number] consecutive, unsuccessful device logon attempts." - }, - { - "ref": "AC-8", - "title": "System Use Notification", - "summary": "The information system:\n a. Displays to users **see additional Requirements and Guidance** before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that:\n 1. Users are accessing a U.S. Government information system;\n 2. Information system usage may be monitored, recorded, and subject to audit;\n 3. Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and\n 4. Use of the information system indicates consent to monitoring and recording;\n b. Retains the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the information system; and \n c. For publicly accessible systems:\n 1. Displays system use information [Assignment: organization-defined conditions], before granting further access;\n 2. Displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and\n 3. Includes a description of the authorized uses of the system." - }, - { - "ref": "AC-10", - "title": "Concurrent Session Control", - "summary": "The information system limits the number of concurrent sessions for each **three (3) sessions for privileged access and two (2) sessions for non-privileged access** to [Assignment: organization-defined number]." - }, - { - "ref": "AC-11", - "title": "Session Lock", - "summary": "The information system:\n a. Prevents further access to the system by initiating a session lock after **fifteen (15) minutes** of inactivity or upon receiving a request from a user; and\n b. Retains the session lock until the user reestablishes access using established identification and authentication procedures." - }, - { - "ref": "AC-11 (1)", - "title": "Session Lock | Pattern-Hiding Displays", - "summary": "The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image." - }, - { - "ref": "AC-12", - "title": "Session Termination", - "summary": "The information system automatically terminates a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect]." - }, - { - "ref": "AC-12 (1)", - "title": "Session Termination | User-Initiated Logouts / Message Displays", - "summary": "The information system:\n (a) Provides a logout capability for user-initiated communications sessions whenever authentication is used to gain access to [Assignment: organization-defined information resources]; and\n (b) Displays an explicit logout message to users indicating the reliable termination of authenticated communications sessions." - }, - { - "ref": "AC-14", - "title": "Permitted Actions Without Identification or Authentication", - "summary": "The organization:\n a. Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and\n b. Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication." - }, - { - "ref": "AC-17", - "title": "Remote Access", - "summary": "The organization:\n a. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\n b. Authorizes remote access to the information system prior to allowing such connections." - }, - { - "ref": "AC-17 (1)", - "title": "Remote Access | Automated Monitoring / Control", - "summary": "The information system monitors and controls remote access methods." - }, - { - "ref": "AC-17 (2)", - "title": "Remote Access | Protection of Confidentiality / Integrity Using Encryption", - "summary": "The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions." - }, - { - "ref": "AC-17 (3)", - "title": "Remote Access | Managed Access Control Points", - "summary": "The information system routes all remote accesses through [Assignment: organization-defined number] managed network access control points." - }, - { - "ref": "AC-17 (4)", - "title": "Remote Access | Privileged Commands / Access", - "summary": "The organization:\n (a) Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and\n (b) Documents the rationale for such access in the security plan for the information system." - }, - { - "ref": "AC-17 (9)", - "title": "Remote Access | Disconnect / Disable Access", - "summary": "The organization provides the capability to expeditiously disconnect or disable remote access to the information system within **fifteen (15) minutes**." - }, - { - "ref": "AC-18", - "title": "Wireless Access", - "summary": "The organization:\n a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and\n b. Authorizes wireless access to the information system prior to allowing such connections." - }, - { - "ref": "AC-18 (1)", - "title": "Wireless Access | Authentication and Encryption", - "summary": "The information system protects wireless access to the system using authentication of [Selection\n(one or more): users; devices] and encryption." - }, - { - "ref": "AC-18 (3)", - "title": "Wireless Access | Disable Wireless Networking", - "summary": "The organization disables, when not intended for use, wireless networking capabilities internally embedded within information system components prior to issuance and deployment." - }, - { - "ref": "AC-18 (4)", - "title": "Wireless Access | Restrict Configurations By Users", - "summary": "The organization identifies and explicitly authorizes users allowed to independently configure wireless networking capabilities." - }, - { - "ref": "AC-18 (5)", - "title": "Wireless Access | Antennas / Transmission Power Levels", - "summary": "The organization selects radio antennas and calibrates transmission power levels to reduce the probability that usable signals can be received outside of organization-controlled boundaries." - }, - { - "ref": "AC-19", - "title": "Access Control for Mobile Devices", - "summary": "The organization:\n a. Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and\n b. Authorizes the connection of mobile devices to organizational information systems." - }, - { - "ref": "AC-19 (5)", - "title": "Access Control for Mobile Devices | Full Device / Container-Based Encryption", - "summary": "The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices]." - }, - { - "ref": "AC-20", - "title": "Use of External Information Systems", - "summary": "The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:\n a. Access the information system from external information systems; and\n b. Process, store, or transmit organization-controlled information using external information systems." - }, - { - "ref": "AC-20 (1)", - "title": "Use of External Information Systems | Limits on Authorized Use", - "summary": "The organization permits authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization:\n (a) Verifies the implementation of required security controls on the external system as specified in the organization’s information security policy and security plan; or\n (b) Retains approved information system connection or processing agreements with the organizational entity hosting the external information system." - }, - { - "ref": "AC-20 (2)", - "title": "Use of External Information Systems | Portable Storage Devices", - "summary": "The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems." - }, - { - "ref": "AC-21", - "title": "Information Sharing", - "summary": "The organization:\na. Facilitates information sharing by enabling authorized users to determine whether access authorizations assigned to the sharing partner match the access restrictions on the information for [Assignment: organization-defined information sharing circumstances where user discretion is required]; and\nb. Employs [Assignment: organization-defined automated mechanisms or manual processes] to assist users in making information sharing/collaboration decisions.\n \nSupplemental Guidance: This control applies to information that may be restricted in some manner (e.g., privileged medical information, contract-sensitive information, proprietary information, personally identifiable information, classified information related to special access programs or compartments) based on some formal or administrative determination. Depending on the particular information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment." - }, - { - "ref": "AC-22", - "title": "Publicly Accessible Content", - "summary": "The organization:\n a. Designates individuals authorized to post information onto a publicly accessible information system;\n b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\n c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and\n d. Reviews the content on the publicly accessible information system for nonpublic information **at least quarterly** and removes such information, if discovered." - } - ] - }, - { - "title": "AWARENESS AND TRAINING", - "controls": [ - { - "ref": "AT-1", - "title": "Security Awareness and Training Policy Andprocedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security awareness and training policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security awareness and training policy and associated security awareness and training controls; and\n b. Reviews and updates the current:\n 1. Security awareness and training policy **at least annually or whenever a significant change occurs**; and\n 2. Security awareness and training procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "AT-2", - "title": "Security Awareness Training", - "summary": "The organization provides basic security awareness training to information system users (including managers, senior executives, and contractors):\n a. As part of initial training for new users;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "AT-2 (2)", - "title": "Security Awareness | Insider Threat", - "summary": "The organization includes security awareness training on recognizing and reporting potential indicators of insider threat." - }, - { - "ref": "AT-3", - "title": "Role-Based Security Training", - "summary": "The organization provides role-based security training to personnel with assigned security roles and responsibilities:\na. Before authorizing access to the information system or performing assigned duties;\nb. When required by information system changes; and\nc. **at least annually** thereafter." - }, - { - "ref": "AT-3 (3)", - "title": "Security Training | Practical Exercises", - "summary": "The organization includes practical exercises in security training that reinforce training objectives." - }, - { - "ref": "AT-3 (4)", - "title": "Security Training | Suspicious Communications and Anomalous System Behavior", - "summary": "The organization provides training to its personnel on **malicious code indicators as defined by organization incident policy/capability** to recognize suspicious communications and anomalous behavior in organizational information systems." - }, - { - "ref": "AT-4", - "title": "Security Training Records", - "summary": "The organization:\n a. Documents and monitors individual information system security training activities including basic security awareness training and specific information system security training; and\n b. Retains individual training records for **five (5) years or 5 years after completion of a specific training program**." - } - ] - }, - { - "title": "AUDIT AND ACCOUNTABILITY", - "controls": [ - { - "ref": "AU-1", - "title": "Audit and Accountability Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and\n b. Reviews and updates the current:\n 1. Audit and accountability policy **at least annually**; and\n 2. Audit and accountability procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "AU-2", - "title": "Audit Events", - "summary": "The organization:\n a. Determines that the information system is capable of auditing the following events: **successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes**;\n b. Coordinates the security audit function with other organizational entities requiring audit- related information to enhance mutual support and to help guide the selection of auditable events;\n c. Provides a rationale for why the auditable events are deemed to be adequate to support after- the-fact investigations of security incidents; and\n d. Determines that the following events are to be audited within the information system: **organization-defined subset of the auditable events defined in AU-2a to be audited continually for each identified event**." - }, - { - "ref": "AU-2 (3)", - "title": "Audit Events | Reviews and Updates", - "summary": "The organization reviews and updates the audited events **annually or whenever there is a change in the threat environment**." - }, - { - "ref": "AU-3", - "title": "Content of Audit Records", - "summary": "The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event." - }, - { - "ref": "AU-3 (1)", - "title": "Content of Audit Records | Additional Audit Information", - "summary": "The information system generates audit records containing the following additional information: **session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands**." - }, - { - "ref": "AU-3 (2)", - "title": "Content of Audit Records | Centralized Management of Planned Audit Record Content", - "summary": "The information system provides centralized management and configuration of the content to be captured in audit records generated by **all network, data storage, and computing devices**." - }, - { - "ref": "AU-4", - "title": "Audit Storage Capacity", - "summary": "The organization allocates audit record storage capacity in accordance with [Assignment:\norganization-defined audit record storage requirements]." - }, - { - "ref": "AU-5", - "title": "Response To Audit Processing Failures", - "summary": "The information system:\n a. Alerts [Assignment: organization-defined personnel or roles] in the event of an audit processing failure; and\n b. Takes the following additional actions: [Assignment: organization-defined actions to be taken (e.g., shut down information system, overwrite oldest audit records, stop generating audit records)]." - }, - { - "ref": "AU-5 (1)", - "title": "Response To Audit Processing Failures | Audit Storage Capacity", - "summary": "The information system provides a warning to [Assignment: organization-defined personnel, roles, and/or locations] within [Assignment: organization-defined time period] when allocated audit record storage volume reaches [Assignment: organization-defined percentage] of repository maximum audit record storage capacity." - }, - { - "ref": "AU-5 (2)", - "title": "Response To Audit Processing Failures | Real-Time Alerts", - "summary": "The information system provides an alert in **real-time** to **service provider personnel with authority to address failed audit events** when the following audit failure events occur: **audit failure events requiring real-time alerts, as defined by organization audit policy**." - }, - { - "ref": "AU-6", - "title": "Audit Review, Analysis, and Reporting", - "summary": "The organization:\n a. Reviews and analyzes information system audit records **at least weekly** for indications of [Assignment: organization-defined inappropriate or unusual activity]; and\n b. Reports findings to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "AU-6 (1)", - "title": "Audit Review, Analysis, and Reporting | Process Integration", - "summary": "The organization employs automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities." - }, - { - "ref": "AU-6 (3)", - "title": "Audit Review, Analysis, and Reporting | Correlate Audit Repositories", - "summary": "The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness." - }, - { - "ref": "AU-6 (4)", - "title": "Audit Review, Analysis, and Reporting | Central Review and Analysis", - "summary": "The information system provides the capability to centrally review and analyze audit records from multiple components within the system." - }, - { - "ref": "AU-6 (5)", - "title": "Audit Review, Analysis, and Reporting | Integration / Scanning and Monitoring Capabilities", - "summary": "The organization integrates analysis of audit records with analysis of [Selection (one or more): vulnerability scanning information; performance data; information system monitoring information; **Organization -defined data/information collected from other sources]**] to further enhance the ability to identify inappropriate or unusual activity." - }, - { - "ref": "AU-6 (6)", - "title": "Audit Review, Analysis, and Reporting | Correlation With Physical Monitoring", - "summary": "The organization correlates information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual, or malevolent activity." - }, - { - "ref": "AU-6 (7)", - "title": "Audit Review, Analysis, and Reporting | Permitted Actions", - "summary": "The organization specifies the permitted actions for each [Selection (one or more): information system process; role; user] associated with the review, analysis, and reporting of audit information." - }, - { - "ref": "AU-6 (10)", - "title": "Audit Review, Analysis, and Reporting | Audit Level Adjustment", - "summary": "The organization adjusts the level of audit review, analysis, and reporting within the information system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information." - }, - { - "ref": "AU-7", - "title": "Audit Reduction and Report Generation", - "summary": "The information system provides an audit reduction and report generation capability that:\n a. Supports on-demand audit review, analysis, and reporting requirements and after-the-fact investigations of security incidents; and\n b. Does not alter the original content or time ordering of audit records." - }, - { - "ref": "AU-7 (1)", - "title": "Audit Reduction and Report Generation | Automatic Processing", - "summary": "The information system provides the capability to process audit records for events of interest based on [Assignment: organization-defined audit fields within audit records]." - }, - { - "ref": "AU-8", - "title": "Time Stamps", - "summary": "The information system:\n a. Uses internal system clocks to generate time stamps for audit records; and\n b. Records time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) and meets **one second granularity of time measurement**." - }, - { - "ref": "AU-8 (1)", - "title": "Time Stamps | Synchronization With Authoritative Time Source", - "summary": "The information system:\n (a) Compares the internal information system clocks **At least hourly** with [Assignment: organization-defined authoritative time source]; and\n (b) Synchronizes the internal system clocks to the authoritative time source when the time difference is greater than **At least hourly**." - }, - { - "ref": "AU-9", - "title": "Protection of Audit Information", - "summary": "The information system protects audit information and audit tools from unauthorized access, modification, and deletion." - }, - { - "ref": "AU-9 (2)", - "title": "Protection of Audit Information | Audit Backup on Separate Physical Systems / Components", - "summary": "The information system backs up audit records **at least weekly** onto a physically different system or system component than the system or component being audited." - }, - { - "ref": "AU-9 (3)", - "title": "Protection of Audit Information | Cryptographic Protection", - "summary": "The information system implements cryptographic mechanisms to protect the integrity of audit information and audit tools." - }, - { - "ref": "AU-9 (4)", - "title": "Protection of Audit Information | Access By Subset of Privileged Users", - "summary": "The organization authorizes access to management of audit functionality to only [Assignment: organization-defined subset of privileged users]." - }, - { - "ref": "AU-10", - "title": "Non-Repudiation", - "summary": "The information system protects against an individual (or process acting on behalf of an individual) falsely denying having performed **minimum actions including the addition, modification, deletion, approval, sending, or receiving of data**." - }, - { - "ref": "AU-11", - "title": "Audit Record Retention", - "summary": "The organization retains audit records for **at least one (1) year** to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements." - }, - { - "ref": "AU-12", - "title": "Audit Generation", - "summary": "The information system:\n a. Provides audit record generation capability for the auditable events defined in AU-2 a. at **all information system and network components where audit capability is deployed/available**;\n b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and\n c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3." - }, - { - "ref": "AU-12 (1)", - "title": "Audit Generation | System-Wide / Time-Correlated Audit Trail", - "summary": "The information system compiles audit records from **all network, data storage, and computing devices** into a system-wide (logical or physical) audit trail that is time- correlated to within [Assignment: organization-defined level of tolerance for relationship between time stamps of individual records in the audit trail]." - }, - { - "ref": "AU-12 (3)", - "title": "Audit Generation | Changes By Authorized Individuals", - "summary": "The information system provides the capability for **service provider-defined individuals or roles with audit configuration responsibilities** to change the auditing to be performed on **all network, data storage, and computing devices** based on [Assignment: organization-defined selectable event criteria] within [Assignment: organization-defined time thresholds]." - } - ] - }, - { - "title": "SECURITY ASSESSMENT AND AUTHORIZATION", - "controls": [ - { - "ref": "CA-1", - "title": "Security Assessment and Authorization Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security assessment and authorization policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security assessment and authorization policy and associated security assessment and authorization controls; and\n b. Reviews and updates the current:\n 1. Security assessment and authorization policy **at least annually**; and\n 2. Security assessment and authorization procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "CA-2", - "title": "Security Assessments", - "summary": "The organization:\n a. Develops a security assessment plan that describes the scope of the assessment including:\n 1. Security controls and control enhancements under assessment;\n 2. Assessment procedures to be used to determine security control effectiveness; and\n 3. Assessment environment, assessment team, and assessment roles and responsibilities;\n b. Assesses the security controls in the information system and its environment of operation **at least annually** to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements;\n c. Produces a security assessment report that documents the results of the assessment; and\n d. Provides the results of the security control assessment to **individuals or roles to include FedRAMP PMO**." - }, - { - "ref": "CA-2 (1)", - "title": "Security Assessments | Independent Assessors", - "summary": "The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to conduct security control assessments." - }, - { - "ref": "CA-2 (2)", - "title": "Security Assessments | Specialized Assessments", - "summary": "The organization includes as part of security control assessments, **at least annually**, [Selection: announced; unannounced], [Selection (one or more): in-depth monitoring; vulnerability scanning; malicious user testing; insider threat assessment; performance/load testing; [Assignment: organization-defined other forms of security assessment]]." - }, - { - "ref": "CA-2 (3)", - "title": "Security Assessments | External Organizations", - "summary": "The organization accepts the results of an assessment of **any FedRAMP Accredited 3PAO** performed by **any FedRAMP Accredited 3PAO** when the assessment meets **the conditions of the JAB/AO in the FedRAMP Repository**." - }, - { - "ref": "CA-3", - "title": "System Interconnections", - "summary": "The organization:\n a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements;\n b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and\n c. Reviews and updates Interconnection Security Agreements **at least annually and on input from FedRAMP**." - }, - { - "ref": "CA-3 (3)", - "title": "System Interconnections | Unclassified Non-National Security System Connections", - "summary": "The organization prohibits the direct connection of an **Boundary Protections which meet the Trusted Internet Connection (TIC) requirements** to an external network without the use of [Assignment; organization-defined boundary protection device]." - }, - { - "ref": "CA-3 (5)", - "title": "System Interconnections | Restrictions on External System Connections", - "summary": "The organization employs [Selection: allow-all, deny-by-exception; deny-all, permit-by-exception] policy for allowing **deny-all, permit by exception** to connect to external information systems." - }, - { - "ref": "CA-5", - "title": "Plan of Action and Milestones", - "summary": "The organization:\n a. Develops a plan of action and milestones for the information system to document the organization’s planned remedial actions to correct weaknesses or deficiencies noted during\nthe assessment of the security controls and to reduce or eliminate known vulnerabilities in the system; and\n b. Updates existing plan of action and milestones **at least monthly** based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities." - }, - { - "ref": "CA-6", - "title": "Security Authorization", - "summary": "The organization:\n a. Assigns a senior-level executive or manager as the authorizing official for the information system;\n b. Ensures that the authorizing official authorizes the information system for processing before commencing operations; and\n c. Updates the security authorization **at least every three (3) years or when a significant change occurs**." - }, - { - "ref": "CA-7", - "title": "Continuous Monitoring", - "summary": "The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:\n a. Establishment of [Assignment: organization-defined metrics] to be monitored;\n b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;\n c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;\n d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;\n e. Correlation and analysis of security-related information generated by assessments and monitoring;\n f. Response actions to address results of the analysis of security-related information; and\n g. Reporting the security status of organization and the information system to **to meet Federal and FedRAMP requirements** [Assignment: organization-defined frequency]." - }, - { - "ref": "CA-7 (1)", - "title": "Continuous Monitoring | Independent Assessment", - "summary": "The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to monitor the security controls in the information system on an ongoing basis." - }, - { - "ref": "CA-7 (3)", - "title": "Continuous Monitoring | Trend Analyses", - "summary": "The organization employs trend analyses to determine if security control implementations, the frequency of continuous monitoring activities, and/or the types of activities used in the continuous monitoring process need to be modified based on empirical data." - }, - { - "ref": "CA-8", - "title": "Penetration Testing", - "summary": "The organization conducts penetration testing **at least annually** on [Assignment: organization-defined information systems or system components]." - }, - { - "ref": "CA-8 (1)", - "title": "Penetration Testing | Independent Penetration Agent or Team", - "summary": "The organization employs an independent penetration agent or penetration team to perform penetration testing on the information system or system components." - }, - { - "ref": "CA-9", - "title": "Internal System Connections", - "summary": "The organization:\n a. Authorizes internal connections of [Assignment: organization-defined information system components or classes of components] to the information system; and\n b. Documents, for each internal connection, the interface characteristics, security requirements, and the nature of the information communicated." - } - ] - }, - { - "title": "CONFIGURATION MANAGEMENT", - "controls": [ - { - "ref": "CM-1", - "title": "Configuration Management Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the configuration management policy and associated configuration management controls; and\n b. Reviews and updates the current:\n 1. Configuration management policy **at least annually**; and\n 2. Configuration management procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "CM-2", - "title": "Baseline Configuration", - "summary": "The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system." - }, - { - "ref": "CM-2 (1)", - "title": "Baseline Configuration | Reviews and Updates", - "summary": "The organization reviews and updates the baseline configuration of the information system: \n (a) [Assignment: organization-defined frequency];\n (b) When required due to [Assignment organization-defined circumstances]; and\n (c) As an integral part of information system component installations and upgrades." - }, - { - "ref": "CM-2 (2)", - "title": "Baseline Configuration | Automation Support for Accuracy / Currency", - "summary": "The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system." - }, - { - "ref": "CM-2 (3)", - "title": "Baseline Configuration | Retention of Previous Configurations", - "summary": "The organization retains **organization-defined previous versions of baseline configurations of the previously approved baseline configuration of IS components** to support rollback." - }, - { - "ref": "CM-2 (7)", - "title": "Baseline Configuration | Configure Systems, Components, or Devices for High-Risk Areas", - "summary": "The organization:\n (a) Issues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and\n (b) Applies [Assignment: organization-defined security safeguards] to the devices when the individuals return." - }, - { - "ref": "CM-3", - "title": "Configuration Change Control", - "summary": "The organization:\n a. Determines the types of changes to the information system that are configuration-controlled;\n b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;\n c. Documents configuration change decisions associated with the information system;\n d. Implements approved configuration-controlled changes to the information system;\n e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\n f. Audits and reviews activities associated with configuration-controlled changes to the information system; and\n g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]]." - }, - { - "ref": "CM-3 (1)", - "title": "Configuration Change Control | Automated Document / Notification / Prohibition of Changes", - "summary": "The organization employs automated mechanisms to:\n (a) Document proposed changes to the information system;\n (b) Notify [Assignment: organized-defined approval authorities] of proposed changes to the information system and request change approval;\n (c) Highlight proposed changes to the information system that have not been approved or disapproved by [Assignment: organization-defined time period];\n (d) Prohibit changes to the information system until designated approvals are received; \n (e) Document all changes to the information system; and\n (f) Notify [Assignment: organization-defined personnel] when approved changes to the information system are completed." - }, - { - "ref": "CM-3 (2)", - "title": "Configuration Change Control | Test / Validate / Document Changes", - "summary": "The organization tests, validates, and documents changes to the information system before implementing the changes on the operational system." - }, - { - "ref": "CM-3 (4)", - "title": "Configuration Change Control | Security Representative", - "summary": "The organization requires an information security representative to be a member of the [Assignment: organization-defined configuration change control element]." - }, - { - "ref": "CM-3 (6)", - "title": "Configuration Change Control | Cryptography Management", - "summary": "The organization ensures that cryptographic mechanisms used to provide [Assignment: organization-defined security safeguards] are under configuration management." - }, - { - "ref": "CM-4", - "title": "Security Impact Analysis", - "summary": "The organization analyzes changes to the information system to determine potential security impacts prior to change implementation." - }, - { - "ref": "CM-4 (1)", - "title": "Security Impact Analysis | Separate Test Environments", - "summary": "The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice." - }, - { - "ref": "CM-5", - "title": "Access Restrictions for Change", - "summary": "The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system." - }, - { - "ref": "CM-5 (1)", - "title": "Access Restrictions for Change | Automated Access Enforcement / Auditing", - "summary": "The information system enforces access restrictions and supports auditing of the enforcement actions." - }, - { - "ref": "CM-5 (2)", - "title": "Access Restrictions for Change | Review System Changes", - "summary": "The organization reviews information system changes **at least every thirty (30) days** and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred." - }, - { - "ref": "CM-5 (3)", - "title": "Access Restrictions for Change | Signed Components", - "summary": "The information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization." - }, - { - "ref": "CM-5 (5)", - "title": "Access Restrictions for Change | Limit Production / Operational Privileges", - "summary": "The organization:\n (a) Limits privileges to change information system components and system-related information within a production or operational environment; and\n (b) Reviews and reevaluates privileges [Assignment: organization-defined frequency]." - }, - { - "ref": "CM-6", - "title": "Configuration Settings", - "summary": "The organization:\n a. Establishes and documents configuration settings for information technology products employed within the information system using **United States Government Configuration Baseline (USGCB)** that reflect the most restrictive mode consistent with operational requirements;\n b. Implements the configuration settings;\n c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and\n d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures." - }, - { - "ref": "CM-6 (1)", - "title": "Configuration Settings | Automated Central Management / Application / Verification", - "summary": "The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components]." - }, - { - "ref": "CM-6 (2)", - "title": "Configuration Settings | Respond To Unauthorized Changes", - "summary": "The organization employs [Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings]." - }, - { - "ref": "CM-7", - "title": "Least Functionality", - "summary": "The organization:\n a. Configures the information system to provide only essential capabilities; and\n b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: **United States Government Configuration Baseline (USGCB)**." - }, - { - "ref": "CM-7 (1)", - "title": "Least Functionality | Periodic Review", - "summary": "The organization:\n (a) Reviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or nonsecure functions, ports, protocols, and services; and\n (b) Disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or nonsecure]." - }, - { - "ref": "CM-7 (2)", - "title": "Least Functionality | Prevent Program Execution", - "summary": "The information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage]." - }, - { - "ref": "CM-7 (5)", - "title": "Least Functionality | Authorized Software / Whitelisting", - "summary": "The organization:\n (a) Identifies [Assignment: organization-defined software programs authorized to execute on the information system];\n (b) Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; and\n (c) Reviews and updates the list of authorized software programs [Assignment: organization- defined frequency]." - }, - { - "ref": "CM-8", - "title": "Information System Component Inventory", - "summary": "The organization:\n a. Develops and documents an inventory of information system components that:\n 1. Accurately reflects the current information system;\n 2. Includes all components within the authorization boundary of the information system;\n 3. Is at the level of granularity deemed necessary for tracking and reporting; and\n 4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\n b. Reviews and updates the information system component inventory **at least monthly**." - }, - { - "ref": "CM-8 (1)", - "title": "Information System Component Inventory | Updates During Installations / Removals", - "summary": "The organization updates the inventory of information system components as an integral part of component installations, removals, and information system updates." - }, - { - "ref": "CM-8 (2)", - "title": "Information System Component Inventory | Automated Maintenance", - "summary": "The organization employs automated mechanisms to help maintain an up-to-date, complete, accurate, and readily available inventory of information system components." - }, - { - "ref": "CM-8 (3)", - "title": "Information System Component Inventory | Automated Unauthorized Component Detection", - "summary": "The organization:\n (a) Employs automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\n (b) Takes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]]." - }, - { - "ref": "CM-8 (4)", - "title": "Information System Component Inventory | Accountability Information", - "summary": "The organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components." - }, - { - "ref": "CM-8 (5)", - "title": "Information System Component Inventory | No Duplicate Accounting of Components", - "summary": "The organization verifies that all components within the authorization boundary of the information system are not duplicated in other information system inventories." - }, - { - "ref": "CM-9", - "title": "Configuration Management Plan", - "summary": "The organization develops, documents, and implements a configuration management plan for the information system that:\n a. Addresses roles, responsibilities, and configuration management processes and procedures;\n b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;\n c. Defines the configuration items for the information system and places the configuration items under configuration management; and\n d. Protects the configuration management plan from unauthorized disclosure and modification." - }, - { - "ref": "CM-10", - "title": "Software Usage Restrictions", - "summary": "The organization:\na. Uses software and associated documentation in accordance with contract agreements and copyright laws;\nb. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Controls and documents the use of 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." - }, - { - "ref": "CM-10 (1)", - "title": "Software Usage Restrictions | Open Source Software", - "summary": "The organization establishes the following restrictions on the use of open source software: [Assignment: organization-defined restrictions]." - }, - { - "ref": "CM-11", - "title": "User-Installed Software", - "summary": "The organization:\n a. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\n b. Enforces software installation policies through [Assignment: organization-defined methods]; and\n c. Monitors policy compliance at **Continuously (via CM-7 (5))**." - }, - { - "ref": "CM-11 (1)", - "title": "User-Installed Software | Alerts for Unauthorized Installations", - "summary": "The information system alerts [Assignment: organization-defined personnel or roles] when the unauthorized installation of software is detected." - } - ] - }, - { - "title": "CONTINGENCY PLANNING", - "controls": [ - { - "ref": "CP-1", - "title": "Contingency Planning Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A contingency planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls; and\n b. Reviews and updates the current:\n 1. Contingency planning policy **at least annually**; and\n 2. Contingency planning procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "CP-2", - "title": "Contingency Plan", - "summary": "The organization:\n a. Develops a contingency plan for the information system that:\n 1. Identifies essential missions and business functions and associated contingency requirements;\n 2. Provides recovery objectives, restoration priorities, and metrics;\n 3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;\n 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and\n 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];\n c. Coordinates contingency planning activities with incident handling activities;\n d. Reviews the contingency plan for the information system **at least annually**;\n e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\n f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and\n g. Protects the contingency plan from unauthorized disclosure and modification." - }, - { - "ref": "CP-2 (1)", - "title": "Contingency Plan | Coordinate With Related Plans", - "summary": "The organization coordinates contingency plan development with organizational elements responsible for related plans." - }, - { - "ref": "CP-2 (2)", - "title": "Contingency Plan | Capacity Planning", - "summary": "The organization conducts capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations." - }, - { - "ref": "CP-2 (3)", - "title": "Contingency Plan | Resume Essential Missions / Business Functions", - "summary": "The organization plans for the resumption of essential missions and business functions within\n[Assignment: organization-defined time period] of contingency plan activation." - }, - { - "ref": "CP-2 (4)", - "title": "Contingency Plan | Resume All Missions / Business Functions", - "summary": "The organization plans for the resumption of all missions and business functions within\n**time period defined in service provider and organization SLA** of contingency plan activation." - }, - { - "ref": "CP-2 (5)", - "title": "Contingency Plan | Continue Essential Missions / Business Functions", - "summary": "The organization plans for the continuance of essential missions and business functions with little or no loss of operational continuity and sustains that continuity until full information system restoration at primary processing and/or storage sites." - }, - { - "ref": "CP-2 (8)", - "title": "Contingency Plan | Identify Critical Assets", - "summary": "The organization identifies critical information system assets supporting essential missions and business functions." - }, - { - "ref": "CP-3", - "title": "Contingency Training", - "summary": "The organization provides contingency training to information system users consistent with assigned roles and responsibilities:\n a. Within **ten (10) days** of assuming a contingency role or responsibility;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "CP-3 (1)", - "title": "Contingency Training | Simulated Events", - "summary": "The organization incorporates simulated events into contingency training to facilitate effective response by personnel in crisis situations." - }, - { - "ref": "CP-4", - "title": "Contingency Plan Testing", - "summary": "The organization:\n a. Tests the contingency plan for the information system **at least annually** using **functional exercises** to determine the effectiveness of the plan and the organizational readiness to execute the plan;\n b. Reviews the contingency plan test results; and\n c. Initiates corrective actions, if needed." - }, - { - "ref": "CP-4 (1)", - "title": "Contingency Plan Testing | Coordinate With Related Plans", - "summary": "The organization coordinates contingency plan testing with organizational elements responsible for related plans." - }, - { - "ref": "CP-4 (2)", - "title": "Contingency Plan Testing | Alternate Processing Site", - "summary": "The organization tests the contingency plan at the alternate processing site:\n (a) To familiarize contingency personnel with the facility and available resources; and\n (b) To evaluate the capabilities of the alternate processing site to support contingency operations." - }, - { - "ref": "CP-6", - "title": "Alternate Storage Site", - "summary": "The organization:\n a. Establishes an alternate storage site including necessary agreements to permit the storage and retrieval of information system backup information; and\n b. Ensures that the alternate storage site provides information security safeguards equivalent to that of the primary site." - }, - { - "ref": "CP-6 (1)", - "title": "Alternate Storage Site | Separation From Primary Site", - "summary": "The organization identifies an alternate storage site that is separated from the primary storage site to reduce susceptibility to the same threats." - }, - { - "ref": "CP-6 (2)", - "title": "Alternate Storage Site | Recovery Time / Point Objectives", - "summary": "The organization configures the alternate storage site to facilitate recovery operations in accordance with recovery time and recovery point objectives." - }, - { - "ref": "CP-6 (3)", - "title": "Alternate Storage Site | Accessibility", - "summary": "The organization identifies potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions." - }, - { - "ref": "CP-7", - "title": "Alternate Processing Site", - "summary": "The organization:\n a. Establishes an alternate processing site including necessary agreements to permit the transfer and resumption of [Assignment: organization-defined information system operations] for essential missions/business functions within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable;\n b. Ensures that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the organization-defined time period for transfer/resumption; and \n c. Ensures that the alternate processing site provides information security safeguards equivalent to that of the primary site." - }, - { - "ref": "CP-7 (1)", - "title": "Alternate Processing Site | Separation From Primary Site", - "summary": "The organization identifies an alternate processing site that is separated from the primary processing site to reduce susceptibility to the same threats." - }, - { - "ref": "CP-7 (2)", - "title": "Alternate Processing Site | Accessibility", - "summary": "The organization identifies potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions." - }, - { - "ref": "CP-7 (3)", - "title": "Alternate Processing Site | Priority of Service", - "summary": "The organization develops alternate processing site agreements that contain priority-of-service provisions in accordance with organizational availability requirements (including recovery time objectives)." - }, - { - "ref": "CP-7 (4)", - "title": "Alternate Processing Site | Preparation for Use", - "summary": "The organization prepares the alternate processing site so that the site is ready to be used as the operational site supporting essential missions and business functions." - }, - { - "ref": "CP-8", - "title": "Telecommunications Services", - "summary": "The organization establishes alternate telecommunications services including necessary agreements to permit the resumption of [Assignment: organization-defined information system operations] for essential missions and business functions within [Assignment: organization- defined time period] when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites." - }, - { - "ref": "CP-8 (1)", - "title": "Telecommunications Services | Priority of Service Provisions", - "summary": "The organization:\n (a) Develops primary and alternate telecommunications service agreements that contain priority- of-service provisions in accordance with organizational availability requirements (including recovery time objectives); and\n (b) Requests Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness in the event that the primary and/or alternate telecommunications services are provided by a common carrier." - }, - { - "ref": "CP-8 (2)", - "title": "Telecommunications Services | Single Points of Failure", - "summary": "The organization obtains alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services." - }, - { - "ref": "CP-8 (3)", - "title": "Telecommunications Services | Separation of Primary / Alternate Providers", - "summary": "The organization obtains alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats." - }, - { - "ref": "CP-8 (4)", - "title": "Telecommunications Services | Provider Contingency Plan", - "summary": "The organization:\n (a) Requires primary and alternate telecommunications service providers to have contingency plans;\n (b) Reviews provider contingency plans to ensure that the plans meet organizational contingency requirements; and\n (c) Obtains evidence of contingency testing/training by providers [Assignment: organization- defined frequency]." - }, - { - "ref": "CP-9", - "title": "Information System Backup", - "summary": "The organization:\na. Conducts backups of user-level information contained in the information system **daily incremental; weekly full**;\nb. Conducts backups of system-level information contained in the information system **daily incremental; weekly full**;\nc. Conducts backups of information system documentation including security-related documentation **daily incremental; weekly full**; and\nd. Protects the confidentiality, integrity, and availability of backup information at storage locations." - }, - { - "ref": "CP-9 (1)", - "title": "Information System Backup | Testing for Reliability / Integrity", - "summary": "The organization tests backup information **at least monthly** to verify media reliability and information integrity." - }, - { - "ref": "CP-9 (2)", - "title": "Information System Backup | Test Restoration Using Sampling", - "summary": "The organization uses a sample of backup information in the restoration of selected information system functions as part of contingency plan testing." - }, - { - "ref": "CP-9 (3)", - "title": "Information System Backup | Separate Storage for Critical Information", - "summary": "The organization stores backup copies of [Assignment: organization-defined critical information system software and other security-related information] in a separate facility or in a fire-rated container that is not collocated with the operational system." - }, - { - "ref": "CP-9 (5)", - "title": "Information System Backup | Transfer To Alternate Storage Site", - "summary": "The organization transfers information system backup information to the alternate storage site **time period and transfer rate consistent with the recovery time and recovery point objectives defined in the service provider and organization SLA**." - }, - { - "ref": "CP-10", - "title": "Information System Recovery and Reconstitution", - "summary": "The organization provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure." - }, - { - "ref": "CP-10 (2)", - "title": "Information System Recovery and Reconstitution | Transaction Recovery", - "summary": "The information system implements transaction recovery for systems that are transaction-based." - }, - { - "ref": "CP-10 (4)", - "title": "Information System Recovery and Reconstitution | Restore Within Time Period", - "summary": "The organization provides the capability to restore information system components within **time period consistent with the restoration time-periods defined in the service provider and organization SLA** from configuration-controlled and integrity-protected information representing a known, operational state for the components." - } - ] - }, - { - "title": "IDENTIFICATION AND AUTHENTICATION", - "controls": [ - { - "ref": "IA-1", - "title": "Identification and Authentication Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the identification and authentication policy and associated identification and authentication controls; and\n b. Reviews and updates the current:\n 1. Identification and authentication policy **at least annually**; and\n 2. Identification and authentication procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "IA-2", - "title": "Identification and Authentication (Organizational Users)", - "summary": "The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users)." - }, - { - "ref": "IA-2 (1)", - "title": "Identification and Authentication | Network Access To Privileged Accounts", - "summary": "The information system implements multifactor authentication for network access to privileged accounts." - }, - { - "ref": "IA-2 (2)", - "title": "Identification and Authentication | Network Access To Non-Privileged Accounts", - "summary": "The information system implements multifactor authentication for network access to non- privileged accounts." - }, - { - "ref": "IA-2 (3)", - "title": "Identification and Authentication | Local Access To Privileged Accounts", - "summary": "The information system implements multifactor authentication for local access to privileged accounts." - }, - { - "ref": "IA-2 (4)", - "title": "Identification and Authentication | Local Access To Non-Privileged Accounts", - "summary": "The information system implements multifactor authentication for local access to non-privileged accounts." - }, - { - "ref": "IA-2 (5)", - "title": "Identification and Authentication (Organizational Users) | Group Authentication", - "summary": "The organization requires individuals to be authenticated with an individual authenticator when a group authenticator is employed." - }, - { - "ref": "IA-2 (8)", - "title": "Identification and Authentication | Network Access To Privileged Accounts - Replay Resistant", - "summary": "The information system implements replay-resistant authentication mechanisms for network access to privileged accounts." - }, - { - "ref": "IA-2 (9)", - "title": "Identification and Authentication | Network Access To Non-Privileged Accounts - Replay Resistant", - "summary": "The information system implements replay-resistant authentication mechanisms for network access to non-privileged accounts." - }, - { - "ref": "IA-2 (11)", - "title": "Identification and Authentication | Remote Access - Separate Device", - "summary": "The information system implements multifactor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets **FIPS 140-2, NIAP Certification, or NSA approval**." - }, - { - "ref": "IA-2 (12)", - "title": "Identification and Authentication | Acceptance of Piv Credentials", - "summary": "The information system accepts and electronically verifies Personal Identity Verification (PIV)\ncredentials." - }, - { - "ref": "IA-3", - "title": "Device Identification and Authentication", - "summary": "The information system uniquely identifies and authenticates [Assignment: organization- defined specific and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection." - }, - { - "ref": "IA-4", - "title": "Identifier Management", - "summary": "The organization manages information system identifiers by:\n a. Receiving authorization from **at a minimum, the ISSO (or similar role within the organization)** to assign an individual, group, role, or device identifier;\n b. Selecting an identifier that identifies an individual, group, role, or device;\n c. Assigning the identifier to the intended individual, group, role, or device;\n d. Preventing reuse of identifiers for **at least two (2) years**; and\n e. Disabling the identifier after **thirty-five (35) days**." - }, - { - "ref": "IA-4 (4)", - "title": "Identifier Management | Identify User Status", - "summary": "The organization manages individual identifiers by uniquely identifying each individual as\n**contractors; foreign nationals**." - }, - { - "ref": "IA-5", - "title": "Authenticator Management", - "summary": "The organization manages information system authenticators by:\n a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator;\n b. Establishing initial authenticator content for authenticators defined by the organization;\n c. Ensuring that authenticators have sufficient strength of mechanism for their intended use;\n d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators;\n e. Changing default content of authenticators prior to information system installation;\n f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators;\n g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type];\n h. Protecting authenticator content from unauthorized disclosure and modification;\n i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and\n j. Changing authenticators for group/role accounts when membership to those accounts changes." - }, - { - "ref": "IA-5 (1)", - "title": "Authenticator Management | Password-Based Authentication", - "summary": "The information system, for password-based authentication:\n (a) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type];\n (b) Enforces at least the following number of changed characters when new passwords are created: [Assignment: organization-defined number];\n (c) Stores and transmits only encrypted representations of passwords;\n (d) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization- defined numbers for lifetime minimum, lifetime maximum];\n (e) Prohibits password reuse for [Assignment: organization-defined number] generations; and\n (f) Allows the use of a temporary password for system logons with an immediate change to a permanent password." - }, - { - "ref": "IA-5 (2)", - "title": "Authenticator Management | Pki-Based Authentication", - "summary": "The information system, for PKI-based authentication:\n (a) Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information;\n (b) Enforces authorized access to the corresponding private key;\n (c) Maps the authenticated identity to the account of the individual or group; and\n (d) Implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network." - }, - { - "ref": "IA-5 (3)", - "title": "Authenticator Management | In-Person or Trusted Third-Party Registration", - "summary": "The organization requires that the registration process to receive **All hardware/biometric (multifactor authenticators** be conducted [Selection: in person; by a trusted third party] before **in person** with authorization by [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "IA-5 (4)", - "title": "Authenticator Management | Automated Support for Password Strength Determination", - "summary": "The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy **complexity as identified in IA-5 (1) Control Enhancement Part (a)**." - }, - { - "ref": "IA-5 (6)", - "title": "Authenticator Management | Protection of Authenticators", - "summary": "The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access." - }, - { - "ref": "IA-5 (7)", - "title": "Authenticator Management | No Embedded Unencrypted Static Authenticators", - "summary": "The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys." - }, - { - "ref": "IA-5 (8)", - "title": "Authenticator Management | Multiple Information System Accounts", - "summary": "The organization implements **different authenticators on different systems** to manage the risk of compromise due to individuals having accounts on multiple information systems." - }, - { - "ref": "IA-5 (11)", - "title": "Authenticator Management | Hardware Token-Based Authentication", - "summary": "The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]." - }, - { - "ref": "IA-5 (13)", - "title": "Authenticator Management | Expiration of Cached Authenticators", - "summary": "The information system prohibits the use of cached authenticators after [Assignment: organization-defined time period]." - }, - { - "ref": "IA-6", - "title": "Authenticator Feedback", - "summary": "The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals." - }, - { - "ref": "IA-7", - "title": "Cryptographic Module Authentication", - "summary": "The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication." - }, - { - "ref": "IA-8", - "title": "Identification and Authentication (Non- Organizational Users)", - "summary": "The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users)." - }, - { - "ref": "IA-8 (1)", - "title": "Identification and Authentication | Acceptance of Piv Credentials From Other Agencies", - "summary": "The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies." - }, - { - "ref": "IA-8 (2)", - "title": "Identification and Authentication | Acceptance of Third-Party Credentials", - "summary": "The information system accepts only FICAM-approved third-party credentials." - }, - { - "ref": "IA-8 (3)", - "title": "Identification and Authentication | Use of Ficam-Approved Products", - "summary": "The organization employs only FICAM-approved information system components in [Assignment:\norganization-defined information systems] to accept third-party credentials." - }, - { - "ref": "IA-8 (4)", - "title": "Identification and Authentication | Use of Ficam-Issued Profiles", - "summary": "The information system conforms to FICAM-issued profiles." - } - ] - }, - { - "title": "INCIDENT RESPONSE", - "controls": [ - { - "ref": "IR-1", - "title": "Incident Response Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the incident response policy and associated incident response controls; and\n b. Reviews and updates the current:\n 1. Incident response policy **at least annually**; and\n 2. Incident response procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "IR-2", - "title": "Incident Response Training", - "summary": "The organization provides incident response training to information system users consistent with assigned roles and responsibilities:\n a. Within **within ten (10) days** of assuming an incident response role or responsibility;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "IR-2 (1)", - "title": "Incident Response Training | Simulated Events", - "summary": "The organization incorporates simulated events into incident response training to facilitate effective response by personnel in crisis situations." - }, - { - "ref": "IR-2 (2)", - "title": "Incident Response Training | Automated Training Environments", - "summary": "The organization employs automated mechanisms to provide a more thorough and realistic incident response training environment." - }, - { - "ref": "IR-3", - "title": "Incident Response Testing", - "summary": "The organization tests the incident response capability for the information system **at least every six (6) months** using [Assignment: organization-defined tests] to determine the incident response effectiveness and documents the results." - }, - { - "ref": "IR-3 (2)", - "title": "Incident Response Testing | Coordination With Related Plans", - "summary": "The organization coordinates incident response testing with organizational elements responsible for related plans." - }, - { - "ref": "IR-4", - "title": "Incident Handling", - "summary": "The organization:\na. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;\nb. Coordinates incident handling activities with contingency planning activities; and\nc. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly." - }, - { - "ref": "IR-4 (1)", - "title": "Incident Handling | Automated Incident Handling Processes", - "summary": "The organization employs automated mechanisms to support the incident handling process." - }, - { - "ref": "IR-4 (2)", - "title": "Incident Handling | Dynamic Reconfiguration", - "summary": "The organization includes dynamic reconfiguration of **all network, data storage, and computing devices** as part of the incident response capability." - }, - { - "ref": "IR-4 (3)", - "title": "Incident Handling | Continuity of Operations", - "summary": "The organization identifies [Assignment: organization-defined classes of incidents] and [Assignment: organization-defined actions to take in response to classes of incidents] to ensure continuation of organizational missions and business functions." - }, - { - "ref": "IR-4 (4)", - "title": "Incident Handling | Information Correlation", - "summary": "The organization correlates incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response." - }, - { - "ref": "IR-4 (6)", - "title": "Incident Handling | Insider Threats - Specific Capabilities", - "summary": "The organization implements incident handling capability for insider threats." - }, - { - "ref": "IR-4 (8)", - "title": "Incident Handling | Correlation With External Organizations", - "summary": "The organization coordinates with **external organizations including consumer incident responders and network defenders and the appropriate CIRT/CERT (such as US-CERT, DOD CERT, IC CERT)** to correlate and share [Assignment: organization-defined incident information] to achieve a cross- organization perspective on incident awareness and more effective incident responses." - }, - { - "ref": "IR-5", - "title": "Incident Monitoring", - "summary": "The organization tracks and documents information system security incidents." - }, - { - "ref": "IR-5 (1)", - "title": "Incident Monitoring | Automated Tracking / Data Collection / Analysis", - "summary": "The organization employs automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information." - }, - { - "ref": "IR-6", - "title": "Incident Reporting", - "summary": "The organization:\n a. Requires personnel to report suspected security incidents to the organizational incident response capability within **US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended)**; and\n b. Reports security incident information to [Assignment: organization-defined authorities]." - }, - { - "ref": "IR-6 (1)", - "title": "Incident Reporting | Automated Reporting", - "summary": "The organization employs automated mechanisms to assist in the reporting of security incidents." - }, - { - "ref": "IR-7", - "title": "Incident Response Assistance", - "summary": "The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents." - }, - { - "ref": "IR-7 (1)", - "title": "Incident Response Assistance | Automation Support for Availability of Information / Support", - "summary": "The organization employs automated mechanisms to increase the availability of incident response- related information and support." - }, - { - "ref": "IR-7 (2)", - "title": "Incident Response Assistance | Coordination With External Providers", - "summary": "The organization:\n (a) Establishes a direct, cooperative relationship between its incident response capability and external providers of information system protection capability; and\n (b) Identifies organizational incident response team members to the external providers." - }, - { - "ref": "IR-8", - "title": "Incident Response Plan", - "summary": "The organization:\n a. Develops an incident response plan that:\n 1. Provides the organization with a roadmap for implementing its incident response capability;\n 2. Describes the structure and organization of the incident response capability;\n 3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n 4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n 5. Defines reportable incidents;\n 6. Provides metrics for measuring the incident response capability within the organization;\n 7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and\n 8. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the incident response plan to **see additional FedRAMP Requirements and Guidance**;\n c. Reviews the incident response plan **at least annually**;\n d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;\n e. Communicates incident response plan changes to **see additional FedRAMP Requirements and Guidance**; and\nf. Protects the incident response plan from unauthorized disclosure and modification." - }, - { - "ref": "IR-9", - "title": "Information Spillage Response", - "summary": "The organization responds to information spills by:\n a. Identifying the specific information involved in the information system contamination;\n b. Alerting [Assignment: organization-defined personnel or roles] of the information spill using a method of communication not associated with the spill;\n c. Isolating the contaminated information system or system component;\n d. Eradicating the information from the contaminated information system or component;\n e. Identifying other information systems or system components that may have been subsequently contaminated; and\n f. Performing other [Assignment: organization-defined actions]." - }, - { - "ref": "IR-9 (1)", - "title": "Information Spillage Response | Responsible Personnel", - "summary": "The organization assigns [Assignment: organization-defined personnel or roles] with responsibility for responding to information spills." - }, - { - "ref": "IR-9 (2)", - "title": "Information Spillage Response | Training", - "summary": "The organization provides information spillage response training **at least annually**." - }, - { - "ref": "IR-9 (3)", - "title": "Information Spillage Response | Post-Spill Operations", - "summary": "The organization implements [Assignment: organization-defined procedures] to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions." - }, - { - "ref": "IR-9 (4)", - "title": "Information Spillage Response | Exposure To Unauthorized Personnel", - "summary": "The organization employs [Assignment: organization-defined security safeguards] for personnel exposed to information not within assigned access authorizations." - } - ] - }, - { - "title": "MAINTENANCE", - "controls": [ - { - "ref": "MA-1", - "title": "System Maintenance Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system maintenance policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system maintenance policy and associated system maintenance controls; and\n b. Reviews and updates the current:\n 1. System maintenance policy **at least annually**; and\n 2. System maintenance procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "MA-2", - "title": "Controlled Maintenance", - "summary": "The organization:\n a. Schedules, performs, documents, and reviews records of maintenance and repairs on information system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\n b. Approves and monitors all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location;\n c. Requires that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the information system or system components from organizational facilities for off-site maintenance or repairs;\n d. Sanitizes equipment to remove all information from associated media prior to removal from organizational facilities for off-site maintenance or repairs;\n e. Checks all potentially impacted security controls to verify that the controls are still functioning properly following maintenance or repair actions; and\n f. Includes [Assignment: organization-defined maintenance-related information] in organizational maintenance records." - }, - { - "ref": "MA-2 (2)", - "title": "Controlled Maintenance | Automated Maintenance Activities", - "summary": "The organization:\n (a) Employs automated mechanisms to schedule, conduct, and document maintenance and repairs; and\n (b) Produces up-to date, accurate, and complete records of all maintenance and repair actions requested, scheduled, in process, and completed." - }, - { - "ref": "MA-3", - "title": "Maintenance Tools", - "summary": "The organization approves, controls, and monitors information system maintenance tools." - }, - { - "ref": "MA-3 (1)", - "title": "Maintenance Tools | Inspect Tools", - "summary": "The organization inspects the maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications." - }, - { - "ref": "MA-3 (2)", - "title": "Maintenance Tools | Inspect Media", - "summary": "The organization checks media containing diagnostic and test programs for malicious code before the media are used in the information system." - }, - { - "ref": "MA-3 (3)", - "title": "Maintenance Tools | Prevent Unauthorized Removal", - "summary": "The organization prevents the unauthorized removal of maintenance equipment containing organizational information by:\n (a) Verifying that there is no organizational information contained on the equipment; \n (b) Sanitizing or destroying the equipment;\n (c) Retaining the equipment within the facility; or\n (d) Obtaining an exemption from [Assignment: organization-defined personnel or roles] explicitly authorizing removal of the equipment from the facility." - }, - { - "ref": "MA-4", - "title": "Nonlocal Maintenance", - "summary": "The organization:\n a. Approves and monitors nonlocal maintenance and diagnostic activities;\n b. Allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system;\n c. Employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions;\n d. Maintains records for nonlocal maintenance and diagnostic activities; and\n e. Terminates session and network connections when nonlocal maintenance is completed." - }, - { - "ref": "MA-4 (2)", - "title": "Nonlocal Maintenance | Document Nonlocal Maintenance", - "summary": "The organization documents in the security plan for the information system, the policies and procedures for the establishment and use of nonlocal maintenance and diagnostic connections." - }, - { - "ref": "MA-4 (3)", - "title": "Nonlocal Maintenance | Comparable Security / Sanitization", - "summary": "The organization:\n (a) Requires that nonlocal maintenance and diagnostic services be performed from an information system that implements a security capability comparable to the capability implemented on the system being serviced; or\n (b) Removes the component to be serviced from the information system and prior to nonlocal maintenance or diagnostic services, sanitizes the component (with regard to organizational information) before removal from organizational facilities, and after the service is performed, inspects and sanitizes the component (with regard to potentially malicious software) before reconnecting the component to the information system." - }, - { - "ref": "MA-4 (6)", - "title": "Nonlocal Maintenance | Cryptographic Protection", - "summary": "The information system implements cryptographic mechanisms to protect the integrity and confidentiality of nonlocal maintenance and diagnostic communications." - }, - { - "ref": "MA-5", - "title": "Maintenance Personnel", - "summary": "The organization:\n a. Establishes a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel;\n b. Ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and\n c. Designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations." - }, - { - "ref": "MA-5 (1)", - "title": "Maintenance Personnel | Individuals Without Appropriate Access", - "summary": "The organization:\n (a) Implements procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements:\n (1) Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the information system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified;\n (2) Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the information system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and\n (b) Develops and implements alternate security safeguards in the event an information system component cannot be sanitized, removed, or disconnected from the system." - }, - { - "ref": "MA-6", - "title": "Timely Maintenance", - "summary": "The organization obtains maintenance support and/or spare parts for [Assignment: organization-defined information system components] within [Assignment: organization-defined time period] of failure." - } - ] - }, - { - "title": "MEDIA PROTECTION", - "controls": [ - { - "ref": "MP-1", - "title": "Media Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A media protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the media protection policy and associated media protection controls; and\n b. Reviews and updates the current:\n 1. Media protection policy **at least annually**; and\n 2. Media protection procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "MP-2", - "title": "Media Access", - "summary": "The organization restricts access to **any digital and non-digital media deemed sensitive** to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "MP-3", - "title": "Media Marking", - "summary": "The organization:\n a. Marks information system media indicating the distribution limitations, handling caveats, and applicable security markings (if any) of the information; and\n b. Exempts **no removable media types** from marking as long as the media remain within **organization-defined security safeguards not applicable**." - }, - { - "ref": "MP-4", - "title": "Media Storage", - "summary": "The organization:\n a. Physically controls and securely stores **all types of digital and non-digital media with sensitive information** within **see additional FedRAMP requirements and guidance**; and\n b. Protects information system media until the media are destroyed or sanitized using approved equipment, techniques, and procedures." - }, - { - "ref": "MP-5", - "title": "Media Transport", - "summary": "The organization:\n a. Protects and controls [Assignment: organization-defined types of information system media] during transport outside of controlled areas using [Assignment: organization-defined security safeguards];\n b. Maintains accountability for information system media during transport outside of controlled areas;\n c. Documents activities associated with the transport of information system media; and\n d. Restricts the activities associated with the transport of information system media to authorized personnel." - }, - { - "ref": "MP-5 (4)", - "title": "Media Transport | Cryptographic Protection", - "summary": "The information system implements cryptographic mechanisms to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas." - }, - { - "ref": "MP-6", - "title": "Media Sanitization", - "summary": "The organization:\n a. Sanitizes **techniques and procedures IAW NIST SP 800-88 and Section 5.9: Reuse and Disposal of Storage Media and Hardware** prior to disposal, release out of organizational control, or release for reuse using [Assignment: organization- defined sanitization techniques and procedures] in accordance with applicable federal and organizational standards and policies; and\n b. Employs sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information." - }, - { - "ref": "MP-6 (1)", - "title": "Media Sanitization | Review / Approve / Track / Document / Verify", - "summary": "The organization reviews, approves, tracks, documents, and verifies media sanitization and disposal actions." - }, - { - "ref": "MP-6 (2)", - "title": "Media Sanitization | Equipment Testing", - "summary": "The organization tests sanitization equipment and procedures **at least every six (6) months** to verify that the intended sanitization is being achieved." - }, - { - "ref": "MP-6 (3)", - "title": "Media Sanitization | Nondestructive Techniques", - "summary": "The organization applies non-destructive sanitization techniques to portable storage devices prior to connecting such devices to the information system under the following circumstances: [Assignment: organization-defined circumstances requiring sanitization of portable storage devices]." - }, - { - "ref": "MP-7", - "title": "Media Use", - "summary": "The organization [Selection: restricts; prohibits] the use of [Assignment: organization- defined types of information system media] on [Assignment: organization-defined information systems or system components] using [Assignment: organization-defined security safeguards]." - }, - { - "ref": "MP-7 (1)", - "title": "Media Use | Prohibit Use Without Owner", - "summary": "The organization prohibits the use of portable storage devices in organizational information systems when such devices have no identifiable owner." - } - ] - }, - { - "title": "PHYSICAL AND ENVIRONMENTAL PROTECTION", - "controls": [ - { - "ref": "PE-1", - "title": "Physical and Environmental Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A physical and environmental protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the physical and environmental protection policy and associated physical and environmental protection controls; and\n b. Reviews and updates the current:\n 1. Physical and environmental protection policy **at least annually**; and\n 2. Physical and environmental protection procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "PE-2", - "title": "Physical Access Authorizations", - "summary": "The organization:\n a. Develops, approves, and maintains a list of individuals with authorized access to the facility where the information system resides;\n b. Issues authorization credentials for facility access;\n c. Reviews the access list detailing authorized facility access by individuals **at least every ninety (90) days**; and\n d. Removes individuals from the facility access list when access is no longer required." - }, - { - "ref": "PE-3", - "title": "Physical Access Control", - "summary": "The organization:\n a. Enforces physical access authorizations at [Assignment: organization-defined entry/exit points to the facility where the information system resides] by;\n 1. Verifying individual access authorizations before granting access to the facility; and\n 2. Controlling ingress/egress to the facility using [Selection (one or more): **CSP defined physical access control systems/devices AND guards**; guards];\n b. Maintains physical access audit logs for [Assignment: organization-defined entry/exit points];\n c. Provides [Assignment: organization-defined security safeguards] to control access to areas within the facility officially designated as publicly accessible;\n d. Escorts visitors and monitors visitor activity **in all circumstances within restricted access area where the information system resides**;\n e. Secures keys, combinations, and other physical access devices;\n f. Inventories **at least annually** every [Assignment: organization-defined frequency]; and\n g. Changes combinations and keys **at least annually** and/or when keys are lost, combinations are compromised, or individuals are transferred or terminated." - }, - { - "ref": "PE-3 (1)", - "title": "Physical Access Control | Information System Access", - "summary": "The organization enforces physical access authorizations to the information system in addition to the physical access controls for the facility at [Assignment: organization-defined physical spaces containing one or more components of the information system]." - }, - { - "ref": "PE-4", - "title": "Access Control for Transmission Medium", - "summary": "The organization controls physical access to [Assignment: organization-defined information system distribution and transmission lines] within organizational facilities using [Assignment: organization-defined security safeguards]." - }, - { - "ref": "PE-5", - "title": "Access Control for Output Devices", - "summary": "The organization controls physical access to information system output devices to prevent unauthorized individuals from obtaining the output." - }, - { - "ref": "PE-6", - "title": "Monitoring Physical Access", - "summary": "The organization:\n a. Monitors physical access to the facility where the information system resides to detect and respond to physical security incidents;\n b. Reviews physical access logs **at least monthly** and upon occurrence of [Assignment: organization-defined events or potential indications of events]; and\n c. Coordinates results of reviews and investigations with the organizational incident response capability." - }, - { - "ref": "PE-6 (1)", - "title": "Monitoring Physical Access | Intrusion Alarms / Surveillance Equipment", - "summary": "The organization monitors physical intrusion alarms and surveillance equipment." - }, - { - "ref": "PE-6 (4)", - "title": "Monitoring Physical Access | Monitoring Physical Access To Information Systems", - "summary": "The organization monitors physical access to the information system in addition to the physical access monitoring of the facility as [Assignment: organization-defined physical spaces containing one or more components of the information system]." - }, - { - "ref": "PE-8", - "title": "Visitor Access Records", - "summary": "The organization:\n a. Maintains visitor access records to the facility where the information system resides for **for a minimum of one (1) year**; and\n b. Reviews visitor access records **at least monthly**." - }, - { - "ref": "PE-8 (1)", - "title": "Visitor Access Records | Automated Records Maintenance / Review", - "summary": "The organization employs automated mechanisms to facilitate the maintenance and review of visitor access records." - }, - { - "ref": "PE-9", - "title": "Power Equipment and Cabling", - "summary": "The organization protects power equipment and power cabling for the information system from damage and destruction." - }, - { - "ref": "PE-10", - "title": "Emergency Shutoff", - "summary": "The organization:\n a. Provides the capability of shutting off power to the information system or individual system components in emergency situations;\n b. Places emergency shutoff switches or devices in [Assignment: organization-defined location by information system or system component] to facilitate safe and easy access for personnel; and\n c. Protects emergency power shutoff capability from unauthorized activation." - }, - { - "ref": "PE-11", - "title": "Emergency Power", - "summary": "The organization provides a short-term uninterruptible power supply to facilitate [Selection (one or more): an orderly shutdown of the information system; transition of the information system to long-term alternate power] in the event of a primary power source loss." - }, - { - "ref": "PE-11 (1)", - "title": "Emergency Power | Long-Term Alternate Power Supply - Minimal Operational Capability", - "summary": "The organization provides a long-term alternate power supply for the information system that is capable of maintaining minimally required operational capability in the event of an extended loss of the primary power source." - }, - { - "ref": "PE-12", - "title": "Emergency Lighting", - "summary": "The organization employs and maintains automatic emergency lighting for the information system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility." - }, - { - "ref": "PE-13", - "title": "Fire Protection", - "summary": "The organization employs and maintains fire suppression and detection devices/systems for the information system that are supported by an independent energy source." - }, - { - "ref": "PE-13 (1)", - "title": "Fire Protection | Detection Devices / Systems", - "summary": "The organization employs fire detection devices/systems for the information system that activate automatically and notify **service provider building maintenance/physical security personnel** and **service provider emergency responders with incident response responsibilities** in the event of a fire." - }, - { - "ref": "PE-13 (2)", - "title": "Fire Protection | Suppression Devices / Systems", - "summary": "The organization employs fire suppression devices/systems for the information system that provide automatic notification of any activation to Assignment: organization-defined personnel or roles] and [Assignment: organization-defined emergency responders]." - }, - { - "ref": "PE-13 (3)", - "title": "Fire Protection | Automatic Fire Suppression", - "summary": "The organization employs an automatic fire suppression capability for the information system when the facility is not staffed on a continuous basis." - }, - { - "ref": "PE-14", - "title": "Temperature and Humidity Controls", - "summary": "The organization:\n a. Maintains temperature and humidity levels within the facility where the information system resides at **consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments**; and\n b. Monitors temperature and humidity levels **continuously**." - }, - { - "ref": "PE-14 (2)", - "title": "Temperature and Humidity Controls | Monitoring With Alarms / Notifications", - "summary": "The organization employs temperature and humidity monitoring that provides an alarm or notification of changes potentially harmful to personnel or equipment." - }, - { - "ref": "PE-15", - "title": "Water Damage Protection", - "summary": "The organization protects the information system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel." - }, - { - "ref": "PE-15 (1)", - "title": "Water Damage Protection | Automation Support", - "summary": "The organization employs automated mechanisms to detect the presence of water in the vicinity of the information system and alerts **service provider building maintenance/physical security personnel**." - }, - { - "ref": "PE-16", - "title": "Delivery and Removal", - "summary": "The organization authorizes, monitors, and controls **all information system components** entering and exiting the facility and maintains records of those items." - }, - { - "ref": "PE-17", - "title": "Alternate Work Site", - "summary": "The organization:\n a. Employs [Assignment: organization-defined security controls] at alternate work sites;\n b. Assesses as feasible, the effectiveness of security controls at alternate work sites; and\n c. Provides a means for employees to communicate with information security personnel in case of security incidents or problems." - }, - { - "ref": "PE-18", - "title": "Location of Information System Components", - "summary": "The organization positions information system components within the facility to minimize potential damage from **physical and environmental hazards identified during threat assessment** and to minimize the opportunity for unauthorized access." - } - ] - }, - { - "title": "PLANNING", - "controls": [ - { - "ref": "PL-1", - "title": "Security Planning Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and\n b. Reviews and updates the current:\n 1. Security planning policy **at least annually**; and\n 2. Security planning procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "PL-2", - "title": "System Security Plan", - "summary": "The organization:\n a. Develops a security plan for the information system that:\n 1. Is consistent with the organization’s enterprise architecture;\n 2. Explicitly defines the authorization boundary for the system;\n 3. Describes the operational context of the information system in terms of missions and business processes;\n 4. Provides the security categorization of the information system including supporting rationale;\n 5. Describes the operational environment for the information system and relationships with or connections to other information systems;\n 6. Provides an overview of the security requirements for the system;\n 7. Identifies any relevant overlays, if applicable;\n 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and\n 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;\n b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles];\n c. Reviews the security plan for the information system **at least annually**;\n d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and\n e. Protects the security plan from unauthorized disclosure and modification." - }, - { - "ref": "PL-2 (3)", - "title": "System Security Plan | Plan / Coordinate With Other Organizational Entities", - "summary": "The organization plans and coordinates security-related activities affecting the information system with [Assignment: organization-defined individuals or groups] before conducting such activities in order to reduce the impact on other organizational entities." - }, - { - "ref": "PL-4", - "title": "Rules of Behavior", - "summary": "The organization:\n a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage;\n b. Receives a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system;\n c. Reviews and updates the rules of behavior **annually**; and d. Requires individuals who have signed a previous version of the rules of behavior to read and\nresign when the rules of behavior are revised/updated." - }, - { - "ref": "PL-4 (1)", - "title": "Rules of Behavior | Social Media and Networking Restrictions", - "summary": "The organization includes in the rules of behavior, explicit restrictions on the use of social media/networking sites and posting organizational information on public websites." - }, - { - "ref": "PL-8", - "title": "Information Security Architecture", - "summary": "The organization:\n a. Develops an information security architecture for the information system that:\n 1. Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information;\n 2. Describes how the information security architecture is integrated into and supports the enterprise architecture; and\n 3. Describes any information security assumptions about, and dependencies on, external services;\n b. Reviews and updates the information security architecture **at least annually or when a significant change occurs** to reflect updates in the enterprise architecture; and\n c. Ensures that planned information security architecture changes are reflected in the security plan, the security Concept of Operations (CONOPS), and organizational procurements/acquisitions." - } - ] - }, - { - "title": "PERSONNEL SECURITY", - "controls": [ - { - "ref": "PS-1", - "title": "Personnel Security Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A personnel security policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the personnel security policy and associated personnel security controls; and\n b. Reviews and updates the current:\n 1. Personnel security policy **at least annually**; and\n 2. Personnel security procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "PS-2", - "title": "Position Risk Designation", - "summary": "The organization:\n a. Assigns a risk designation to all organizational positions;\n b. Establishes screening criteria for individuals filling those positions; and\n c. Reviews and updates position risk designations **at least annually**." - }, - { - "ref": "PS-3", - "title": "Personnel Screening", - "summary": "The organization:\n a. Screens individuals prior to authorizing access to the information system; and\n b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening]." - }, - { - "ref": "PS-3 (3)", - "title": "Personnel Screening | Information With Special Protection Measures", - "summary": "The organization ensures that individuals accessing an information system processing, storing, or transmitting information requiring special protection:\n (a) Have valid access authorizations that are demonstrated by assigned official government duties; and\n (b) Satisfy [Assignment: organization-defined additional personnel screening criteria]." - }, - { - "ref": "PS-4", - "title": "Personnel Termination", - "summary": "The organization, upon termination of individual employment:\n a. Disables information system access within **eight (8) hours**;\n b. Terminates/revokes any authenticators/credentials associated with the individual;\n c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics];\n d. Retrieves all security-related organizational information system-related property;\n e. Retains access to organizational information and information systems formerly controlled by terminated individual; and\n f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]." - }, - { - "ref": "PS-4 (2)", - "title": "Personnel Termination | Automated Notification", - "summary": "The organization employs automated mechanisms to notify **access control personnel responsible for disabling access to the system** upon termination of an individual." - }, - { - "ref": "PS-5", - "title": "Personnel Transfer", - "summary": "The organization:\n a. Reviews and confirms ongoing operational need for current logical and physical access authorizations to information systems/facilities when individuals are reassigned or transferred to other positions within the organization;\n b. Initiates **twenty-four (24) hours** within [Assignment: organization-defined time period following the formal transfer action];\n c. Modifies access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and\n d. Notifies **twenty-four (24) hours** within [Assignment: organization-defined time period]." - }, - { - "ref": "PS-6", - "title": "Access Agreements", - "summary": "The organization:\n a. Develops and documents access agreements for organizational information systems;\n b. Reviews and updates the access agreements **at least annually**; and\n c. Ensures that individuals requiring access to organizational information and information systems:\n 1. Sign appropriate access agreements prior to being granted access; and\n 2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or **at least annually and any time there is a change to the user's level of access**." - }, - { - "ref": "PS-7", - "title": "Third-Party Personnel Security", - "summary": "The organization:\n a. Establishes personnel security requirements including security roles and responsibilities for third-party providers;\n b. Requires third-party providers to comply with personnel security policies and procedures established by the organization;\n c. Documents personnel security requirements;\n d. Requires third-party providers to notify **terminations: immediately; transfers: within twenty-four (24) hours** of any personnel transfers or terminations of third-party personnel who possess organizational credentials and/or badges, or who have information system privileges within [Assignment: organization-defined time period]; and\n e. Monitors provider compliance." - }, - { - "ref": "PS-8", - "title": "Personnel Sanctions", - "summary": "The organization:\n a. Employs a formal sanctions process for individuals failing to comply with established information security policies and procedures; and\n b. Notifies **at a minimum, the ISSO and/or similar role within the organization** within [Assignment: organization-defined time period] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction." - } - ] - }, - { - "title": "RISK ASSESSMENT", - "controls": [ - { - "ref": "RA-1", - "title": "Risk Assessment Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the risk assessment policy and associated risk assessment controls; and\n b. Reviews and updates the current:\n 1. Risk assessment policy **at least annually**; and\n 2. Risk assessment procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "RA-2", - "title": "Security Categorization", - "summary": "The organization:\n a. Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Documents the security categorization results (including supporting rationale) in the security plan for the information system; and\n c. Ensures that the security categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative." - }, - { - "ref": "RA-3", - "title": "Risk Assessment", - "summary": "The organization:\n a. Conducts an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits;\n b. Documents risk assessment results in [Selection: security plan; risk assessment report; **security assessment report**];\n c. Reviews risk assessment results **at least annually or whenever a significant change occurs**;\n d. Disseminates risk assessment results to [Assignment: organization-defined personnel or roles]; and\n e. Updates the risk assessment **annually** or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system." - }, - { - "ref": "RA-5", - "title": "Vulnerability Scanning", - "summary": "The organization:\n a. Scans for vulnerabilities in the information system and hosted applications **monthly operating system/infrastructure; monthly web applications and databases** and when new vulnerabilities potentially affecting the system/applications are identified and reported;\n b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n 1. Enumerating platforms, software flaws, and improper configurations;\n 2. Formatting checklists and test procedures; and\n 3. Measuring vulnerability impact;\n c. Analyzes vulnerability scan reports and results from security control assessments;\n d. Remediates legitimate vulnerabilities **high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery**, in accordance with an organizational assessment of risk; and\n e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies)." - }, - { - "ref": "RA-5 (1)", - "title": "Vulnerability Scanning | Update Tool Capability", - "summary": "The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned." - }, - { - "ref": "RA-5 (2)", - "title": "Vulnerability Scanning | Update By Frequency / Prior To New Scan / When Identified", - "summary": "The organization updates the information system vulnerabilities scanned [Selection (one or more): **prior to a new scan**; prior to a new scan; when new vulnerabilities are identified and reported]." - }, - { - "ref": "RA-5 (3)", - "title": "Vulnerability Scanning | Breadth / Depth of Coverage", - "summary": "The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked)." - }, - { - "ref": "RA-5 (4)", - "title": "Vulnerability Scanning | Discoverable Information", - "summary": "The organization determines what information about the information system is discoverable by adversaries and subsequently takes **notify appropriate service provider personnel and follow procedures for organization and service provider-defined corrective actions**." - }, - { - "ref": "RA-5 (5)", - "title": "Vulnerability Scanning | Privileged Access", - "summary": "The information system implements privileged access authorization to **operating systems / web applications / databases** for selected **all scans**." - }, - { - "ref": "RA-5 (6)", - "title": "Vulnerability Scanning | Automated Trend Analyses", - "summary": "The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities." - }, - { - "ref": "RA-5 (8)", - "title": "Vulnerability Scanning | Review Historic Audit Logs", - "summary": "The organization reviews historic audit logs to determine if a vulnerability identified in the information system has been previously exploited." - }, - { - "ref": "RA-5 (10)", - "title": "Vulnerability Scanning | Correlate Scanning Information", - "summary": "The organization correlates the output from vulnerability scanning tools to determine the presence of multi-vulnerability/multi-hop attack vectors." - } - ] - }, - { - "title": "SYSTEM AND SERVICES ACQUISITION", - "controls": [ - { - "ref": "SA-1", - "title": "System and Services Acquisition Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and services acquisition policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls; and\n b. Reviews and updates the current:\n 1. System and services acquisition policy **at least annually**; and\n 2. System and services acquisition procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "SA-2", - "title": "Allocation of Resources", - "summary": "The organization:\n a. Determines information security requirements for the information system or information system service in mission/business process planning;\n b. Determines, documents, and allocates the resources required to protect the information system or information system service as part of its capital planning and investment control process; and\n c. Establishes a discrete line item for information security in organizational programming and budgeting documentation." - }, - { - "ref": "SA-3", - "title": "System Development Life Cycle", - "summary": "The organization:\n a. Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;\n b. Defines and documents information security roles and responsibilities throughout the system development life cycle;\n c. Identifies individuals having information security roles and responsibilities; and\n d. Integrates the organizational information security risk management process into system development life cycle activities." - }, - { - "ref": "SA-4", - "title": "Acquisition Process", - "summary": "The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs:\n a. Security functional requirements;\n b. Security strength requirements;\n c. Security assurance requirements;\n d. Security-related documentation requirements;\n e. Requirements for protecting security-related documentation;\n f. Description of the information system development environment and environment in which the system is intended to operate; and\n g. Acceptance criteria." - }, - { - "ref": "SA-4 (1)", - "title": "Acquisition Process | Functional Properties of Security Controls", - "summary": "The organization requires the developer of the information system, system component, or information system service to provide a description of the functional properties of the security controls to be employed." - }, - { - "ref": "SA-4 (2)", - "title": "Acquisition Process | Design / Implementation Information for Security Controls", - "summary": "The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; **organization-defined design/implementation information]**] at [Assignment: organization-defined level of detail]." - }, - { - "ref": "SA-4 (8)", - "title": "Acquisition Process | Continuous Monitoring Plan", - "summary": "The organization requires the developer of the information system, system component, or information system service to produce a plan for the continuous monitoring of security control effectiveness that contains **at least the minimum requirement as defined in control CA-7**." - }, - { - "ref": "SA-4 (9)", - "title": "Acquisition Process | Functions / Ports / Protocols / Services in Use", - "summary": "The organization requires the developer of the information system, system component, or information system service to identify early in the system development life cycle, the functions, ports, protocols, and services intended for organizational use." - }, - { - "ref": "SA-4 (10)", - "title": "Acquisition Process | Use of Approved Piv Products", - "summary": "The organization employs only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems." - }, - { - "ref": "SA-5", - "title": "Information System Documentation", - "summary": "The organization:\n a. Obtains administrator documentation for the information system, system component, or information system service that describes:\n 1. Secure configuration, installation, and operation of the system, component, or service;\n 2. Effective use and maintenance of security functions/mechanisms; and\n 3. Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions;\n b. Obtains user documentation for the information system, system component, or information system service that describes:\n 1. User-accessible security functions/mechanisms and how to effectively use those security functions/mechanisms;\n 2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner; and\n 3. User responsibilities in maintaining the security of the system, component, or service;\n c. Documents attempts to obtain information system, system component, or information system service documentation when such documentation is either unavailable or nonexistent and [Assignment: organization-defined actions] in response;\n d. Protects documentation as required, in accordance with the risk management strategy; and e. Distributes documentation to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SA-8", - "title": "Security Engineering Principles", - "summary": "The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system." - }, - { - "ref": "SA-9", - "title": "External Information System Services", - "summary": "The organization:\n a. Requires that providers of external information system services comply with organizational information security requirements and employ **FedRAMP Security Controls Baseline(s) if Federal information is processed or stored within the external system** in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and\n c. Employs **Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored** to monitor security control compliance by external service providers on an ongoing basis." - }, - { - "ref": "SA-9 (1)", - "title": "External Information Systems | Risk Assessments / Organizational Approvals", - "summary": "The organization:\n (a) Conducts an organizational assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and\n (b) Ensures that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SA-9 (2)", - "title": "External Information Systems | Identification of Functions / Ports / Protocols / Services", - "summary": "The organization requires providers of **all external systems where Federal information is processed or stored** to identify the functions, ports, protocols, and other services required for the use of such services." - }, - { - "ref": "SA-9 (4)", - "title": "External Information Systems | Consistent Interests of Consumers and Providers", - "summary": "The organization employs **all external systems where Federal information is processed or stored** to ensure that the interests of [Assignment: organization-defined external service providers] are consistent with and reflect organizational interests." - }, - { - "ref": "SA-9 (5)", - "title": "External Information Systems | Processing, Storage, and Service Location", - "summary": "The organization restricts the location of [Selection (one or more): information processing; information/data; information system services] to **information processing, information data, AND information services** based on [Assignment: organization-defined requirements or conditions]." - }, - { - "ref": "SA-10", - "title": "Developer Configuration Management", - "summary": "The organization requires the developer of the information system, system component, or information system service to:\n a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation];\n b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management];\n c. Implement only organization-approved changes to the system, component, or service;\n d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and\n e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel]." - }, - { - "ref": "SA-10 (1)", - "title": "Developer Configuration Management | Software / Firmware Integrity Verification", - "summary": "The organization requires the developer of the information system, system component, or information system service to enable integrity verification of software and firmware components." - }, - { - "ref": "SA-11", - "title": "Developer Security Testing and Evaluation", - "summary": "The organization requires the developer of the information system, system component, or information system service to:\n a. Create and implement a security assessment plan;\n b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage];\n c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation;\n d. Implement a verifiable flaw remediation process; and\n e. Correct flaws identified during security testing/evaluation." - }, - { - "ref": "SA-11 (1)", - "title": "Developer Security Testing and Evaluation | Static Code Analysis", - "summary": "The organization requires the developer of the information system, system component, or information system service to employ static code analysis tools to identify common flaws and document the results of the analysis." - }, - { - "ref": "SA-11 (2)", - "title": "Developer Security Testing and Evaluation | Threat and Vulnerability Analyses", - "summary": "The organization requires the developer of the information system, system component, or information system service to perform threat and vulnerability analyses and subsequent testing/evaluation of the as-built system, component, or service." - }, - { - "ref": "SA-11 (8)", - "title": "Developer Security Testing and Evaluation | Dynamic Code Analysis", - "summary": "The organization requires the developer of the information system, system component, or information system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis." - }, - { - "ref": "SA-12", - "title": "Supply Chain Protection", - "summary": "The organization protects against supply chain threats to the information system, system component, or information system service by employing **organization and service provider-defined personnel security requirements, approved HW/SW vendor list/process, and secure SDLC procedures** as part of a comprehensive, defense-in-breadth information security strategy." - }, - { - "ref": "SA-15", - "title": "Development Process, Standards, and Tools", - "summary": "The organization:\n a. Requires the developer of the information system, system component, or information system service to follow a documented development process that:\n 1. Explicitly addresses security requirements;\n 2. Identifies the standards and tools used in the development process;\n 3. Documents the specific tool options and tool configurations used in the development process; and\n 4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and\n b. Reviews the development process, standards, tools, and tool options/configurations **as needed and as dictated by the current threat posture** to determine if the process, standards, tools, and tool options/configurations selected and employed can satisfy **organization and service provider- defined security requirements**." - }, - { - "ref": "SA-16", - "title": "Developer-Provided Training", - "summary": "The organization requires the developer of the information system, system component, or information system service to provide [Assignment: organization-defined training] on the correct use and operation of the implemented security functions, controls, and/or mechanisms." - }, - { - "ref": "SA-17", - "title": "Developer Security Architecture and Design", - "summary": "The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:\n a. Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture;\n b. Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and\n c. Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection." - } - ] - }, - { - "title": "SYSTEM AND COMMUNICATIONS PROTECTION", - "controls": [ - { - "ref": "SC-1", - "title": "System and Communications Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and communications protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and communications protection policy and associated system and communications protection controls; and\n b. Reviews and updates the current:\n 1. System and communications protection policy **at least annually**; and\n 2. System and communications protection procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "SC-2", - "title": "Application Partitioning", - "summary": "The information system separates user functionality (including user interface services) from information system management functionality." - }, - { - "ref": "SC-3", - "title": "Security Function Isolation", - "summary": "The information system isolates security functions from nonsecurity functions." - }, - { - "ref": "SC-4", - "title": "Information in Shared Resources", - "summary": "The information system prevents unauthorized and unintended information transfer via shared system resources." - }, - { - "ref": "SC-5", - "title": "Denial of Service Protection", - "summary": "The information system protects against or limits the effects of the following types of denial of service attacks: [Assignment: organization-defined types of denial of service attacks or reference to source for such information] by employing [Assignment: organization-defined security safeguards]." - }, - { - "ref": "SC-6", - "title": "Resource Availability", - "summary": "The information system protects the availability of resources by allocating [Assignment: organization-defined resources] by [Selection (one or more); priority; quota; [Assignment: organization-defined security safeguards]]." - }, - { - "ref": "SC-7", - "title": "Boundary Protection", - "summary": "The information system:\n a. Monitors and controls communications at the external boundary of the system and at key internal boundaries within the system;\n b. Implements subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and\n c. Connects to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture." - }, - { - "ref": "SC-7 (3)", - "title": "Boundary Protection | Access Points", - "summary": "The organization limits the number of external network connections to the information system." - }, - { - "ref": "SC-7 (4)", - "title": "Boundary Protection | External Telecommunications Services", - "summary": "The organization:\n (a) Implements a managed interface for each external telecommunication service; \n (b) Establishes a traffic flow policy for each managed interface;\n (c) Protects the confidentiality and integrity of the information being transmitted across each interface;\n (d) Documents each exception to the traffic flow policy with a supporting mission/business need and duration of that need; and\n (e) Reviews exceptions to the traffic flow policy [Assignment: organization-defined frequency] and removes exceptions that are no longer supported by an explicit mission/business need." - }, - { - "ref": "SC-7 (5)", - "title": "Boundary Protection | Deny By Default / Allow By Exception", - "summary": "The information system at managed interfaces denies network communications traffic by default and allows network communications traffic by exception (i.e., deny all, permit by exception)." - }, - { - "ref": "SC-7 (7)", - "title": "Boundary Protection | Prevent Split Tunneling for Remote Devices", - "summary": "The information system, in conjunction with a remote device, prevents the device from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks." - }, - { - "ref": "SC-7 (8)", - "title": "Boundary Protection | Route Traffic To Authenticated Proxy Servers", - "summary": "The information system routes [Assignment: organization-defined internal communications traffic] to [Assignment: organization-defined external networks] through authenticated proxy servers at managed interfaces." - }, - { - "ref": "SC-7 (10)", - "title": "Boundary Protection | Prevent Unauthorized Exfiltration", - "summary": "The organization prevents the unauthorized exfiltration of information across managed interfaces." - }, - { - "ref": "SC-7 (12)", - "title": "Boundary Protection | Host-Based Protection", - "summary": "The organization implements **Host Intrusion Prevention System (HIPS), Host Intrusion Detection System (HIDS), or minimally a host-based firewall** at [Assignment: organization-defined information system components]." - }, - { - "ref": "SC-7 (13)", - "title": "Boundary Protection | Isolation of Security Tools / Mechanisms / Support Components", - "summary": "The organization isolates [Assignment: organization-defined information security tools, mechanisms, and support components] from other internal information system components by implementing physically separate subnetworks with managed interfaces to other components of the system." - }, - { - "ref": "SC-7 (18)", - "title": "Boundary Protection | Fail Secure", - "summary": "The information system fails securely in the event of an operational failure of a boundary protection device." - }, - { - "ref": "SC-7 (20)", - "title": "Boundary Protection | Dynamic Isolation / Segregation", - "summary": "The information system provides the capability to dynamically isolate/segregate [Assignment: organization-defined information system components] from other components of the system." - }, - { - "ref": "SC-7 (21)", - "title": "Boundary Protection | Isolation of Information System Components", - "summary": "The organization employs boundary protection mechanisms to separate [Assignment: organization-defined information system components] supporting [Assignment: organization- defined missions and/or business functions]." - }, - { - "ref": "SC-8", - "title": "Transmission Confidentiality and Integrity", - "summary": "The information system protects the [Selection (one or more): confidentiality; integrity] of transmitted information." - }, - { - "ref": "SC-8 (1)", - "title": "Transmission Confidentiality and Integrity | Cryptographic or Alternate Physical Protection", - "summary": "The information system implements cryptographic mechanisms to [Selection (one or more): prevent unauthorized disclosure of information; detect changes to information] during transmission unless otherwise protected by **prevent unauthorized disclosure of information AND detect changes to information**." - }, - { - "ref": "SC-10", - "title": "Network Disconnect", - "summary": "The information system terminates the network connection associated with a communications session at the end of the session or after **no longer than ten (10) minutes for privileged sessions and no longer than fifteen (15) minutes for user sessions** of inactivity." - }, - { - "ref": "SC-12", - "title": "Cryptographic Key Establishment and Management", - "summary": "The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]." - }, - { - "ref": "SC-12 (1)", - "title": "Cryptographic Key Establishment and Management | Availability", - "summary": "The organization maintains availability of information in the event of the loss of cryptographic keys by users." - }, - { - "ref": "SC-12 (2)", - "title": "Cryptographic Key Establishment and Management | Symmetric Keys", - "summary": "The organization produces, controls, and distributes symmetric cryptographic keys using [Selection: NIST FIPS-compliant; NSA-approved] key management technology and processes." - }, - { - "ref": "SC-12 (3)", - "title": "Cryptographic Key Establishment and Management | Asymmetric Keys", - "summary": "The organization produces, controls, and distributes asymmetric cryptographic keys using [Selection: NSA-approved key management technology and processes; approved PKI Class 3 certificates or prepositioned keying material; approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user’s private key]." - }, - { - "ref": "SC-13", - "title": "Cryptographic Protection", - "summary": "The information system implements **FIPS-validated or NSA-approved cryptography** in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards." - }, - { - "ref": "SC-15", - "title": "Collaborative Computing Devices", - "summary": "The information system:\n a. Prohibits remote activation of collaborative computing devices with the following exceptions: **no exceptions**; and\n b. Provides an explicit indication of use to users physically present at the devices." - }, - { - "ref": "SC-17", - "title": "Public Key Infrastructure Certificates", - "summary": "The organization issues public key certificates under an [Assignment: organization- defined certificate policy] or obtains public key certificates from an approved service provider." - }, - { - "ref": "SC-18", - "title": "Mobile Code", - "summary": "The organization:\n a. Defines acceptable and unacceptable mobile code and mobile code technologies;\n b. Establishes usage restrictions and implementation guidance for acceptable mobile code and mobile code technologies; and\n c. Authorizes, monitors, and controls the use of mobile code within the information system." - }, - { - "ref": "SC-19", - "title": "Voice Over Internet Protocol", - "summary": "The organization:\n a. Establishes usage restrictions and implementation guidance for Voice over Internet Protocol (VoIP) technologies based on the potential to cause damage to the information system if used maliciously; and\n b. Authorizes, monitors, and controls the use of VoIP within the information system." - }, - { - "ref": "SC-20", - "title": "Secure Name /Address Resolution Service (Authoritative Source)", - "summary": "The information system:\n a. Provides additional data origin and integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and\n b. Provides the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace." - }, - { - "ref": "SC-21", - "title": "Secure Name /Address Resolution Service (Recursive or Caching Resolver)", - "summary": "The information system requests and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources." - }, - { - "ref": "SC-22", - "title": "Architecture and Provisioning for Name/Address Resolution Service", - "summary": "The information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation." - }, - { - "ref": "SC-23", - "title": "Session Authenticity", - "summary": "The information system protects the authenticity of communications sessions." - }, - { - "ref": "SC-23 (1)", - "title": "Session Authenticity | Invalidate Session Identifiers At Logout", - "summary": "The information system invalidates session identifiers upon user logout or other session termination." - }, - { - "ref": "SC-24", - "title": "Fail in Known State", - "summary": "The information system fails to a [Assignment: organization-defined known-state] for [Assignment: organization-defined types of failures] preserving [Assignment: organization-defined system state information] in failure." - }, - { - "ref": "SC-28", - "title": "Protection of Information At Rest", - "summary": "The information system protects the [Selection (one or more): confidentiality; integrity] of **confidentiality AND integrity**." - }, - { - "ref": "SC-28 (1)", - "title": "Protection of Information At Rest | Cryptographic Protection", - "summary": "The information system implements cryptographic mechanisms to prevent unauthorized disclosure and modification of **all information system components storing customer data deemed sensitive** on [Assignment: organization-defined information system components]." - }, - { - "ref": "SC-39", - "title": "Process Isolation", - "summary": "The information system maintains a separate execution domain for each executing process." - } - ] - }, - { - "title": "SYSTEM AND INFORMATION INTEGRITY", - "controls": [ - { - "ref": "SI-1", - "title": "System and Information Integrity Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and information integrity policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and information integrity policy and associated system and information integrity controls; and\n b. Reviews and updates the current:\n 1. System and information integrity policy **at least annually**; and\n 2. System and information integrity procedures **at least annually or whenever a significant change occurs**." - }, - { - "ref": "SI-2", - "title": "Flaw Remediation", - "summary": "The organization:\na. Identifies, reports, and corrects information system flaws;\nb. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;\nc. Installs security-relevant software and firmware updates within **thirty (30) days of release of updates** of the release of the updates; and\nd. Incorporates flaw remediation into the organizational configuration management process." - }, - { - "ref": "SI-2 (1)", - "title": "Flaw Remediation | Central Management", - "summary": "The organization centrally manages the flaw remediation process." - }, - { - "ref": "SI-2 (2)", - "title": "Flaw Remediation | Automated Flaw Remediation Status", - "summary": "The organization employs automated mechanisms **at least monthly** to determine the state of information system components with regard to flaw remediation." - }, - { - "ref": "SI-2 (3)", - "title": "Flaw Remediation | Time To Remediate Flaws / Benchmarks for Corrective Actions", - "summary": "The organization:\n (a) Measures the time between flaw identification and flaw remediation; and\n (b) Establishes [Assignment: organization-defined benchmarks] for taking corrective actions." - }, - { - "ref": "SI-3", - "title": "Malicious Code Protection", - "summary": "The organization:\n a. Employs malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code;\n b. Updates malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures;\n c. Configures malicious code protection mechanisms to:\n 1. Perform periodic scans of the information system **at least weekly** and real-time scans of files from external sources at [Selection (one or more); endpoint; network entry/exit points] as the files are downloaded, opened, or executed in accordance with organizational security policy; and\n 2. [Selection (one or more): block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined action, **to include blocking and quarantining malicious code and alerting administrator or defined security personnel near-realtime**]] in response to malicious code detection; and\n d. Addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system." - }, - { - "ref": "SI-3 (1)", - "title": "Malicious Code Protection | Central Management", - "summary": "The organization centrally manages malicious code protection mechanisms." - }, - { - "ref": "SI-3 (2)", - "title": "Malicious Code Protection | Automatic Updates", - "summary": "The information system automatically updates malicious code protection mechanisms." - }, - { - "ref": "SI-3 (7)", - "title": "Malicious Code Protection | Nonsignature-Based Detection", - "summary": "The information system implements nonsignature-based malicious code detection mechanisms." - }, - { - "ref": "SI-4", - "title": "Information System Monitoring", - "summary": "The organization:\n a. Monitors the information system to detect:\n 1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and\n 2. Unauthorized local, network, and remote connections;\n b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods];\n c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;\n d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;\n e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;\n f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and\n g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]]." - }, - { - "ref": "SI-4 (1)", - "title": "Information System Monitoring | System-Wide Intrusion Detection System", - "summary": "The organization connects and configures individual intrusion detection tools into an information system-wide intrusion detection system." - }, - { - "ref": "SI-4 (2)", - "title": "Information System Monitoring | Automated Tools for Real-Time Analysis", - "summary": "The organization employs automated tools to support near real-time analysis of events." - }, - { - "ref": "SI-4 (4)", - "title": "Information System Monitoring | Inbound and Outbound Communications Traffic", - "summary": "The information system monitors inbound and outbound communications traffic **continuously** for unusual or unauthorized activities or conditions." - }, - { - "ref": "SI-4 (5)", - "title": "Information System Monitoring | System-Generated Alerts", - "summary": "The information system alerts [Assignment: organization-defined personnel or roles] when the following indications of compromise or potential compromise occur: [Assignment: organization- defined compromise indicators]." - }, - { - "ref": "SI-4 (11)", - "title": "Information System Monitoring | Analyze Communications Traffic Anomalies", - "summary": "The organization analyzes outbound communications traffic at the external boundary of the information system and selected [Assignment: organization-defined interior points within the system (e.g., subnetworks, subsystems)] to discover anomalies." - }, - { - "ref": "SI-4 (14)", - "title": "Information System Monitoring | Wireless Intrusion Detection", - "summary": "The organization employs a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises/breaches to the information system." - }, - { - "ref": "SI-4 (16)", - "title": "Information System Monitoring | Correlate Monitoring Information", - "summary": "The organization correlates information from monitoring tools employed throughout the information system." - }, - { - "ref": "SI-4 (18)", - "title": "Information System Monitoring | Analyze Traffic / Covert Exfiltration", - "summary": "The organization analyzes outbound communications traffic at the external boundary of the information system (i.e., system perimeter) and at [Assignment: organization-defined interior points within the system (e.g., subsystems, subnetworks)] to detect covert exfiltration of information." - }, - { - "ref": "SI-4 (19)", - "title": "Information System Monitoring | Individuals Posing Greater Risk", - "summary": "The organization implements [Assignment: organization-defined additional monitoring] of individuals who have been identified by [Assignment: organization-defined sources] as posing an increased level of risk." - }, - { - "ref": "SI-4 (20)", - "title": "Information System Monitoring | Privileged User", - "summary": "The organization implements [Assignment: organization-defined additional monitoring] of privileged users." - }, - { - "ref": "SI-4 (22)", - "title": "Information System Monitoring | Unauthorized Network Services", - "summary": "The information system detects network services that have not been authorized or approved by [Assignment: organization-defined authorization or approval processes] and [Selection (one or more): audits; alerts [Assignment: organization-defined personnel or roles]]." - }, - { - "ref": "SI-4 (23)", - "title": "Information System Monitoring | Host-Based Devices", - "summary": "The organization implements [Assignment: organization-defined host-based monitoring mechanisms] at [Assignment: organization-defined information system components]." - }, - { - "ref": "SI-4 (24)", - "title": "Information System Monitoring | Indicators of Compromise", - "summary": "The information system discovers, collects, distributes, and uses indicators of compromise." - }, - { - "ref": "SI-5", - "title": "Security Alerts, Advisories, and Directives", - "summary": "The organization:\n a. Receives information system security alerts, advisories, and directives from [Assignment: organization-defined external organizations, **to include US-CERT**] on an ongoing basis;\n b. Generates internal security alerts, advisories, and directives as deemed necessary;\n c. Disseminates security alerts, advisories, and directives to: [Selection (one or more): [Assignment: organization-defined personnel or roles, **to include system security personnel and administrators with configuration/patch-management responsibilities**]; [Assignment: organization-defined elements within the organization]; [Assignment: organization-defined external organizations]]; and\n d. Implements security directives in accordance with established time frames, or notifies the issuing organization of the degree of noncompliance." - }, - { - "ref": "SI-5 (1)", - "title": "Security Alerts, Advisories, and Directives | Automated Alerts and Advisories", - "summary": "The organization employs automated mechanisms to make security alert and advisory information available throughout the organization." - }, - { - "ref": "SI-6", - "title": "Security Function Verification", - "summary": "The information system:\n a. Verifies the correct operation of [Assignment: organization-defined security functions];\n b. Performs this verification [Selection (one or more): [Assignment: organization-defined system transitional states, **to include upon system startup and/or restart and at least monthly**]; upon command by user with appropriate privilege; [Assignment: organization-defined frequency]];\n c. Notifies [Assignment: organization-defined personnel or roles, **to include system administrators and security personnel**] of failed security verification tests; and\n d. [Selection (one or more): shuts the information system down; restarts the information system; [Assignment: organization-defined alternative action(s), **to include notification of system administrators and security personnel**]] when anomalies are discovered." - }, - { - "ref": "SI-7", - "title": "Software, Firmware, and Information Integrity", - "summary": "The organization employs integrity verification tools to detect unauthorized changes to [Assignment: organization-defined software, firmware, and information]." - }, - { - "ref": "SI-7 (1)", - "title": "Software, Firmware, and Information Integrity | Integrity Checks", - "summary": "The information system performs an integrity check of [Assignment: organization-defined software, firmware, and information] [Selection (one or more): at startup; at [Assignment: organization-defined transitional states or security-relevant events, **selection to include security relevant events**]; **at least monthly**]." - }, - { - "ref": "SI-7 (2)", - "title": "Software, Firmware, and Information Integrity | Automated Notifications of Integrity Violations", - "summary": "The organization employs automated tools that provide notification to [Assignment: organization- defined personnel or roles] upon discovering discrepancies during integrity verification." - }, - { - "ref": "SI-7 (5)", - "title": "Software, Firmware, and Information Integrity | Automated Response To Integrity Violations", - "summary": "The information system automatically [Selection (one or more): shuts the information system down; restarts the information system; implements [Assignment: organization-defined security safeguards]] when integrity violations are discovered." - }, - { - "ref": "SI-7 (7)", - "title": "Software, Firmware, and Information Integrity | Integration of Detection and Response", - "summary": "The organization incorporates the detection of unauthorized [Assignment: organization-defined security-relevant changes to the information system] into the organizational incident response capability." - }, - { - "ref": "SI-7 (14)", - "title": "Software, Firmware, and Information Integrity | Binary or Machine Executable Code", - "summary": "The organization:\n (a) Prohibits the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code; and\n (b) Provides exceptions to the source code requirement only for compelling mission/operational requirements and with the approval of the authorizing official." - }, - { - "ref": "SI-8", - "title": "Spam Protection", - "summary": "The organization:\n a. Employs spam protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages; and\n b. Updates spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures." - }, - { - "ref": "SI-8 (1)", - "title": "Spam Protection | Central Management", - "summary": "The organization centrally manages spam protection mechanisms." - }, - { - "ref": "SI-8 (2)", - "title": "Spam Protection | Automatic Updates", - "summary": "The information system automatically updates spam protection mechanisms." - }, - { - "ref": "SI-10", - "title": "Information Input Validation", - "summary": "The information system checks the validity of [Assignment: organization-defined information inputs]." - }, - { - "ref": "SI-11", - "title": "Error Handling", - "summary": "The information system:\n a. Generates error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries; and\n b. Reveals error messages only to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SI-12", - "title": "Information Handling and Retention", - "summary": "The organization handles and retains information within the information system and information output from the system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and operational requirements." - }, - { - "ref": "SI-16", - "title": "Memory Protection", - "summary": "The information system implements [Assignment: organization-defined security safeguards] to protect its memory from unauthorized code execution." + "standard": "FedRAMP Rev 5 High Baseline", + "version": "Rev 5", + "basedOn": "fedramp-2.0.0-oscal1.0.4", + "webLink": "https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/baselines/json/FedRAMP_rev5_HIGH-baseline-resolved-profile_catalog.json", + "domains": [ + { + "title": "Access Control", + "controls": [ + { + "ref": "AC-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} access control policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the access control policy and the associated access controls;\nb. Designate an {{ official - an official to manage the access control policy and procedures is defined; }} to manage the development, documentation, and dissemination of the access control policy and procedures; and\nc. Review and update the current access control:\n1. Policy at least annually and following {{ events - events that would require the current access control policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AC-2", + "title": "Account Management", + "summary": "Account Management\na. Define and document the types of accounts allowed and specifically prohibited for use within the system;\nb. Assign account managers;\nc. Require {{ prerequisites and criteria - prerequisites and criteria for group and role membership are defined; }} for group and role membership;\nd. Specify:\n1. Authorized users of the system;\n2. Group and role membership; and\n3. Access authorizations (i.e., privileges) and {{ attributes (as required) - attributes (as required) for each account are defined; }} for each account;\ne. Require approvals by {{ personnel or roles - personnel or roles required to approve requests to create accounts is/are defined; }} for requests to create accounts;\nf. Create, enable, modify, disable, and remove accounts in accordance with {{ policy, procedures, prerequisites, and criteria - policy, procedures, prerequisites, and criteria for account creation, enabling, modification, disabling, and removal are defined; }};\ng. Monitor the use of accounts;\nh. Notify account managers and {{ personnel or roles - personnel or roles to be notified is/are defined; }} within:\n1. twenty-four (24) hours when accounts are no longer required;\n2. eight (8) hours when users are terminated or transferred; and\n3. eight (8) hours when system usage or need-to-know changes for an individual;\ni. Authorize access to the system based on:\n1. A valid access authorization;\n2. Intended system usage; and\n3. {{ attributes (as required) - attributes needed to authorize system access (as required) are defined; }};\nj. Review accounts for compliance with account management requirements monthly for privileged accessed, every six (6) months for non-privileged access;\nk. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and\nl. Align account management processes with personnel termination and transfer processes.\ncontrols AC-2(1) Automated System Account Management\nSupport the management of system accounts using {{ automated mechanisms - automated mechanisms used to support the management of system accounts are defined; }}.\nAC-2(2) Automated Temporary and Emergency Account Management\nAutomatically disables temporary and emergency accounts after no more than 24 hours from last use.\nAC-2(3) Disable Accounts\nDisable accounts within 24 hours for user accounts when the accounts:\n(a) Have expired;\n(b) Are no longer associated with a user or individual;\n(c) Are in violation of organizational policy; or\n(d) Have been inactive for thirty-five (35) days (See additional requirements and guidance.).\nAC-2 (3) Additional FedRAMP Requirements and Guidance Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices). The time periods are approved and accepted by the JAB/AO. Where user management is a function of the service, reports of activity of consumer users shall be made available.\n(d) Requirement: The service provider defines the time period of inactivity for device identifiers.\nAC-2(4) Automated Audit Actions\nAutomatically audit account creation, modification, enabling, disabling, and removal actions.\nAC-2(5) Inactivity Logout\nRequire that users log out when inactivity is anticipated to exceed Fifteen (15) minutes.\nAC-2 (5) Additional FedRAMP Requirements and Guidance \nAC-2(7) Privileged User Accounts\n(a) Establish and administer privileged user accounts in accordance with {{ a role-based access scheme OR an attribute-based access scheme }};\n(b) Monitor privileged role or attribute assignments;\n(c) Monitor changes to roles or attributes; and\n(d) Revoke access when privileged role or attribute assignments are no longer appropriate.\nAC-2(9) Restrictions on Use of Shared and Group Accounts\nOnly permit the use of shared and group accounts that meet organization-defined need with justification statement that explains why such accounts are necessary.\nAC-2 (9) Additional FedRAMP Requirements and Guidance Requirement: Required if shared/group accounts are deployed.\nAC-2(11) Usage Conditions\nEnforce {{ circumstances and/or usage conditions - circumstances and/or usage conditions to be enforced for system accounts are defined; }} for {{ system accounts - system accounts subject to enforcement of circumstances and/or usage conditions are defined; }}.\nAC-2(12) Account Monitoring for Atypical Usage\n(a) Monitor system accounts for {{ atypical usage - atypical usage for which to monitor system accounts is defined; }} ; and\n(b) Report atypical usage of system accounts to at a minimum, the ISSO and/or similar role within the organization.\nAC-2 (12) Additional FedRAMP Requirements and Guidance (a) Requirement: Required for privileged accounts.\n(b) Requirement: Required for privileged accounts.\nAC-2(13) Disable Accounts for High-risk Individuals\nDisable accounts of individuals within one (1) hour of discovery of {{ significant risks - significant risks leading to disabling accounts are defined; }}.", + "guidance": "Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.\n\nWhere access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.\n\nTemporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training." + }, + { + "ref": "AC-3", + "title": "Access Enforcement", + "summary": "Access Enforcement\nEnforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.", + "guidance": "Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection ( [PE] ) family." + }, + { + "ref": "AC-4", + "title": "Information Flow Enforcement", + "summary": "Information Flow Enforcement\nEnforce approved authorizations for controlling the flow of information within the system and between connected systems based on {{ information flow control policies - information flow control policies within the system and between connected systems are defined; }}.\ncontrols AC-4(4) Flow Control of Encrypted Information\nPrevent encrypted information from bypassing intrusion detection mechanisms by {{ one or more: decrypting the information, blocking the flow of the encrypted information, terminating communications sessions attempting to pass encrypted information, {{ organization-defined procedure or method - the organization-defined procedure or method used to prevent encrypted information from bypassing information flow control mechanisms is defined (if selected); }} }}.\nAC-4 (4) Additional FedRAMP Requirements and Guidance Requirement: The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf) and M-22-09 (https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf).\nAC-4(21) Physical or Logical Separation of Information Flows\nSeparate information flows logically or physically using {{ organization-defined mechanisms and/or techniques }} to accomplish {{ required separations - required separations by types of information are defined; }}.", + "guidance": "Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see [CA-3] ). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security or privacy attributes and labels.\n\nOrganizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS)." + }, + { + "ref": "AC-5", + "title": "Separation of Duties", + "summary": "Separation of Duties\na. Identify and document {{ duties of individuals - duties of individuals requiring separation are defined; }} ; and\nb. Define system access authorizations to support separation of duties.\nAC-5 Additional FedRAMP Requirements and Guidance ", + "guidance": "Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in [AC-2] , access control mechanisms in [AC-3] , and identity management activities in [IA-2], [IA-4] , and [IA-12]." + }, + { + "ref": "AC-6", + "title": "Least Privilege", + "summary": "Least Privilege\nEmploy the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.\ncontrols AC-6(1) Authorize Access to Security Functions\nAuthorize access for {{ individuals and roles - individuals and roles with authorized access to security functions and security-relevant information are defined; }} to:\n(a) all functions not publicly accessible ; and\n(b) all security-relevant information not publicly available.\nAC-6(2) Non-privileged Access for Nonsecurity Functions\nRequire that users of system accounts (or roles) with access to all security functions use non-privileged accounts or roles, when accessing nonsecurity functions.\nAC-6 (2) Additional FedRAMP Requirements and Guidance \nAC-6(3) Network Access to Privileged Commands\nAuthorize network access to all privileged commands only for {{ compelling operational needs - compelling operational needs necessitating network access to privileged commands are defined; }} and document the rationale for such access in the security plan for the system.\nAC-6(5) Privileged Accounts\nRestrict privileged accounts on the system to {{ personnel or roles - personnel or roles to which privileged accounts on the system are to be restricted is/are defined; }}.\nAC-6(7) Review of User Privileges\n(a) Review at a minimum, annually the privileges assigned to all users with privileges to validate the need for such privileges; and\n(b) Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.\nAC-6(8) Privilege Levels for Code Execution\nPrevent the following software from executing at higher privilege levels than users executing the software: any software except software explicitly documented.\nAC-6(9) Log Use of Privileged Functions\nLog the execution of privileged functions.\nAC-6(10) Prohibit Non-privileged Users from Executing Privileged Functions\nPrevent non-privileged users from executing privileged functions.", + "guidance": "Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems." + }, + { + "ref": "AC-7", + "title": "Unsuccessful Logon Attempts", + "summary": "Unsuccessful Logon Attempts\na. Enforce a limit of {{ number - the number of consecutive invalid logon attempts by a user allowed during a time period is defined; }} consecutive invalid logon attempts by a user during a {{ time period - the time period to which the number of consecutive invalid logon attempts by a user is limited is defined; }} ; and\nb. Automatically {{ one or more: lock the account or node for {{ time period - time period for an account or node to be locked is defined (if selected); }} , lock the account or node until released by an administrator, delay next logon prompt per {{ delay algorithm - delay algorithm for the next logon prompt is defined (if selected); }} , notify system administrator, take other {{ action - other action to be taken when the maximum number of unsuccessful attempts is exceeded is defined (if selected); }} }} when the maximum number of unsuccessful attempts is exceeded.\nAC-7 Additional FedRAMP Requirements and Guidance Requirement: In alignment with NIST SP 800-63B.", + "guidance": "The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need." + }, + { + "ref": "AC-8", + "title": "System Use Notification", + "summary": "System Use Notification\na. Display see additional Requirements and Guidance to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:\n1. Users are accessing a U.S. Government system;\n2. System usage may be monitored, recorded, and subject to audit;\n3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and\n4. Use of the system indicates consent to monitoring and recording;\nb. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and\nc. For publicly accessible systems:\n1. Display system use information see additional Requirements and Guidance , before granting further access to the publicly accessible system;\n2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and\n3. Include a description of the authorized uses of the system.\nAC-8 Additional FedRAMP Requirements and Guidance Requirement: If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO.", + "guidance": "System use notifications can be implemented using messages or warning banners displayed before individuals log in to systems. System use notifications are used only for access via logon interfaces with human users. Notifications are not required when human interfaces do not exist. Based on an assessment of risk, organizations consider whether or not a secondary system use notification is needed to access applications or other system resources after the initial network logon. Organizations consider system use notification messages or banners displayed in multiple languages based on organizational needs and the demographics of system users. Organizations consult with the privacy office for input regarding privacy messaging and the Office of the General Counsel or organizational equivalent for legal review and approval of warning banner content." + }, + { + "ref": "AC-10", + "title": "Concurrent Session Control", + "summary": "Concurrent Session Control\nLimit the number of concurrent sessions for each {{ account and/or account types - accounts and/or account types for which to limit the number of concurrent sessions is defined; }} to three (3) sessions for privileged access and two (2) sessions for non-privileged access.", + "guidance": "Organizations may define the maximum number of concurrent sessions for system accounts globally, by account type, by account, or any combination thereof. For example, organizations may limit the number of concurrent sessions for system administrators or other individuals working in particularly sensitive domains or mission-critical applications. Concurrent session control addresses concurrent sessions for system accounts. It does not, however, address concurrent sessions by single users via multiple system accounts." + }, + { + "ref": "AC-11", + "title": "Device Lock", + "summary": "Device Lock\na. Prevent further access to the system by {{ one or more: initiating a device lock after fifteen (15) minutes of inactivity, requiring the user to initiate a device lock before leaving the system unattended }} ; and\nb. Retain the device lock until the user reestablishes access using established identification and authentication procedures.\ncontrols AC-11(1) Pattern-hiding Displays\nConceal, via the device lock, information previously visible on the display with a publicly viewable image.", + "guidance": "Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks can be implemented at the operating system level or at the application level. A proximity lock may be used to initiate the device lock (e.g., via a Bluetooth-enabled device or dongle). User-initiated device locking is behavior or policy-based and, as such, requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of systems, such as when organizations require users to log out at the end of workdays." + }, + { + "ref": "AC-12", + "title": "Session Termination", + "summary": "Session Termination\nAutomatically terminate a user session after {{ conditions or trigger events - conditions or trigger events requiring session disconnect are defined; }}.", + "guidance": "Session termination addresses the termination of user-initiated logical sessions (in contrast to [SC-10] , which addresses the termination of network connections associated with communications sessions (i.e., network disconnect)). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational system. Such user sessions can be terminated without terminating network sessions. Session termination ends all processes associated with a user\u2019s logical session except for those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events that require automatic termination of the session include organization-defined periods of user inactivity, targeted responses to certain types of incidents, or time-of-day restrictions on system use." + }, + { + "ref": "AC-14", + "title": "Permitted Actions Without Identification or Authentication", + "summary": "Permitted Actions Without Identification or Authentication\na. Identify {{ user actions - user actions that can be performed on the system without identification or authentication are defined; }} that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and\nb. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.", + "guidance": "Specific user actions may be permitted without identification or authentication if organizations determine that identification and authentication are not required for the specified user actions. Organizations may allow a limited number of user actions without identification or authentication, including when individuals access public websites or other publicly accessible federal systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations identify actions that normally require identification or authentication but may, under certain circumstances, allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. Permitting actions without identification or authentication does not apply to situations where identification and authentication have already occurred and are not repeated but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational systems without identification and authentication, and therefore, the value for the assignment operation can be \"none.\" " + }, + { + "ref": "AC-17", + "title": "Remote Access", + "summary": "Remote Access\na. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\nb. Authorize each type of remote access to the system prior to allowing such connections.\ncontrols AC-17(1) Monitoring and Control\nEmploy automated mechanisms to monitor and control remote access methods.\nAC-17(2) Protection of Confidentiality and Integrity Using Encryption\nImplement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.\nAC-17(3) Managed Access Control Points\nRoute remote accesses through authorized and managed network access control points.\nAC-17(4) Privileged Commands and Access\n(a) Authorize the execution of privileged commands and access to security-relevant information via remote access only in a format that provides assessable evidence and for the following needs: {{ organization-defined needs }} ; and\n(b) Document the rationale for remote access in the security plan for the system.", + "guidance": "Remote access is access to organizational systems (or processes acting on behalf of users) that communicate through external networks such as the Internet. Types of remote access include dial-up, broadband, and wireless. Organizations use encrypted virtual private networks (VPNs) to enhance confidentiality and integrity for remote connections. The use of encrypted VPNs provides sufficient assurance to the organization that it can effectively treat such connections as internal networks if the cryptographic mechanisms used are implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. VPNs with encrypted tunnels can also affect the ability to adequately monitor network communications traffic for malicious code. Remote access controls apply to systems other than public web servers or systems designed for public access. Authorization of each remote access type addresses authorization prior to allowing remote access without specifying the specific formats for such authorization. While organizations may use information exchange and system connection security agreements to manage remote access connections to other systems, such agreements are addressed as part of [CA-3] . Enforcing access restrictions for remote access is addressed via [AC-3]." + }, + { + "ref": "AC-18", + "title": "Wireless Access", + "summary": "Wireless Access\na. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and\nb. Authorize each type of wireless access to the system prior to allowing such connections.\ncontrols AC-18(1) Authentication and Encryption\nProtect wireless access to the system using authentication of {{ one or more: users, devices }} and encryption.\nAC-18(3) Disable Wireless Networking\nDisable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.\nAC-18(4) Restrict Configurations by Users\nIdentify and explicitly authorize users allowed to independently configure wireless networking capabilities.\nAC-18(5) Antennas and Transmission Power Levels\nSelect radio antennas and calibrate transmission power levels to reduce the probability that signals from wireless access points can be received outside of organization-controlled boundaries.", + "guidance": "Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. Wireless networks use authentication protocols that provide authenticator protection and mutual authentication." + }, + { + "ref": "AC-19", + "title": "Access Control for Mobile Devices", + "summary": "Access Control for Mobile Devices\na. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and\nb. Authorize the connection of mobile devices to organizational systems.\ncontrols AC-19(5) Full Device or Container-based Encryption\nEmploy {{ full-device encryption OR container-based encryption }} to protect the confidentiality and integrity of information on {{ mobile devices - mobile devices on which to employ encryption are defined; }}.", + "guidance": "A mobile device is a computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile device functionality may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of notebook/desktop systems, depending on the nature and intended purpose of the device. Protection and control of mobile devices is behavior or policy-based and requires users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which organizations provide physical or procedural controls to meet the requirements established for protecting information and systems.\n\nDue to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions and specific implementation guidance for mobile devices include configuration management, device identification and authentication, implementation of mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware.\n\nUsage restrictions and authorization to connect may vary among organizational systems. For example, the organization may authorize the connection of mobile devices to its network and impose a set of usage restrictions, while a system owner may withhold authorization for mobile device connection to specific applications or impose additional usage restrictions before allowing mobile device connections to a system. Adequate security for mobile devices goes beyond the requirements specified in [AC-19] . Many safeguards for mobile devices are reflected in other controls. [AC-20] addresses mobile devices that are not organization-controlled." + }, + { + "ref": "AC-20", + "title": "Use of External Systems", + "summary": "Use of External Systems\na. {{ one or more: establish {{ terms and conditions - terms and conditions consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems are defined (if selected); }} , identify {{ controls asserted - controls asserted to be implemented on external systems consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems are defined (if selected); }} }} , consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:\n1. Access the system from external systems; and\n2. Process, store, or transmit organization-controlled information using external systems; or\nb. Prohibit the use of {{ prohibited types of external systems - types of external systems prohibited from use are defined; }}.\nAC-20 Additional FedRAMP Requirements and Guidance \ncontrols AC-20(1) Limits on Authorized Use\nPermit authorized individuals to use an external system to access the system or to process, store, or transmit organization-controlled information only after:\n(a) Verification of the implementation of controls on the external system as specified in the organization\u2019s security and privacy policies and security and privacy plans; or\n(b) Retention of approved system connection or processing agreements with the organizational entity hosting the external system.\nAC-20(2) Portable Storage Devices \u2014 Restricted Use\nRestrict the use of organization-controlled portable storage devices by authorized individuals on external systems using {{ restrictions - restrictions on the use of organization-controlled portable storage devices by authorized individuals on external systems are defined; }}.", + "guidance": "External systems are systems that are used by but not part of organizational systems, and for which the organization has no direct control over the implementation of required controls or the assessment of control effectiveness. External systems include personally owned systems, components, or devices; privately owned computing and communications devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; systems managed by contractors; and federal information systems that are not owned by, operated by, or under the direct supervision or authority of the organization. External systems also include systems owned or operated by other components within the same organization and systems within the organization with different authorization boundaries. Organizations have the option to prohibit the use of any type of external system or prohibit the use of specified types of external systems, (e.g., prohibit the use of any external system that is not organizationally owned or prohibit the use of personally-owned systems).\n\nFor some external systems (i.e., systems operated by other organizations), the trust relationships that have been established between those organizations and the originating organization may be such that no explicit terms and conditions are required. Systems within these organizations may not be considered external. These situations occur when, for example, there are pre-existing information exchange agreements (either implicit or explicit) established between organizations or components or when such agreements are specified by applicable laws, executive orders, directives, regulations, policies, or standards. Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to organizational systems and over which organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals need not be uniform, as the restrictions may vary depending on trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments.\n\nExternal systems used to access public interfaces to organizational systems are outside the scope of [AC-20] . Organizations establish specific terms and conditions for the use of external systems in accordance with organizational security policies and procedures. At a minimum, terms and conditions address the specific types of applications that can be accessed on organizational systems from external systems and the highest security category of information that can be processed, stored, or transmitted on external systems. If the terms and conditions with the owners of the external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems." + }, + { + "ref": "AC-21", + "title": "Information Sharing", + "summary": "Information Sharing\na. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information\u2019s access and use restrictions for {{ information-sharing circumstances - information-sharing circumstances where user discretion is required to determine whether access authorizations assigned to a sharing partner match the information\u2019s access and use restrictions are defined; }} ; and\nb. Employ {{ automated mechanisms - automated mechanisms or manual processes that assist users in making information-sharing and collaboration decisions are defined; }} to assist users in making information sharing and collaboration decisions.", + "guidance": "Information sharing applies to information that may be restricted in some manner based on some formal or administrative determination. Examples of such information include, contract-sensitive information, classified information related to special access programs or compartments, privileged information, proprietary information, and personally identifiable information. Security and privacy risk assessments as well as applicable laws, regulations, and policies can provide useful inputs to these determinations. Depending on the circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program or compartment. Access restrictions may include non-disclosure agreements (NDA). Information flow techniques and security attributes may be used to provide automated assistance to users making sharing and collaboration decisions." + }, + { + "ref": "AC-22", + "title": "Publicly Accessible Content", + "summary": "Publicly Accessible Content\na. Designate individuals authorized to make information publicly accessible;\nb. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\nc. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and\nd. Review the content on the publicly accessible system for nonpublic information at least quarterly and remove such information, if discovered.", + "guidance": "In accordance with applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the public is not authorized to have access to nonpublic information, including information protected under the [PRIVACT] and proprietary information. Publicly accessible content addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Posting information on non-organizational systems (e.g., non-organizational public websites, forums, and social media) is covered by organizational policy. While organizations may have individuals who are responsible for developing and implementing policies about the information that can be made publicly accessible, publicly accessible content addresses the management of the individuals who make such information publicly accessible." + } + ] + }, + { + "title": "Awareness and Training", + "controls": [ + { + "ref": "AT-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} awareness and training policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the awareness and training policy and the associated awareness and training controls;\nb. Designate an {{ official - an official to manage the awareness and training policy and procedures is defined; }} to manage the development, documentation, and dissemination of the awareness and training policy and procedures; and\nc. Review and update the current awareness and training:\n1. Policy at least annually and following {{ events - events that would require the current awareness and training policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Awareness and training policy and procedures address the controls in the AT family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of awareness and training policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to awareness and training policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AT-2", + "title": "Literacy Training and Awareness", + "summary": "Literacy Training and Awareness\na. Provide security and privacy literacy training to system users (including managers, senior executives, and contractors):\n1. As part of initial training for new users and at least annually thereafter; and\n2. When required by system changes or following {{ organization-defined events }};\nb. Employ the following techniques to increase the security and privacy awareness of system users {{ awareness techniques - techniques to be employed to increase the security and privacy awareness of system users are defined; }};\nc. Update literacy training and awareness content at least annually and following {{ events - events that would require literacy training and awareness content to be updated are defined; }} ; and\nd. Incorporate lessons learned from internal or external security incidents or breaches into literacy training and awareness techniques.\ncontrols AT-2(2) Insider Threat\nProvide literacy training on recognizing and reporting potential indicators of insider threat.\nAT-2(3) Social Engineering and Mining\nProvide literacy training on recognizing and reporting potential and actual instances of social engineering and social mining.", + "guidance": "Organizations provide basic and advanced levels of literacy training to system users, including measures to test the knowledge level of users. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and privacy as well as actions by users to maintain security and personal privacy and to respond to suspected incidents. The content addresses the need for operations security and the handling of personally identifiable information.\n\nAwareness techniques include displaying posters, offering supplies inscribed with security and privacy reminders, displaying logon screen messages, generating email advisories or notices from organizational officials, and conducting awareness events. Literacy training after the initial training described in [AT-2a.1] is conducted at a minimum frequency consistent with applicable laws, directives, regulations, and policies. Subsequent literacy training may be satisfied by one or more short ad hoc sessions and include topical information on recent attack schemes, changes to organizational security and privacy policies, revised security and privacy expectations, or a subset of topics from the initial training. Updating literacy training and awareness content on a regular basis helps to ensure that the content remains relevant. Events that may precipitate an update to literacy training and awareness content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "AT-3", + "title": "Role-based Training", + "summary": "Role-based Training\na. Provide role-based security and privacy training to personnel with the following roles and responsibilities: {{ organization-defined roles and responsibilities }}:\n1. Before authorizing access to the system, information, or performing assigned duties, and at least annually thereafter; and\n2. When required by system changes;\nb. Update role-based training content at least annually and following {{ events - events that require role-based training content to be updated are defined; }} ; and\nc. Incorporate lessons learned from internal or external security incidents or breaches into role-based training.", + "guidance": "Organizations determine the content of training based on the assigned roles and responsibilities of individuals as well as the security and privacy requirements of organizations and the systems to which personnel have authorized access, including technical training specifically tailored for assigned duties. Roles that may require role-based training include senior leaders or management officials (e.g., head of agency/chief executive officer, chief information officer, senior accountable official for risk management, senior agency information security officer, senior agency official for privacy), system owners; authorizing officials; system security officers; privacy officers; acquisition and procurement officials; enterprise architects; systems engineers; software developers; systems security engineers; privacy engineers; system, network, and database administrators; auditors; personnel conducting configuration management activities; personnel performing verification and validation activities; personnel with access to system-level software; control assessors; personnel with contingency planning and incident response duties; personnel with privacy management responsibilities; and personnel with access to personally identifiable information.\n\nComprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls. Role-based training also includes policies, procedures, tools, methods, and artifacts for the security and privacy roles defined. Organizations provide the training necessary for individuals to fulfill their responsibilities related to operations and supply chain risk management within the context of organizational security and privacy programs. Role-based training also applies to contractors who provide services to federal agencies. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Updating role-based training on a regular basis helps to ensure that the content remains relevant and effective. Events that may precipitate an update to role-based training content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "AT-4", + "title": "Training Records", + "summary": "Training Records\na. Document and monitor information security and privacy training activities, including security and privacy awareness training and specific role-based security and privacy training; and\nb. Retain individual training records for five (5) years or 5 years after completion of a specific training program.", + "guidance": "Documentation for specialized training may be maintained by individual supervisors at the discretion of the organization. The National Archives and Records Administration provides guidance on records retention for federal agencies." + } + ] + }, + { + "title": "Audit and Accountability", + "controls": [ + { + "ref": "AU-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} audit and accountability policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the audit and accountability policy and the associated audit and accountability controls;\nb. Designate an {{ official - an official to manage the audit and accountability policy and procedures is defined; }} to manage the development, documentation, and dissemination of the audit and accountability policy and procedures; and\nc. Review and update the current audit and accountability:\n1. Policy at least annually and following {{ events - events that would require the current audit and accountability policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Audit and accountability policy and procedures address the controls in the AU family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of audit and accountability policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to audit and accountability policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AU-2", + "title": "Event Logging", + "summary": "Event Logging\na. Identify the types of events that the system is capable of logging in support of the audit function: successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes;\nb. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;\nc. Specify the following event types for logging within the system: organization-defined subset of the auditable events defined in AU-2a to be audited continually for each identified event.;\nd. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and\ne. Review and update the event types selected for logging annually and whenever there is a change in the threat environment.\nAU-2 Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.", + "guidance": "An event is an observable occurrence in a system. The types of events that require logging are those events that are significant and relevant to the security of systems and the privacy of individuals. Event logging also supports specific monitoring and auditing needs. Event types include password changes, failed logons or failed accesses related to systems, security or privacy attribute changes, administrative privilege usage, PIV credential usage, data action changes, query parameters, or external credential usage. In determining the set of event types that require logging, organizations consider the monitoring and auditing appropriate for each of the controls to be implemented. For completeness, event logging includes all protocols that are operational and supported by the system.\n\nTo balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. The types of events that organizations desire to be logged may change. Reviewing and updating the set of logged events is necessary to help ensure that the events remain relevant and continue to support the needs of the organization. Organizations consider how the types of logging events can reveal information about individuals that may give rise to privacy risk and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the logging event is based on patterns or time of usage.\n\nEvent logging requirements, including the need to log specific event types, may be referenced in other controls and control enhancements. These include [AC-2(4)], [AC-3(10)], [AC-6(9)], [AC-17(1)], [CM-3f], [CM-5(1)], [IA-3(3)(b)], [MA-4(1)], [MP-4(2)], [PE-3], [PM-21], [PT-7], [RA-8], [SC-7(9)], [SC-7(15)], [SI-3(8)], [SI-4(22)], [SI-7(8)] , and [SI-10(1)] . Organizations include event types that are required by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Audit records can be generated at various levels, including at the packet level as information traverses the network. Selecting the appropriate level of event logging is an important part of a monitoring and auditing capability and can identify the root causes of problems. When defining event types, organizations consider the logging necessary to cover related event types, such as the steps in distributed, transaction-based processes and the actions that occur in service-oriented architectures." + }, + { + "ref": "AU-3", + "title": "Content of Audit Records", + "summary": "Content of Audit Records\nEnsure that audit records contain information that establishes the following:\na. What type of event occurred;\nb. When the event occurred;\nc. Where the event occurred;\nd. Source of the event;\ne. Outcome of the event; and\nf. Identity of any individuals, subjects, or objects/entities associated with the event.\ncontrols AU-3(1) Additional Audit Information\nGenerate audit records containing the following additional information: session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands.\nAU-3 (1) Additional FedRAMP Requirements and Guidance ", + "guidance": "Audit record content that may be necessary to support the auditing function includes event descriptions (item a), time stamps (item b), source and destination addresses (item c), user or process identifiers (items d and f), success or fail indications (item e), and filenames involved (items a, c, e, and f) . Event outcomes include indicators of event success or failure and event-specific results, such as the system security and privacy posture after the event occurred. Organizations consider how audit records can reveal information about individuals that may give rise to privacy risks and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the trail records inputs or is based on patterns or time of usage." + }, + { + "ref": "AU-4", + "title": "Audit Log Storage Capacity", + "summary": "Audit Log Storage Capacity\nAllocate audit log storage capacity to accommodate {{ audit log retention requirements - audit log retention requirements are defined; }}.", + "guidance": "Organizations consider the types of audit logging to be performed and the audit log processing requirements when allocating audit log storage capacity. Allocating sufficient audit log storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of audit logging capability." + }, + { + "ref": "AU-5", + "title": "Response to Audit Logging Process Failures", + "summary": "Response to Audit Logging Process Failures\na. Alert {{ personnel or roles - personnel or roles receiving audit logging process failure alerts are defined; }} within {{ time period - time period for personnel or roles receiving audit logging process failure alerts is defined; }} in the event of an audit logging process failure; and\nb. Take the following additional actions: overwrite oldest record.\ncontrols AU-5(1) Storage Capacity Warning\nProvide a warning to {{ personnel, roles, and/or locations - personnel, roles, and/or locations to be warned when allocated audit log storage volume reaches a percentage of repository maximum audit log storage capacity. }} within {{ time period - time period for defined personnel, roles, and/or locations to be warned when allocated audit log storage volume reaches a percentage of repository maximum audit log storage capacity is defined; }} when allocated audit log storage volume reaches 75%, or one month before expected negative impact of repository maximum audit log storage capacity.\nAU-5(2) Real-time Alerts\nProvide an alert within real-time to service provider personnel with authority to address failed audit events when the following audit failure events occur: audit failure events requiring real-time alerts, as defined by organization audit policy.", + "guidance": "Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Organization-defined actions include overwriting oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel." + }, + { + "ref": "AU-6", + "title": "Audit Record Review, Analysis, and Reporting", + "summary": "Audit Record Review, Analysis, and Reporting\na. Review and analyze system audit records at least weekly for indications of {{ inappropriate or unusual activity - inappropriate or unusual activity is defined; }} and the potential impact of the inappropriate or unusual activity;\nb. Report findings to {{ personnel or roles - personnel or roles to receive findings from reviews and analyses of system records is/are defined; }} ; and\nc. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.\nAU-6 Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO. In multi-tenant environments, capability and means for providing review, analysis, and reporting to consumer for data pertaining to consumer shall be documented.\ncontrols AU-6(1) Automated Process Integration\nIntegrate audit record review, analysis, and reporting processes using {{ automated mechanisms - automated mechanisms used for integrating audit record review, analysis, and reporting processes are defined; }}.\nAU-6(3) Correlate Audit Record Repositories\nAnalyze and correlate audit records across different repositories to gain organization-wide situational awareness.\nAU-6(4) Central Review and Analysis\nProvide and implement the capability to centrally review and analyze audit records from multiple components within the system.\nAU-6(5) Integrated Analysis of Audit Records\nIntegrate analysis of audit records with analysis of vulnerability scanning information; performance data; information system monitoring information; penetration test data; {{ data/information collected from other sources - data/information collected from other sources to be analyzed is defined (if selected); }} to further enhance the ability to identify inappropriate or unusual activity.\nAU-6(6) Correlation with Physical Monitoring\nCorrelate information from audit records with information obtained from monitoring physical access to further enhance the ability to identify suspicious, inappropriate, unusual, or malevolent activity.\nAU-6 (6) Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.\nAU-6(7) Permitted Actions\nSpecify the permitted actions for each information system process; role; user associated with the review, analysis, and reporting of audit record information.", + "guidance": "Audit record review, analysis, and reporting covers information security- and privacy-related logging performed by organizations, including logging that results from the monitoring of account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, use of maintenance tools and non-local maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at system interfaces, and use of mobile code or Voice over Internet Protocol (VoIP). Findings can be reported to organizational entities that include the incident response team, help desk, and security or privacy offices. If organizations are prohibited from reviewing and analyzing audit records or unable to conduct such activities, the review or analysis may be carried out by other organizations granted such authority. The frequency, scope, and/or depth of the audit record review, analysis, and reporting may be adjusted to meet organizational needs based on new information received." + }, + { + "ref": "AU-7", + "title": "Audit Record Reduction and Report Generation", + "summary": "Audit Record Reduction and Report Generation\nProvide and implement an audit record reduction and report generation capability that:\na. Supports on-demand audit record review, analysis, and reporting requirements and after-the-fact investigations of incidents; and\nb. Does not alter the original content or time ordering of audit records.\ncontrols AU-7(1) Automatic Processing\nProvide and implement the capability to process, sort, and search audit records for events of interest based on the following content: {{ fields within audit records - fields within audit records that can be processed, sorted, or searched are defined; }}.", + "guidance": "Audit record reduction is a process that manipulates collected audit log information and organizes it into a summary format that is more meaningful to analysts. Audit record reduction and report generation capabilities do not always emanate from the same system or from the same organizational entities that conduct audit logging activities. The audit record reduction capability includes modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the system can generate customizable reports. Time ordering of audit records can be an issue if the granularity of the timestamp in the record is insufficient." + }, + { + "ref": "AU-8", + "title": "Time Stamps", + "summary": "Time Stamps\na. Use internal system clocks to generate time stamps for audit records; and\nb. Record time stamps for audit records that meet one second granularity of time measurement and that use Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or that include the local time offset as part of the time stamp.", + "guidance": "Time stamps generated by the system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., clocks synchronizing within hundreds of milliseconds or tens of milliseconds). Organizations may define different time granularities for different system components. Time service can be critical to other security capabilities such as access control and identification and authentication, depending on the nature of the mechanisms used to support those capabilities." + }, + { + "ref": "AU-9", + "title": "Protection of Audit Information", + "summary": "Protection of Audit Information\na. Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and\nb. Alert {{ personnel or roles - personnel or roles to be alerted upon detection of unauthorized access, modification, or deletion of audit information is/are defined; }} upon detection of unauthorized access, modification, or deletion of audit information.\ncontrols AU-9(2) Store on Separate Physical Systems or Components\nStore audit records at least weekly in a repository that is part of a physically different system or system component than the system or component being audited.\nAU-9(3) Cryptographic Protection\nImplement cryptographic mechanisms to protect the integrity of audit information and audit tools.\nAU-9 (3) Additional FedRAMP Requirements and Guidance \nAU-9(4) Access by Subset of Privileged Users\nAuthorize access to management of audit logging functionality to only {{ subset of privileged users or roles - a subset of privileged users or roles authorized to access management of audit logging functionality is defined; }}.", + "guidance": "Audit information includes all information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are those programs and devices used to conduct system audit and logging activities. Protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by both media protection controls and physical and environmental protection controls." + }, + { + "ref": "AU-10", + "title": "Non-repudiation", + "summary": "Non-repudiation\nProvide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed minimum actions including the addition, modification, deletion, approval, sending, or receiving of data.", + "guidance": "Types of individual actions covered by non-repudiation include creating information, sending and receiving messages, and approving information. Non-repudiation protects against claims by authors of not having authored certain documents, senders of not having transmitted messages, receivers of not having received messages, and signatories of not having signed documents. 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 receiving specific information). Organizations obtain non-repudiation services by employing various techniques or mechanisms, including digital signatures and digital message receipts." + }, + { + "ref": "AU-11", + "title": "Audit Record Retention", + "summary": "Audit Record Retention\nRetain audit records for a time period in compliance with M-21-31 to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.\nAU-11 Additional FedRAMP Requirements and Guidance Requirement: The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf)", + "guidance": "Organizations retain audit records until it is determined that the records are no longer needed for administrative, legal, audit, or other operational purposes. This includes the retention and availability of audit records relative to Freedom of Information Act (FOIA) requests, subpoenas, and law enforcement actions. Organizations develop standard categories of audit records relative to such types of actions and standard response processes for each type of action. The National Archives and Records Administration (NARA) General Records Schedules provide federal policy on records retention." + }, + { + "ref": "AU-12", + "title": "Audit Record Generation", + "summary": "Audit Record Generation\na. Provide audit record generation capability for the event types the system is capable of auditing as defined in [AU-2a] on all information system and network components where audit capability is deployed/available;\nb. Allow {{ personnel or roles - personnel or roles allowed to select the event types that are to be logged by specific components of the system is/are defined; }} to select the event types that are to be logged by specific components of the system; and\nc. Generate audit records for the event types defined in [AU-2c] that include the audit record content defined in [AU-3].\ncontrols AU-12(1) System-wide and Time-correlated Audit Trail\nCompile audit records from all network, data storage, and computing devices into a system-wide (logical or physical) audit trail that is time-correlated to within {{ level of tolerance - level of tolerance for the relationship between timestamps of individual records in the audit trail is defined; }}.\nAU-12(3) Changes by Authorized Individuals\nProvide and implement the capability for service provider-defined individuals or roles with audit configuration responsibilities to change the logging to be performed on all network, data storage, and computing devices based on {{ selectable event criteria - selectable event criteria with which change logging is to be performed are defined; }} within {{ time thresholds - time thresholds in which logging actions are to change is defined; }}.", + "guidance": "Audit records can be generated from many different system components. The event types specified in [AU-2d] are the event types for which audit logs are to be generated and are a subset of all event types for which the system can generate audit records." + } + ] + }, + { + "title": "Assessment, Authorization, and Monitoring", + "controls": [ + { + "ref": "CA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} assessment, authorization, and monitoring policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the assessment, authorization, and monitoring policy and the associated assessment, authorization, and monitoring controls;\nb. Designate an {{ official - an official to manage the assessment, authorization, and monitoring policy and procedures is defined; }} to manage the development, documentation, and dissemination of the assessment, authorization, and monitoring policy and procedures; and\nc. Review and update the current assessment, authorization, and monitoring:\n1. Policy at least annually and following {{ events - events that would require the current assessment, authorization, and monitoring policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Assessment, authorization, and monitoring policy and procedures address the controls in the CA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of assessment, authorization, and monitoring policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to assessment, authorization, and monitoring policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CA-2", + "title": "Control Assessments", + "summary": "Control Assessments\na. Select the appropriate assessor or assessment team for the type of assessment to be conducted;\nb. Develop a control assessment plan that describes the scope of the assessment including:\n1. Controls and control enhancements under assessment;\n2. Assessment procedures to be used to determine control effectiveness; and\n3. Assessment environment, assessment team, and assessment roles and responsibilities;\nc. Ensure the control assessment plan is reviewed and approved by the authorizing official or designated representative prior to conducting the assessment;\nd. Assess the controls in the system and its environment of operation at least annually to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements;\ne. Produce a control assessment report that document the results of the assessment; and\nf. Provide the results of the control assessment to individuals or roles to include FedRAMP PMO.\nCA-2 Additional FedRAMP Requirements and Guidance \ncontrols CA-2(1) Independent Assessors\nEmploy independent assessors or assessment teams to conduct control assessments.\nCA-2 (1) Additional FedRAMP Requirements and Guidance Requirement: For JAB Authorization, must use an accredited 3PAO.\nCA-2(2) Specialized Assessments\nInclude as part of control assessments, at least annually, {{ announced OR unannounced }}, {{ one or more: in-depth monitoring, security instrumentation, automated security test cases, vulnerability scanning, malicious user testing, insider threat assessment, performance and load testing, data leakage or data loss assessment, {{ other forms of assessment - other forms of assessment are defined (if selected); }} }}.\nCA-2 (2) Additional FedRAMP Requirements and Guidance Requirement: To include 'announced', 'vulnerability scanning'\nCA-2(3) Leveraging Results from External Organizations\nLeverage the results of control assessments performed by any FedRAMP Accredited 3PAO on {{ system - system on which a control assessment was performed by an external organization is defined; }} when the assessment meets the conditions of the JAB/AO in the FedRAMP Repository.", + "guidance": "Organizations ensure that control assessors possess the required skills and technical expertise to develop effective assessment plans and to conduct assessments of system-specific, hybrid, common, and program management controls, as appropriate. The required skills include general knowledge of risk management concepts and approaches as well as comprehensive knowledge of and experience with the hardware, software, and firmware system components implemented.\n\nOrganizations assess controls in systems and the environments in which those systems operate as part of initial and ongoing authorizations, continuous monitoring, FISMA annual assessments, system design and development, systems security engineering, privacy engineering, and the system development life cycle. Assessments help to ensure that organizations meet information security and privacy requirements, identify weaknesses and deficiencies in the system design and development process, provide essential information needed to make risk-based decisions as part of authorization processes, and comply with vulnerability mitigation procedures. Organizations conduct assessments on the implemented controls as documented in security and privacy plans. Assessments can also be conducted throughout the system development life cycle as part of systems engineering and systems security engineering processes. The design for controls can be assessed as RFPs are developed, responses assessed, and design reviews conducted. If a design to implement controls and subsequent implementation in accordance with the design are assessed during development, the final control testing can be a simple confirmation utilizing previously completed control assessment and aggregating the outcomes.\n\nOrganizations may develop a single, consolidated security and privacy assessment plan for the system or maintain separate plans. A consolidated assessment plan clearly delineates the roles and responsibilities for control assessment. If multiple organizations participate in assessing a system, a coordinated approach can reduce redundancies and associated costs.\n\nOrganizations can use other types of assessment activities, such as vulnerability scanning and system monitoring, to maintain the security and privacy posture of systems during the system life cycle. Assessment reports document assessment results in sufficient detail, as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting requirements. Assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of authorization decisions are provided to authorizing officials, senior agency officials for privacy, senior agency information security officers, and authorizing official designated representatives.\n\nTo satisfy annual assessment requirements, organizations can use assessment results from the following sources: initial or ongoing system authorizations, continuous monitoring, systems engineering processes, or system development life cycle activities. Organizations ensure that assessment results are current, relevant to the determination of control effectiveness, and obtained with the appropriate level of assessor independence. Existing control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. After the initial authorizations, organizations assess controls during continuous monitoring. Organizations also establish the frequency for ongoing assessments in accordance with organizational continuous monitoring strategies. External audits, including audits by external entities such as regulatory agencies, are outside of the scope of [CA-2]." + }, + { + "ref": "CA-3", + "title": "Information Exchange", + "summary": "Information Exchange\na. Approve and manage the exchange of information between the system and other systems using {{ one or more: interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service level agreements, user agreements, non-disclosure agreements, {{ type of agreement - the type of agreement used to approve and manage the exchange of information is defined (if selected); }} }};\nb. Document, as part of each exchange agreement, the interface characteristics, security and privacy requirements, controls, and responsibilities for each system, and the impact level of the information communicated; and\nc. Review and update the agreements at least annually and on input from JAB/AO.\ncontrols CA-3(6) Transfer Authorizations\nVerify that individuals or systems transferring data between interconnecting systems have the requisite authorizations (i.e., write permissions or privileges) prior to accepting such data.", + "guidance": "System information exchange requirements apply to information exchanges between two or more systems. System information exchanges include connections via leased lines or virtual private networks, connections to internet service providers, database sharing or exchanges of database transaction information, connections and exchanges with cloud services, exchanges via web-based services, or exchanges of files via file transfer protocols, network protocols (e.g., IPv4, IPv6), email, or other organization-to-organization communications. Organizations consider the risk related to new or increased threats that may be introduced when systems exchange information with other systems that may have different security and privacy requirements and controls. This includes systems within the same organization and systems that are external to the organization. A joint authorization of the systems exchanging information, as described in [CA-6(1)] or [CA-6(2)] , may help to communicate and reduce risk.\n\nAuthorizing officials determine the risk associated with system information exchange and the controls needed for appropriate risk mitigation. The types of agreements selected are based on factors such as the impact level of the information being exchanged, the relationship between the organizations exchanging information (e.g., government to government, government to business, business to business, government or business to service provider, government or business to individual), or the level of access to the organizational system by users of the other system. If systems that exchange information have the same authorizing official, organizations need not develop agreements. Instead, the interface characteristics between the systems (e.g., how the information is being exchanged. how the information is protected) are described in the respective security and privacy plans. If the systems that exchange information have different authorizing officials within the same organization, the organizations can develop agreements or provide the same information that would be provided in the appropriate agreement type from [CA-3a] in the respective security and privacy plans for the systems. Organizations may incorporate agreement information into formal contracts, especially for information exchanges established between federal agencies and nonfederal organizations (including service providers, contractors, system developers, and system integrators). Risk considerations include systems that share the same networks." + }, + { + "ref": "CA-5", + "title": "Plan of Action and Milestones", + "summary": "Plan of Action and Milestones\na. Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and\nb. Update existing plan of action and milestones at least monthly based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.\nCA-5 Additional FedRAMP Requirements and Guidance Requirement: POA&Ms must be provided at least monthly.", + "guidance": "Plans of action and milestones are useful for any type of organization to track planned remedial actions. Plans of action and milestones are required in authorization packages and subject to federal reporting requirements established by OMB." + }, + { + "ref": "CA-6", + "title": "Authorization", + "summary": "Authorization\na. Assign a senior official as the authorizing official for the system;\nb. Assign a senior official as the authorizing official for common controls available for inheritance by organizational systems;\nc. Ensure that the authorizing official for the system, before commencing operations:\n1. Accepts the use of common controls inherited by the system; and\n2. Authorizes the system to operate;\nd. Ensure that the authorizing official for common controls authorizes the use of those controls for inheritance by organizational systems;\ne. Update the authorizations in accordance with OMB A-130 requirements or when a significant change occurs.\nCA-6 Additional FedRAMP Requirements and Guidance ", + "guidance": "Authorizations are official management decisions by senior officials to authorize operation of systems, authorize the use of common controls for inheritance by organizational systems, and explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon controls. Authorizing officials provide budgetary oversight for organizational systems and common controls or assume responsibility for the mission and business functions supported by those systems or common controls. The authorization process is a federal responsibility, and therefore, authorizing officials must be federal employees. Authorizing officials are both responsible and accountable for security and privacy risks associated with the operation and use of organizational systems. Nonfederal organizations may have similar processes to authorize systems and senior officials that assume the authorization role and associated responsibilities.\n\nAuthorizing officials issue ongoing authorizations of systems based on evidence produced from implemented continuous monitoring programs. Robust continuous monitoring programs reduce the need for separate reauthorization processes. Through the employment of comprehensive continuous monitoring processes, the information contained in authorization packages (i.e., security and privacy plans, assessment reports, and plans of action and milestones) is updated on an ongoing basis. This provides authorizing officials, common control providers, and system owners with an up-to-date status of the security and privacy posture of their systems, controls, and operating environments. To reduce the cost of reauthorization, authorizing officials can leverage the results of continuous monitoring processes to the maximum extent possible as the basis for rendering reauthorization decisions." + }, + { + "ref": "CA-7", + "title": "Continuous Monitoring", + "summary": "Continuous Monitoring\nDevelop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes:\na. Establishing the following system-level metrics to be monitored: {{ system-level metrics - system-level metrics to be monitored are defined; }};\nb. Establishing {{ frequencies - frequencies at which to monitor control effectiveness are defined; }} for monitoring and {{ frequencies - frequencies at which to assess control effectiveness are defined; }} for assessment of control effectiveness;\nc. Ongoing control assessments in accordance with the continuous monitoring strategy;\nd. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy;\ne. Correlation and analysis of information generated by control assessments and monitoring;\nf. Response actions to address results of the analysis of control assessment and monitoring information; and\ng. Reporting the security and privacy status of the system to to include JAB/AO {{ organization-defined frequency }}.\nCA-7 Additional FedRAMP Requirements and Guidance Requirement: CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight. It does not apply to CSOs authorized via the JAB path because the JAB performs ConMon oversight.\ncontrols CA-7(1) Independent Assessment\nEmploy independent assessors or assessment teams to monitor the controls in the system on an ongoing basis.\nCA-7(4) Risk Monitoring\nEnsure risk monitoring is an integral part of the continuous monitoring strategy that includes the following:\n(a) Effectiveness monitoring;\n(b) Compliance monitoring; and\n(c) Change monitoring.", + "guidance": "Continuous monitoring at the system level facilitates ongoing awareness of the system security and privacy posture to support organizational risk management decisions. The terms \"continuous\" and \"ongoing\" imply that organizations assess and monitor their controls and risks at a frequency sufficient to support risk-based decisions. Different types of controls may require different monitoring frequencies. The results of continuous monitoring generate risk response actions by organizations. When monitoring the effectiveness of multiple controls that have been grouped into capabilities, a root-cause analysis may be needed to determine the specific control that has failed. Continuous monitoring programs allow organizations to maintain the authorizations of systems and common controls in highly dynamic environments of operation with changing mission and business needs, threats, vulnerabilities, and technologies. Having access to security and privacy information on a continuing basis through reports and dashboards gives organizational officials the ability to make effective and timely risk management decisions, including ongoing authorization decisions.\n\nAutomation supports more frequent updates to hardware, software, and firmware inventories, authorization packages, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of systems. Monitoring requirements, including the need for specific monitoring, may be referenced in other controls and control enhancements, such as [AC-2g], [AC-2(7)], [AC-2(12)(a)], [AC-2(7)(b)], [AC-2(7)(c)], [AC-17(1)], [AT-4a], [AU-13], [AU-13(1)], [AU-13(2)], [CM-3f], [CM-6d], [CM-11c], [IR-5], [MA-2b], [MA-3a], [MA-4a], [PE-3d], [PE-6], [PE-14b], [PE-16], [PE-20], [PM-6], [PM-23], [PM-31], [PS-7e], [SA-9c], [SR-4], [SC-5(3)(b)], [SC-7a], [SC-7(24)(b)], [SC-18b], [SC-43b] , and [SI-4]." + }, + { + "ref": "CA-8", + "title": "Penetration Testing", + "summary": "Penetration Testing\nConduct penetration testing at least annually on {{ system(s) or system components - systems or system components on which penetration testing is to be conducted are defined; }}.\nCA-8 Additional FedRAMP Requirements and Guidance \ncontrols CA-8(1) Independent Penetration Testing Agent or Team\nEmploy an independent penetration testing agent or team to perform penetration testing on the system or system components.\nCA-8(2) Red Team Exercises\nEmploy the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement: {{ red team exercises - red team exercises to simulate attempts by adversaries to compromise organizational systems are defined; }}.\nCM-2 Additional FedRAMP Requirements and Guidance ", + "guidance": "Penetration testing is a specialized type of assessment conducted on systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Penetration testing goes beyond automated vulnerability scanning and is conducted by agents and teams with demonstrable skills and experience that include technical expertise in network, operating system, and/or application level security. Penetration testing can be used to validate vulnerabilities or determine the degree of penetration resistance of systems to adversaries within specified constraints. Such constraints include time, resources, and skills. Penetration testing attempts to duplicate the actions of adversaries and provides a more in-depth analysis of security- and privacy-related weaknesses or deficiencies. Penetration testing is especially important when organizations are transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols).\n\nOrganizations can use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted internally or externally on the hardware, software, or firmware components of a system and can exercise both physical and technical controls. A standard method for penetration testing includes a pretest analysis based on full knowledge of the system, pretest identification of potential vulnerabilities based on the pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All parties agree to the rules of engagement before commencing penetration testing scenarios. Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries. Penetration testing may result in the exposure of information that is protected by laws or regulations, to individuals conducting the testing. Rules of engagement, contracts, or other appropriate mechanisms can be used to communicate expectations for how to protect this information. Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing." + }, + { + "ref": "CA-9", + "title": "Internal System Connections", + "summary": "Internal System Connections\na. Authorize internal connections of {{ system components - system components or classes of components requiring internal connections to the system are defined; }} to the system;\nb. Document, for each internal connection, the interface characteristics, security and privacy requirements, and the nature of the information communicated;\nc. Terminate internal system connections after {{ conditions - conditions requiring termination of internal connections are defined; }} ; and\nd. Review at least annually the continued need for each internal connection.", + "guidance": "Internal system connections are connections between organizational systems and separate constituent system components (i.e., connections between components that are part of the same system) including components used for system development. Intra-system connections include connections with mobile devices, notebook and desktop computers, tablets, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each internal system connection individually, organizations can authorize internal connections for a class of system components with common characteristics and/or configurations, including printers, scanners, and copiers with a specified processing, transmission, and storage capability or smart phones and tablets with a specific baseline configuration. The continued need for an internal system connection is reviewed from the perspective of whether it provides support for organizational missions or business functions." + } + ] + }, + { + "title": "Configuration Management", + "controls": [ + { + "ref": "CM-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} configuration management policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls;\nb. Designate an {{ official - an official to manage the configuration management policy and procedures is defined; }} to manage the development, documentation, and dissemination of the configuration management policy and procedures; and\nc. Review and update the current configuration management:\n1. Policy at least annually and following {{ events - events that would require the current configuration management policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Configuration management policy and procedures address the controls in the CM family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of configuration management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to configuration management policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CM-2", + "title": "Baseline Configuration", + "summary": "Baseline Configuration\na. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and\nb. Review and update the baseline configuration of the system:\n1. at least annually and when a significant change occurs;\n2. When required due to to include when directed by the JAB ; and\n3. When system components are installed or upgraded.\nCM-2 Additional FedRAMP Requirements and Guidance \ncontrols CM-2(2) Automation Support for Accuracy and Currency\nMaintain the currency, completeness, accuracy, and availability of the baseline configuration of the system using {{ automated mechanisms - automated mechanisms for maintaining baseline configuration of the system are defined; }}.\nCM-2(3) Retention of Previous Configurations\nRetain organization-defined number of previous versions of baseline configurations of the previously approved baseline configuration of IS components of previous versions of baseline configurations of the system to support rollback.\nCM-2(7) Configure Systems and Components for High-risk Areas\n(a) Issue {{ systems or system components - the systems or system components to be issued when individuals travel to high-risk areas are defined; }} with {{ configurations - configurations for systems or system components to be issued when individuals travel to high-risk areas are defined; }} to individuals traveling to locations that the organization deems to be of significant risk; and\n(b) Apply the following controls to the systems or components when the individuals return from travel: {{ controls - the controls to be applied when the individuals return from travel are defined; }}.", + "guidance": "Baseline configurations for systems and system components include connectivity, operational, and communications aspects of systems. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, or changes to systems and include security and privacy control implementations, operational procedures, information about system components, network topology, and logical placement of components in the system architecture. Maintaining baseline configurations requires creating new baselines as organizational systems change over time. Baseline configurations of systems reflect the current enterprise architecture." + }, + { + "ref": "CM-3", + "title": "Configuration Change Control", + "summary": "Configuration Change Control\na. Determine and document the types of changes to the system that are configuration-controlled;\nb. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses;\nc. Document configuration change decisions associated with the system;\nd. Implement approved configuration-controlled changes to the system;\ne. Retain records of configuration-controlled changes to the system for {{ time period - the time period to retain records of configuration-controlled changes is defined; }};\nf. Monitor and review activities associated with configuration-controlled changes to the system; and\ng. Coordinate and provide oversight for configuration change control activities through {{ configuration change control element - the configuration change control element responsible for coordinating and overseeing change control activities is defined; }} that convenes {{ one or more: {{ frequency - the frequency at which the configuration control element convenes is defined (if selected); }} , when {{ configuration change conditions - configuration change conditions that prompt the configuration control element to convene are defined (if selected); }} }}.\nCM-3 Additional FedRAMP Requirements and Guidance Requirement: The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB/AO.\ncontrols CM-3(1) Automated Documentation, Notification, and Prohibition of Changes\nUse {{ automated mechanisms - mechanisms used to automate configuration change control are defined; }} to:\n(a) Document proposed changes to the system;\n(b) Notify {{ approval authorities - approval authorities to be notified of and request approval for proposed changes to the system are defined; }} of proposed changes to the system and request change approval;\n(c) Highlight proposed changes to the system that have not been approved or disapproved within organization agreed upon time period;\n(d) Prohibit changes to the system until designated approvals are received;\n(e) Document all changes to the system; and\n(f) Notify organization defined configuration management approval authorities when approved changes to the system are completed.\nCM-3(2) Testing, Validation, and Documentation of Changes\nTest, validate, and document changes to the system before finalizing the implementation of the changes.\nCM-3(4) Security and Privacy Representatives\nRequire {{ organization-defined security and privacy representatives }} to be members of the Configuration control board (CCB) or similar (as defined in CM-3).\nCM-3(6) Cryptography Management\nEnsure that cryptographic mechanisms used to provide the following controls are under configuration management: All security safeguards that rely on cryptography.", + "guidance": "Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of system changes, including system upgrades and modifications. Configuration change control includes changes to baseline configurations, configuration items of systems, operational procedures, configuration settings for system components, remediate vulnerabilities, and unscheduled or unauthorized changes. Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes. For changes that impact privacy risk, the senior agency official for privacy updates privacy impact assessments and system of records notices. For new systems or major upgrades, organizations consider including representatives from the development organizations on the Configuration Control Boards or Change Advisory Boards. Auditing of changes includes activities before and after changes are made to systems and the auditing activities required to implement such changes. See also [SA-10]." + }, + { + "ref": "CM-4", + "title": "Impact Analyses", + "summary": "Impact Analyses\nAnalyze changes to the system to determine potential security and privacy impacts prior to change implementation.\ncontrols CM-4(1) Separate Test Environments\nAnalyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice.\nCM-4(2) Verification of Controls\nAfter system changes, verify that the impacted controls are implemented correctly, operating as intended, and producing the desired outcome with regard to meeting the security and privacy requirements for the system.", + "guidance": "Organizational personnel with security or privacy responsibilities conduct impact analyses. Individuals conducting impact analyses possess the necessary skills and technical expertise to analyze the changes to systems as well as the security or privacy ramifications. Impact analyses include reviewing security and privacy plans, policies, and procedures to understand control requirements; reviewing system design documentation and operational procedures to understand control implementation and how specific system changes might affect the controls; reviewing the impact of changes on organizational supply chain partners with stakeholders; and determining how potential changes to a system create new risks to the privacy of individuals and the ability of implemented controls to mitigate those risks. Impact analyses also include risk assessments to understand the impact of the changes and determine if additional controls are required." + }, + { + "ref": "CM-5", + "title": "Access Restrictions for Change", + "summary": "Access Restrictions for Change\nDefine, document, approve, and enforce physical and logical access restrictions associated with changes to the system.\ncontrols CM-5(1) Automated Access Enforcement and Audit Records\n(a) Enforce access restrictions using {{ automated mechanisms - mechanisms used to automate the enforcement of access restrictions are defined; }} ; and\n(b) Automatically generate audit records of the enforcement actions.\nCM-5(5) Privilege Limitation for Production and Operation\n(a) Limit privileges to change system components and system-related information within a production or operational environment; and\n(b) Review and reevaluate privileges at least quarterly.", + "guidance": "Changes to the hardware, software, or firmware components of systems or the operational procedures related to the system can potentially have significant effects on the security of the systems or individuals\u2019 privacy. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes. Access restrictions include physical and logical access controls (see [AC-3] and [PE-3] ), software libraries, workflow automation, media libraries, abstract layers (i.e., changes implemented into external interfaces rather than directly into systems), and change windows (i.e., changes occur only during specified times)." + }, + { + "ref": "CM-6", + "title": "Configuration Settings", + "summary": "Configuration Settings\na. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using {{ common secure configurations - common secure configurations to establish and document configuration settings for components employed within the system are defined; }};\nb. Implement the configuration settings;\nc. Identify, document, and approve any deviations from established configuration settings for {{ system components - system components for which approval of deviations is needed are defined; }} based on {{ operational requirements - operational requirements necessitating approval of deviations are defined; }} ; and\nd. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.\nCM-6 Additional FedRAMP Requirements and Guidance (a) Requirement 1: The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available.\n(a) Requirement 2: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).\ncontrols CM-6(1) Automated Management, Application, and Verification\nManage, apply, and verify configuration settings for {{ system components - system components for which to manage, apply, and verify configuration settings are defined; }} using {{ organization-defined automated mechanisms }}.\nCM-6(2) Respond to Unauthorized Changes\nTake the following actions in response to unauthorized changes to {{ configuration settings - configuration settings requiring action upon an unauthorized change are defined; }}: {{ actions - actions to be taken upon an unauthorized change are defined; }}.", + "guidance": "Configuration settings are the parameters that can be changed in the hardware, software, or firmware components of the system that affect the security and privacy posture or functionality of the system. Information technology products for which configuration settings can be defined include mainframe computers, servers, workstations, operating systems, mobile devices, input/output devices, protocols, and applications. Parameters that impact the security posture of systems include registry settings; account, file, or directory permission settings; and settings for functions, protocols, ports, services, and remote connections. Privacy parameters are parameters impacting the privacy posture of systems, including the parameters required to satisfy other privacy controls. Privacy parameters include settings for access controls, data processing preferences, and processing and retention permissions. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the configuration baseline for the system.\n\nCommon secure configurations (also known as security configuration checklists, lockdown and hardening guides, and security reference guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for information technology products and platforms as well as instructions for configuring those products or platforms to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, federal agencies, consortia, academia, industry, and other organizations in the public and private sectors.\n\nImplementation of a common secure configuration may be mandated at the organization level, mission and business process level, system level, or at a higher level, including by a regulatory agency. Common secure configurations include the United States Government Configuration Baseline [USGCB] and security technical implementation guides (STIGs), which affect the implementation of [CM-6] and other controls such as [AC-19] and [CM-7] . The Security Content Automation Protocol (SCAP) and the defined standards within the protocol provide an effective method to uniquely identify, track, and control configuration settings." + }, + { + "ref": "CM-7", + "title": "Least Functionality", + "summary": "Least Functionality\na. Configure the system to provide only {{ mission-essential capabilities - mission-essential capabilities for the system are defined; }} ; and\nb. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: {{ organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services }}.\nCM-7 Additional FedRAMP Requirements and Guidance (b) Requirement: The service provider shall use Security guidelines (See CM-6) to establish list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, protocols, and/or services if STIGs or CIS is not available.\ncontrols CM-7(1) Periodic Review\n(a) Review the system at least annually to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services; and\n(b) Disable or remove {{ organization-defined functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure }}.\nCM-7(2) Prevent Program Execution\nPrevent program execution in accordance with {{ one or more: {{ policies, rules of behavior, and/or access agreements regarding software program usage and restrictions - policies, rules of behavior, and/or access agreements regarding software program usage and restrictions are defined (if selected); }} , rules authorizing the terms and conditions of software program usage }}.\nCM-7 (2) Additional FedRAMP Requirements and Guidance \nCM-7(5) Authorized Software \u2014 Allow-by-exception\n(a) Identify {{ software programs - software programs authorized to execute on the system are defined; }};\n(b) Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and\n(c) Review and update the list of authorized software programs at least quarterly or when there is a change.", + "guidance": "Systems provide a wide variety of functions and services. Some of the functions and services routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see [SA-8], [SC-2] , and [SC-3])." + }, + { + "ref": "CM-8", + "title": "System Component Inventory", + "summary": "System Component Inventory\na. Develop and document an inventory of system components that:\n1. Accurately reflects the system;\n2. Includes all components within the system;\n3. Does not include duplicate accounting of components or components assigned to any other system;\n4. Is at the level of granularity deemed necessary for tracking and reporting; and\n5. Includes the following information to achieve system component accountability: {{ information - information deemed necessary to achieve effective system component accountability is defined; }} ; and\nb. Review and update the system component inventory at least monthly.\nCM-8 Additional FedRAMP Requirements and Guidance Requirement: must be provided at least monthly or when there is a change.\ncontrols CM-8(1) Updates During Installation and Removal\nUpdate the inventory of system components as part of component installations, removals, and system updates.\nCM-8(2) Automated Maintenance\nMaintain the currency, completeness, accuracy, and availability of the inventory of system components using {{ organization-defined automated mechanisms }}.\nCM-8(3) Automated Unauthorized Component Detection\n(a) Detect the presence of unauthorized hardware, software, and firmware components within the system using automated mechanisms with a maximum five-minute delay in detection continuously ; and\n(b) Take the following actions when unauthorized components are detected: {{ one or more: disable network access by unauthorized components, isolate unauthorized components, notify {{ personnel or roles - personnel or roles to be notified when unauthorized components are detected is/are defined (if selected); }} }}.\nCM-8(4) Accountability Information\nInclude in the system component inventory information, a means for identifying by position and role , individuals responsible and accountable for administering those components.", + "guidance": "System components are discrete, identifiable information technology assets that include hardware, software, and firmware. Organizations may choose to implement centralized system component inventories that include components from all organizational systems. In such situations, organizations ensure that the inventories include system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information, and for networked components, the machine names and network addresses across all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location.\n\nPreventing duplicate accounting of system components addresses the lack of accountability that occurs when component ownership and system association is not known, especially in large or complex connected systems. Effective prevention of duplicate accounting of system components necessitates use of a unique identifier for each component. For software inventory, centrally managed software that is accessed via other systems is addressed as a component of the system on which it is installed and managed. Software installed on multiple organizational systems and managed at the system level is addressed for each individual system and may appear more than once in a centralized component inventory, necessitating a system association for each software instance in the centralized inventory to avoid duplicate accounting of components. Scanning systems implementing multiple network protocols (e.g., IPv4 and IPv6) can result in duplicate components being identified in different address spaces. The implementation of [CM-8(7)] can help to eliminate duplicate accounting of components." + }, + { + "ref": "CM-9", + "title": "Configuration Management Plan", + "summary": "Configuration Management Plan\nDevelop, document, and implement a configuration management plan for the system that:\na. Addresses roles, responsibilities, and configuration management processes and procedures;\nb. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;\nc. Defines the configuration items for the system and places the configuration items under configuration management;\nd. Is reviewed and approved by {{ personnel or roles - personnel or roles to review and approve the configuration management plan is/are defined; }} ; and\ne. Protects the configuration management plan from unauthorized disclosure and modification.", + "guidance": "Configuration management activities occur throughout the system development life cycle. As such, there are developmental configuration management activities (e.g., the control of code and software libraries) and operational configuration management activities (e.g., control of installed components and how the components are configured). Configuration management plans satisfy the requirements in configuration management policies while being tailored to individual systems. Configuration management plans define processes and procedures for how configuration management is used to support system development life cycle activities.\n\nConfiguration management plans are generated during the development and acquisition stage of the system development life cycle. The plans describe how to advance changes through change management processes; update configuration settings and baselines; maintain component inventories; control development, test, and operational environments; and develop, release, and update key documents.\n\nOrganizations can employ templates to help ensure the consistent and timely development and implementation of configuration management plans. Templates can represent a configuration management plan for the organization with subsets of the plan implemented on a system by system basis. Configuration management approval processes include the designation of key stakeholders responsible for reviewing and approving proposed changes to systems, and personnel who conduct security and privacy impact analyses prior to the implementation of changes to the systems. Configuration items are the system components, such as the hardware, software, firmware, and documentation to be configuration-managed. As systems continue through the system development life cycle, new configuration items may be identified, and some existing configuration items may no longer need to be under configuration control." + }, + { + "ref": "CM-10", + "title": "Software Usage Restrictions", + "summary": "Software Usage Restrictions\na. Use software and associated documentation in accordance with contract agreements and copyright laws;\nb. Track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Control and document the use of 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.", + "guidance": "Software license tracking can be accomplished by manual or automated methods, depending on organizational needs. Examples of contract agreements include software license agreements and non-disclosure agreements." + }, + { + "ref": "CM-11", + "title": "User-installed Software", + "summary": "User-installed Software\na. Establish {{ policies - policies governing the installation of software by users are defined; }} governing the installation of software by users;\nb. Enforce software installation policies through the following methods: {{ methods - methods used to enforce software installation policies are defined; }} ; and\nc. Monitor policy compliance Continuously (via CM-7 (5)).", + "guidance": "If provided the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved \"app stores.\" Prohibited software installations include software with unknown or suspect pedigrees or software that organizations consider potentially malicious. Policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods." + }, + { + "ref": "CM-12", + "title": "Information Location", + "summary": "Information Location\na. Identify and document the location of {{ information - information for which the location is to be identified and documented is defined; }} and the specific system components on which the information is processed and stored;\nb. Identify and document the users who have access to the system and system components where the information is processed and stored; and\nc. Document changes to the location (i.e., system or system components) where the information is processed and stored.\nCM-12 Additional FedRAMP Requirements and Guidance Requirement: According to FedRAMP Authorization Boundary Guidance\ncontrols CM-12(1) Automated Tools to Support Information Location\nUse automated tools to identify Federal data and system data that must be protected at the High or Moderate impact levels on {{ system components - system components where the information is located are defined; }} to ensure controls are in place to protect organizational information and individual privacy.\nCM-12 (1) Additional FedRAMP Requirements and Guidance Requirement: According to FedRAMP Authorization Boundary Guidance.", + "guidance": "Information location addresses the need to understand where information is being processed and stored. Information location includes identifying where specific information types and information reside in system components and how information is being processed so that information flow can be understood and adequate protection and policy management provided for such information and system components. The security category of the information is also a factor in determining the controls necessary to protect the information and the system component where the information resides (see [FIPS 199] ). The location of the information and system components is also a factor in the architecture and design of the system (see [SA-4], [SA-8], [SA-17])." + }, + { + "ref": "CM-14", + "title": "Signed Components", + "summary": "Signed Components\nPrevent the installation of {{ organization-defined software and firmware components }} without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.", + "guidance": "Software and firmware components prevented from installation unless signed with recognized and approved certificates include software and firmware version updates, patches, service packs, device drivers, and basic input/output system updates. Organizations can identify applicable software and firmware components by type, by specific items, or a combination of both. Digital signatures and organizational verification of such signatures is a method of code authentication." + } + ] + }, + { + "title": "Contingency Planning", + "controls": [ + { + "ref": "CP-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} contingency planning policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the contingency planning policy and the associated contingency planning controls;\nb. Designate an {{ official - an official to manage the contingency planning policy and procedures is defined; }} to manage the development, documentation, and dissemination of the contingency planning policy and procedures; and\nc. Review and update the current contingency planning:\n1. Policy at least annually and following {{ events - events that would require the current contingency planning policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Contingency planning policy and procedures address the controls in the CP family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of contingency planning policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to contingency planning policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CP-2", + "title": "Contingency Plan", + "summary": "Contingency Plan\na. Develop a contingency plan for the system that:\n1. Identifies essential mission and business functions and associated contingency requirements;\n2. Provides recovery objectives, restoration priorities, and metrics;\n3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n4. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure;\n5. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented;\n6. Addresses the sharing of contingency information; and\n7. Is reviewed and approved by {{ organization-defined personnel or roles }};\nb. Distribute copies of the contingency plan to {{ organization-defined key contingency personnel (identified by name and/or by role) and organizational elements }};\nc. Coordinate contingency planning activities with incident handling activities;\nd. Review the contingency plan for the system at least annually;\ne. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\nf. Communicate contingency plan changes to {{ organization-defined key contingency personnel (identified by name and/or by role) and organizational elements }};\ng. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training; and\nh. Protect the contingency plan from unauthorized disclosure and modification.\nCP-2 Additional FedRAMP Requirements and Guidance Requirement: CSPs must use the FedRAMP Information System Contingency Plan (ISCP) Template (available on the fedramp.gov: https://www.fedramp.gov/assets/resources/templates/SSP-A06-FedRAMP-ISCP-Template.docx).\ncontrols CP-2(1) Coordinate with Related Plans\nCoordinate contingency plan development with organizational elements responsible for related plans.\nCP-2(2) Capacity Planning\nConduct capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations.\nCP-2(3) Resume Mission and Business Functions\nPlan for the resumption of all mission and business functions within time period defined in service provider and organization SLA of contingency plan activation.\nCP-2(5) Continue Mission and Business Functions\nPlan for the continuance of essential mission and business functions with minimal or no loss of operational continuity and sustains that continuity until full system restoration at primary processing and/or storage sites.\nCP-2(8) Identify Critical Assets\nIdentify critical system assets supporting {{ all OR essential }} mission and business functions.", + "guidance": "Contingency planning for systems is part of an overall program for achieving continuity of operations for organizational mission and business functions. Contingency planning addresses system restoration and implementation of alternative mission or business processes when systems are compromised or breached. Contingency planning is considered throughout the system development life cycle and is a fundamental part of the system design. Systems can be designed for redundancy, to provide backup capabilities, and for resilience. Contingency plans reflect the degree of restoration required for organizational systems since not all systems need to fully recover to achieve the level of continuity of operations desired. System recovery objectives reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, organizational risk tolerance, and system impact level.\n\nActions addressed in contingency plans include orderly system degradation, system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By coordinating contingency planning with incident handling activities, organizations ensure that the necessary planning activities are in place and activated in the event of an incident. Organizations consider whether continuity of operations during an incident conflicts with the capability to automatically disable the system, as specified in [IR-4(5)] . Incident response planning is part of contingency planning for organizations and is addressed in the [IR] (Incident Response) family." + }, + { + "ref": "CP-3", + "title": "Contingency Training", + "summary": "Contingency Training\na. Provide contingency training to system users consistent with assigned roles and responsibilities:\n1. Within \\*See Additional Requirements of assuming a contingency role or responsibility;\n2. When required by system changes; and\n3. at least annually thereafter; and\nb. Review and update contingency training content at least annually and following {{ events - events necessitating review and update of contingency training are defined; }}.\nCP-3 Additional FedRAMP Requirements and Guidance (a) Requirement: Privileged admins and engineers must take the basic contingency training within 10 days. Consideration must be given for those privileged admins and engineers with critical contingency-related roles, to gain enough system context and situational awareness to understand the full impact of contingency training as it applies to their respective level. Newly hired critical contingency personnel must take this more in-depth training within 60 days of hire date when the training will have more impact.\ncontrols CP-3(1) Simulated Events\nIncorporate simulated events into contingency training to facilitate effective response by personnel in crisis situations.", + "guidance": "Contingency training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail is included in such training. For example, some individuals may only need to know when and where to report for duty during contingency operations and if normal duties are affected; system administrators may require additional training on how to establish systems at alternate processing and storage sites; and organizational officials may receive more specific training on how to conduct mission-essential functions in designated off-site locations and how to establish communications with other governmental entities for purposes of coordination on contingency-related activities. Training for contingency roles or responsibilities reflects the specific continuity requirements in the contingency plan. Events that may precipitate an update to contingency training content include, but are not limited to, contingency plan testing or an actual contingency (lessons learned), assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. At the discretion of the organization, participation in a contingency plan test or exercise, including lessons learned sessions subsequent to the test or exercise, may satisfy contingency plan training requirements." + }, + { + "ref": "CP-4", + "title": "Contingency Plan Testing", + "summary": "Contingency Plan Testing\na. Test the contingency plan for the system at least annually using the following tests to determine the effectiveness of the plan and the readiness to execute the plan: functional exercises.\nb. Review the contingency plan test results; and\nc. Initiate corrective actions, if needed.\nCP-4 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider develops test plans in accordance with NIST Special Publication 800-34 (as amended); plans are approved by the JAB/AO prior to initiating testing.\n(b) Requirement: The service provider must include the Contingency Plan test results with the security package within the Contingency Plan-designated appendix (Appendix G, Contingency Plan Test Report).\ncontrols CP-4(1) Coordinate with Related Plans\nCoordinate contingency plan testing with organizational elements responsible for related plans.\nCP-4(2) Alternate Processing Site\nTest the contingency plan at the alternate processing site:\n(a) To familiarize contingency personnel with the facility and available resources; and\n(b) To evaluate the capabilities of the alternate processing site to support contingency operations.", + "guidance": "Methods for testing contingency plans to determine the effectiveness of the plans and identify potential weaknesses include checklists, walk-through and tabletop exercises, simulations (parallel or full interrupt), and comprehensive exercises. Organizations conduct testing based on the requirements in contingency plans and include a determination of the effects on organizational operations, assets, and individuals due to contingency operations. Organizations have flexibility and discretion in the breadth, depth, and timelines of corrective actions." + }, + { + "ref": "CP-6", + "title": "Alternate Storage Site", + "summary": "Alternate Storage Site\na. Establish an alternate storage site, including necessary agreements to permit the storage and retrieval of system backup information; and\nb. Ensure that the alternate storage site provides controls equivalent to that of the primary site.\ncontrols CP-6(1) Separation from Primary Site\nIdentify an alternate storage site that is sufficiently separated from the primary storage site to reduce susceptibility to the same threats.\nCP-6(2) Recovery Time and Recovery Point Objectives\nConfigure the alternate storage site to facilitate recovery operations in accordance with recovery time and recovery point objectives.\nCP-6(3) Accessibility\nIdentify potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outline explicit mitigation actions.", + "guidance": "Alternate storage sites are geographically distinct from primary storage sites and maintain duplicate copies of information and data if the primary storage site is not available. Similarly, alternate processing sites provide processing capability if the primary processing site is not available. Geographically distributed architectures that support contingency requirements may be considered alternate storage sites. Items covered by alternate storage site agreements include environmental conditions at the alternate sites, access rules for systems and facilities, physical and environmental protection requirements, and coordination of delivery and retrieval of backup media. Alternate storage sites reflect the requirements in contingency plans so that organizations can maintain essential mission and business functions despite compromise, failure, or disruption in organizational systems." + }, + { + "ref": "CP-7", + "title": "Alternate Processing Site", + "summary": "Alternate Processing Site\na. Establish an alternate processing site, including necessary agreements to permit the transfer and resumption of {{ system operations - system operations for essential mission and business functions are defined; }} for essential mission and business functions within {{ time period - time period consistent with recovery time and recovery point objectives is defined; }} when the primary processing capabilities are unavailable;\nb. Make available at the alternate processing site, the equipment and supplies required to transfer and resume operations or put contracts in place to support delivery to the site within the organization-defined time period for transfer and resumption; and\nc. Provide controls at the alternate processing site that are equivalent to those at the primary site.\nCP-7 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider defines a time period consistent with the recovery time objectives and business impact analysis.\ncontrols CP-7(1) Separation from Primary Site\nIdentify an alternate processing site that is sufficiently separated from the primary processing site to reduce susceptibility to the same threats.\nCP-7 (1) Additional FedRAMP Requirements and Guidance \nCP-7(2) Accessibility\nIdentify potential accessibility problems to alternate processing sites in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.\nCP-7(3) Priority of Service\nDevelop alternate processing site agreements that contain priority-of-service provisions in accordance with availability requirements (including recovery time objectives).\nCP-7(4) Preparation for Use\nPrepare the alternate processing site so that the site can serve as the operational site supporting essential mission and business functions.", + "guidance": "Alternate processing sites are geographically distinct from primary processing sites and provide processing capability if the primary processing site is not available. The alternate processing capability may be addressed using a physical processing site or other alternatives, such as failover to a cloud-based service provider or other internally or externally provided processing service. Geographically distributed architectures that support contingency requirements may also be considered alternate processing sites. Controls that are covered by alternate processing site agreements include the environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and the coordination for the transfer and assignment of personnel. Requirements are allocated to alternate processing sites that reflect the requirements in contingency plans to maintain essential mission and business functions despite disruption, compromise, or failure in organizational systems." + }, + { + "ref": "CP-8", + "title": "Telecommunications Services", + "summary": "Telecommunications Services\nEstablish alternate telecommunications services, including necessary agreements to permit the resumption of {{ system operations - system operations to be resumed for essential mission and business functions are defined; }} for essential mission and business functions within {{ time period - time period within which to resume essential mission and business functions when the primary telecommunications capabilities are unavailable is defined; }} when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites.\nCP-8 Additional FedRAMP Requirements and Guidance Requirement: The service provider defines a time period consistent with the recovery time objectives and business impact analysis.\ncontrols CP-8(1) Priority of Service Provisions\n(a) Develop primary and alternate telecommunications service agreements that contain priority-of-service provisions in accordance with availability requirements (including recovery time objectives); and\n(b) Request Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness if the primary and/or alternate telecommunications services are provided by a common carrier.\nCP-8(2) Single Points of Failure\nObtain alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services.\nCP-8(3) Separation of Primary and Alternate Providers\nObtain alternate telecommunications services from providers that are separated from primary service providers to reduce susceptibility to the same threats.\nCP-8(4) Provider Contingency Plan\n(a) Require primary and alternate telecommunications service providers to have contingency plans;\n(b) Review provider contingency plans to ensure that the plans meet organizational contingency requirements; and\n(c) Obtain evidence of contingency testing and training by providers annually.", + "guidance": "Telecommunications services (for data and voice) for primary and alternate processing and storage sites are in scope for [CP-8] . Alternate telecommunications services reflect the continuity requirements in contingency plans to maintain essential mission and business functions despite the loss of primary telecommunications services. Organizations may specify different time periods for primary or alternate sites. Alternate telecommunications services include additional organizational or commercial ground-based circuits or lines, network-based approaches to telecommunications, or the use of satellites. Organizations consider factors such as availability, quality of service, and access when entering into alternate telecommunications agreements." + }, + { + "ref": "CP-9", + "title": "System Backup", + "summary": "System Backup\na. Conduct backups of user-level information contained in {{ system components - system components for which to conduct backups of user-level information is defined; }} daily incremental; weekly full;\nb. Conduct backups of system-level information contained in the system daily incremental; weekly full;\nc. Conduct backups of system documentation, including security- and privacy-related documentation daily incremental; weekly full ; and\nd. Protect the confidentiality, integrity, and availability of backup information.\nCP-9 Additional FedRAMP Requirements and Guidance Requirement: The service provider shall determine what elements of the cloud environment require the Information System Backup control. The service provider shall determine how Information System Backup is going to be verified and appropriate periodicity of the check.\n(a) Requirement: The service provider maintains at least three backup copies of user-level information (at least one of which is available online) or provides an equivalent alternative.\n(b) Requirement: The service provider maintains at least three backup copies of system-level information (at least one of which is available online) or provides an equivalent alternative.\n(c) Requirement: The service provider maintains at least three backup copies of information system documentation including security information (at least one of which is available online) or provides an equivalent alternative.\ncontrols CP-9(1) Testing for Reliability and Integrity\nTest backup information at least monthly to verify media reliability and information integrity.\nCP-9(2) Test Restoration Using Sampling\nUse a sample of backup information in the restoration of selected system functions as part of contingency plan testing.\nCP-9(3) Separate Storage for Critical Information\nStore backup copies of {{ critical system software and other security-related information - critical system software and other security-related information backups to be stored in a separate facility are defined; }} in a separate facility or in a fire rated container that is not collocated with the operational system.\nCP-9(5) Transfer to Alternate Storage Site\nTransfer system backup information to the alternate storage site time period and transfer rate consistent with the recovery time and recovery point objectives defined in the service provider and organization SLA..\nCP-9(8) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure and modification of all backup files.\nCP-9 (8) Additional FedRAMP Requirements and Guidance ", + "guidance": "System-level information includes system state information, operating system software, middleware, application software, and licenses. User-level information includes information other than system-level information. Mechanisms employed to protect the integrity of system backups include digital signatures and cryptographic hashes. Protection of system backup information while in transit is addressed by [MP-5] and [SC-8] . System backups reflect the requirements in contingency plans as well as other organizational requirements for backing up information. Organizations may be subject to laws, executive orders, directives, regulations, or policies with requirements regarding specific categories of information (e.g., personal health information). Organizational personnel consult with the senior agency official for privacy and legal counsel regarding such requirements." + }, + { + "ref": "CP-10", + "title": "System Recovery and Reconstitution", + "summary": "System Recovery and Reconstitution\nProvide for the recovery and reconstitution of the system to a known state within {{ organization-defined time period consistent with recovery time and recovery point objectives }} after a disruption, compromise, or failure.\ncontrols CP-10(2) Transaction Recovery\nImplement transaction recovery for systems that are transaction-based.\nCP-10(4) Restore Within Time Period\nProvide the capability to restore system components within time period consistent with the restoration time-periods defined in the service provider and organization SLA from configuration-controlled and integrity-protected information representing a known, operational state for the components.", + "guidance": "Recovery is executing contingency plan activities to restore organizational mission and business functions. Reconstitution takes place following recovery and includes activities for returning systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities; recovery point, recovery time, and reconstitution objectives; and organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of interim system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored system capabilities, reestablishment of continuous monitoring activities, system reauthorization (if required), and activities to prepare the system and organization for future disruptions, breaches, compromises, or failures. Recovery and reconstitution capabilities can include automated mechanisms and manual procedures. Organizations establish recovery time and recovery point objectives as part of contingency planning." + } + ] + }, + { + "title": "Identification and Authentication", + "controls": [ + { + "ref": "IA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} identification and authentication policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the identification and authentication policy and the associated identification and authentication controls;\nb. Designate an {{ official - an official to manage the identification and authentication policy and procedures is defined; }} to manage the development, documentation, and dissemination of the identification and authentication policy and procedures; and\nc. Review and update the current identification and authentication:\n1. Policy at least annually and following {{ events - events that would require the current identification and authentication policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Identification and authentication policy and procedures address the controls in the IA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of identification and authentication policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to identification and authentication policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "IA-2", + "title": "Identification and Authentication (Organizational Users)", + "summary": "Identification and Authentication (Organizational Users)\nUniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.\nIA-2 Additional FedRAMP Requirements and Guidance Requirement: All uses of encrypted virtual private networks must meet all applicable Federal requirements and architecture, dataflow, and security and privacy controls must be documented, assessed, and authorized to operate.\ncontrols IA-2(1) Multi-factor Authentication to Privileged Accounts\nImplement multi-factor authentication for access to privileged accounts.\nIA-2 (1) Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\nIA-2(2) Multi-factor Authentication to Non-privileged Accounts\nImplement multi-factor authentication for access to non-privileged accounts.\nIA-2 (2) Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\nIA-2(5) Individual Authentication with Group Authentication\nWhen shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.\nIA-2(6) Access to Accounts \u2014separate Device\nImplement multi-factor authentication for local, network and remote access to privileged accounts; non-privileged accounts such that:\n(a) One of the factors is provided by a device separate from the system gaining access; and\n(b) The device meets FIPS-validated or NSA-approved cryptography.\nIA-2 (6) Additional FedRAMP Requirements and Guidance \nIA-2(8) Access to Accounts \u2014 Replay Resistant\nImplement replay-resistant authentication mechanisms for access to privileged accounts; non-privileged accounts.\nIA-2(12) Acceptance of PIV Credentials\nAccept and electronically verify Personal Identity Verification-compliant credentials.\nIA-2 (12) Additional FedRAMP Requirements and Guidance ", + "guidance": "Organizations can satisfy the identification and authentication requirements by complying with the requirements in [HSPD 12] . Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in [AC-14] and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity.\n\nOrganizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks.\n\nThe use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in [IA-8]." + }, + { + "ref": "IA-3", + "title": "Device Identification and Authentication", + "summary": "Device Identification and Authentication\nUniquely identify and authenticate {{ devices and/or types of devices - devices and/or types of devices to be uniquely identified and authenticated before establishing a connection are defined; }} before establishing a {{ one or more: local, remote, network }} connection.", + "guidance": "Devices that require unique device-to-device identification and authentication are defined by type, device, or a combination of type and device. Organization-defined device types include devices that are not owned by the organization. Systems use shared known information (e.g., Media Access Control [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and wide area networks. Organizations determine the required strength of authentication mechanisms based on the security categories of systems and mission or business requirements. Because of the challenges of implementing device authentication on a large scale, organizations can restrict the application of the control to a limited number/type of devices based on mission or business needs." + }, + { + "ref": "IA-4", + "title": "Identifier Management", + "summary": "Identifier Management\nManage system identifiers by:\na. Receiving authorization from at a minimum, the ISSO (or similar role within the organization) to assign an individual, group, role, service, or device identifier;\nb. Selecting an identifier that identifies an individual, group, role, service, or device;\nc. Assigning the identifier to the intended individual, group, role, service, or device; and\nd. Preventing reuse of identifiers for at least two (2) years.\ncontrols IA-4(4) Identify User Status\nManage individual identifiers by uniquely identifying each individual as contractors; foreign nationals.", + "guidance": "Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. The management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the usernames of the system accounts assigned to those individuals. In such instances, the account management activities of [AC-2] use account names provided by [IA-4] . Identifier management also addresses individual identifiers not necessarily associated with system accounts. Preventing the reuse of identifiers implies preventing the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices." + }, + { + "ref": "IA-5", + "title": "Authenticator Management", + "summary": "Authenticator Management\nManage system authenticators by:\na. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator;\nb. Establishing initial authenticator content for any authenticators issued by the organization;\nc. Ensuring that authenticators have sufficient strength of mechanism for their intended use;\nd. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators;\ne. Changing default authenticators prior to first use;\nf. Changing or refreshing authenticators {{ time period by authenticator type - a time period for changing or refreshing authenticators by authenticator type is defined; }} or when {{ events - events that trigger the change or refreshment of authenticators are defined; }} occur;\ng. Protecting authenticator content from unauthorized disclosure and modification;\nh. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and\ni. Changing authenticators for group or role accounts when membership to those accounts changes.\nIA-5 Additional FedRAMP Requirements and Guidance Requirement: Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 3. Link https://pages.nist.gov/800-63-3\ncontrols IA-5(1) Password-based Authentication\nFor password-based authentication:\n(a) Maintain a list of commonly-used, expected, or compromised passwords and update the list {{ frequency - the frequency at which to update the list of commonly used, expected, or compromised passwords is defined; }} and when organizational passwords are suspected to have been compromised directly or indirectly;\n(b) Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a);\n(c) Transmit passwords only over cryptographically-protected channels;\n(d) Store passwords using an approved salted key derivation function, preferably using a keyed hash;\n(e) Require immediate selection of a new password upon account recovery;\n(f) Allow user selection of long passwords and passphrases, including spaces and all printable characters;\n(g) Employ automated tools to assist the user in selecting strong password authenticators; and\n(h) Enforce the following composition and complexity rules: {{ composition and complexity rules - authenticator composition and complexity rules are defined; }}.\nIA-5 (1) Additional FedRAMP Requirements and Guidance Requirement: Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.\n(h) Requirement: For cases where technology doesn\u2019t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.\n\nFor emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.\nIA-5(2) Public Key-based Authentication\n(a) For public key-based authentication:\n(1) Enforce authorized access to the corresponding private key; and\n(2) Map the authenticated identity to the account of the individual or group; and\n(b) When public key infrastructure (PKI) is used:\n(1) Validate certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status information; and\n(2) Implement a local cache of revocation data to support path discovery and validation.\nIA-5(6) Protection of Authenticators\nProtect authenticators commensurate with the security category of the information to which use of the authenticator permits access.\nIA-5(7) No Embedded Unencrypted Static Authenticators\nEnsure that unencrypted static authenticators are not embedded in applications or other forms of static storage.\nIA-5 (7) Additional FedRAMP Requirements and Guidance \nIA-5(8) Multiple System Accounts\nImplement different authenticators in different user authentication domains to manage the risk of compromise due to individuals having accounts on multiple systems.\nIA-5 (8) Additional FedRAMP Requirements and Guidance \nIA-5(13) Expiration of Cached Authenticators\nProhibit the use of cached authenticators after {{ time period - the time period after which the use of cached authenticators is prohibited is defined; }}.\nIA-5 (13) Additional FedRAMP Requirements and Guidance ", + "guidance": "Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length). Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control [PL-4] or [PS-6] for authenticators in the possession of individuals and by controls [AC-3], [AC-6] , and [SC-28] for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges.\n\nSystems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics (e.g., minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication). Actions can be taken to safeguard individual authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed." + }, + { + "ref": "IA-6", + "title": "Authentication Feedback", + "summary": "Authentication Feedback\nObscure feedback of authentication information during the authentication process to protect the information from possible exploitation and use by unauthorized individuals.", + "guidance": "Authentication feedback from systems does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of systems, such as desktops or notebooks with relatively large monitors, the threat (referred to as shoulder surfing) may be significant. For other types of systems, such as mobile devices with small displays, the threat may be less significant and is balanced against the increased likelihood of typographic input errors due to small keyboards. Thus, the means for obscuring authentication feedback is selected accordingly. Obscuring authentication feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a very limited time before obscuring it." + }, + { + "ref": "IA-7", + "title": "Cryptographic Module Authentication", + "summary": "Cryptographic Module Authentication\nImplement mechanisms for authentication to a cryptographic module that meet the requirements of applicable laws, executive orders, directives, policies, regulations, standards, and guidelines for such authentication.", + "guidance": "Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role." + }, + { + "ref": "IA-8", + "title": "Identification and Authentication (Non-organizational Users)", + "summary": "Identification and Authentication (Non-organizational Users)\nUniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users.\ncontrols IA-8(1) Acceptance of PIV Credentials from Other Agencies\nAccept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.\nIA-8(2) Acceptance of External Authenticators\n(a) Accept only external authenticators that are NIST-compliant; and\n(b) Document and maintain a list of accepted external authenticators.\nIA-8(4) Use of Defined Profiles\nConform to the following profiles for identity management {{ identity management profiles - identity management profiles are defined; }}.", + "guidance": "Non-organizational users include system users other than organizational users explicitly covered by [IA-2] . Non-organizational users are uniquely identified and authenticated for accesses other than those explicitly identified and documented in [AC-14] . Identification and authentication of non-organizational users accessing federal systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations consider many factors\u2014including security, privacy, scalability, and practicality\u2014when balancing the need to ensure ease of use for access to federal information and systems with the need to protect and adequately mitigate risk." + }, + { + "ref": "IA-11", + "title": "Re-authentication", + "summary": "Re-authentication\nRequire users to re-authenticate when {{ circumstances or situations - circumstances or situations requiring re-authentication are defined; }}.\nIA-11 Additional FedRAMP Requirements and Guidance ", + "guidance": "In addition to the re-authentication requirements associated with device locks, organizations may require re-authentication of individuals in certain situations, including when roles, authenticators or credentials change, when security categories of systems change, when the execution of privileged functions occurs, after a fixed time period, or periodically." + }, + { + "ref": "IA-12", + "title": "Identity Proofing", + "summary": "Identity Proofing\na. Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines;\nb. Resolve user identities to a unique individual; and\nc. Collect, validate, and verify identity evidence.\nIA-12 Additional FedRAMP Requirements and Guidance \ncontrols IA-12(2) Identity Evidence\nRequire evidence of individual identification be presented to the registration authority.\nIA-12(3) Identity Evidence Validation and Verification\nRequire that the presented identity evidence be validated and verified through {{ methods of validation and verification - methods of validation and verification of identity evidence are defined; }}.\nIA-12(4) In-person Validation and Verification\nRequire that the validation and verification of identity evidence be conducted in person before a designated registration authority.\nIA-12(5) Address Confirmation\nRequire that a {{ registration code OR notice of proofing }} be delivered through an out-of-band channel to verify the users address (physical or digital) of record.\nIA-12 (5) Additional FedRAMP Requirements and Guidance ", + "guidance": "Identity proofing is the process of collecting, validating, and verifying a user\u2019s identity information for the purposes of establishing credentials for accessing a system. Identity proofing is intended to mitigate threats to the registration of users and the establishment of their accounts. Standards and guidelines specifying identity assurance levels for identity proofing include [SP 800-63-3] and [SP 800-63A] . Organizations may be subject to laws, executive orders, directives, regulations, or policies that address the collection of identity evidence. Organizational personnel consult with the senior agency official for privacy and legal counsel regarding such requirements." + } + ] + }, + { + "title": "Incident Response", + "controls": [ + { + "ref": "IR-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} incident response policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the incident response policy and the associated incident response controls;\nb. Designate an {{ official - an official to manage the incident response policy and procedures is defined; }} to manage the development, documentation, and dissemination of the incident response policy and procedures; and\nc. Review and update the current incident response:\n1. Policy at least annually and following {{ events - events that would require the current incident response policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Incident response policy and procedures address the controls in the IR family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of incident response policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to incident response policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "IR-2", + "title": "Incident Response Training", + "summary": "Incident Response Training\na. Provide incident response training to system users consistent with assigned roles and responsibilities:\n1. Within ten (10) days for privileged users, thirty (30) days for Incident Response roles of assuming an incident response role or responsibility or acquiring system access;\n2. When required by system changes; and\n3. at least annually thereafter; and\nb. Review and update incident response training content at least annually and following {{ events - events that initiate a review of the incident response training content are defined; }}.\ncontrols IR-2(1) Simulated Events\nIncorporate simulated events into incident response training to facilitate the required response by personnel in crisis situations.\nIR-2(2) Automated Training Environments\nProvide an incident response training environment using {{ automated mechanisms - automated mechanisms used in an incident response training environment are defined; }}.", + "guidance": "Incident response training is associated with the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail are included in such training. For example, users may only need to know who to call or how to recognize an incident; system administrators may require additional training on how to handle incidents; and incident responders may receive more specific training on forensics, data collection techniques, reporting, system recovery, and system restoration. Incident response training includes user training in identifying and reporting suspicious activities from external and internal sources. Incident response training for users may be provided as part of [AT-2] or [AT-3] . Events that may precipitate an update to incident response training content include, but are not limited to, incident response plan testing or response to an actual incident (lessons learned), assessment or audit findings, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "IR-3", + "title": "Incident Response Testing", + "summary": "Incident Response Testing\nTest the effectiveness of the incident response capability for the system at least every six (6) months, including functional at least annually using the following tests: {{ tests - tests used to test the effectiveness of the incident response capability for the system are defined; }}.\nIR-3-2 Additional FedRAMP Requirements and Guidance Requirement: The service provider defines tests and/or exercises in accordance with NIST Special Publication 800-61 (as amended). Functional testing must occur prior to testing for initial authorization. Annual functional testing may be concurrent with required penetration tests (see CA-8). The service provider provides test plans to the JAB/AO annually. Test plans are approved and accepted by the JAB/AO prior to test commencing.\ncontrols IR-3(2) Coordination with Related Plans\nCoordinate incident response testing with organizational elements responsible for related plans.", + "guidance": "Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Incident response testing includes the use of checklists, walk-through or tabletop exercises, and simulations (parallel or full interrupt). Incident response testing can include a determination of the effects on organizational operations and assets and individuals due to incident response. The use of qualitative and quantitative data aids in determining the effectiveness of incident response processes." + }, + { + "ref": "IR-4", + "title": "Incident Handling", + "summary": "Incident Handling\na. Implement an incident handling capability for incidents that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery;\nb. Coordinate incident handling activities with contingency planning activities;\nc. Incorporate lessons learned from ongoing incident handling activities into incident response procedures, training, and testing, and implement the resulting changes accordingly; and\nd. Ensure the rigor, intensity, scope, and results of incident handling activities are comparable and predictable across the organization.\nIR-4 Additional FedRAMP Requirements and Guidance Requirement: The service provider ensures that individuals conducting incident handling meet personnel security requirements commensurate with the criticality/sensitivity of the information being processed, stored, and transmitted by the information system.\ncontrols IR-4(1) Automated Incident Handling Processes\nSupport the incident handling process using {{ automated mechanisms - automated mechanisms used to support the incident handling process are defined; }}.\nIR-4(2) Dynamic Reconfiguration\nInclude the following types of dynamic reconfiguration for all network, data storage, and computing devices as part of the incident response capability: {{ types of dynamic reconfiguration - types of dynamic reconfiguration for system components are defined; }}.\nIR-4(4) Information Correlation\nCorrelate incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response.\nIR-4(6) Insider Threats\nImplement an incident handling capability for incidents involving insider threats.\nIR-4(11) Integrated Incident Response Team\nEstablish and maintain an integrated incident response team that can be deployed to any location identified by the organization in {{ time period - the time period within which an integrated incident response team can be deployed is defined; }}.", + "guidance": "Organizations recognize that incident response capabilities are dependent on the capabilities of organizational systems and the mission and business processes being supported by those systems. Organizations consider incident response as part of the definition, design, and development of mission and business processes and systems. Incident-related information can be obtained from a variety of sources, including audit monitoring, physical access monitoring, and network monitoring; user or administrator reports; and reported supply chain events. An effective incident handling capability includes coordination among many organizational entities (e.g., mission or business owners, system owners, authorizing officials, human resources offices, physical security offices, personnel security offices, legal departments, risk executive [function], operations personnel, procurement offices). Suspected security incidents include the receipt of suspicious email communications that can contain malicious code. Suspected supply chain incidents include the insertion of counterfeit hardware or malicious code into organizational systems or system components. For federal agencies, an incident that involves personally identifiable information is considered a breach. A breach results in unauthorized disclosure, the loss of control, unauthorized acquisition, compromise, or a similar occurrence where a person other than an authorized user accesses or potentially accesses personally identifiable information or an authorized user accesses or potentially accesses such information for other than authorized purposes." + }, + { + "ref": "IR-5", + "title": "Incident Monitoring", + "summary": "Incident Monitoring\nTrack and document incidents.\ncontrols IR-5(1) Automated Tracking, Data Collection, and Analysis\nTrack incidents and collect and analyze incident information using {{ organization-defined automated mechanisms }}.", + "guidance": "Documenting incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics as well as evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources, including network monitoring, incident reports, incident response teams, user complaints, supply chain partners, audit monitoring, physical access monitoring, and user and administrator reports. [IR-4] provides information on the types of incidents that are appropriate for monitoring." + }, + { + "ref": "IR-6", + "title": "Incident Reporting", + "summary": "Incident Reporting\na. Require personnel to report suspected incidents to the organizational incident response capability within US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended) ; and\nb. Report incident information to {{ authorities - authorities to whom incident information is to be reported are defined; }}.\nIR-6 Additional FedRAMP Requirements and Guidance Requirement: Reports security incident information according to FedRAMP Incident Communications Procedure.\ncontrols IR-6(1) Automated Reporting\nReport incidents using {{ automated mechanisms - automated mechanisms used for reporting incidents are defined; }}.\nIR-6(3) Supply Chain Coordination\nProvide incident information to the provider of the product or service and other organizations involved in the supply chain or supply chain governance for systems or system components related to the incident.", + "guidance": "The types of incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Incident information can inform risk assessments, control effectiveness assessments, security requirements for acquisitions, and selection criteria for technology products." + }, + { + "ref": "IR-7", + "title": "Incident Response Assistance", + "summary": "Incident Response Assistance\nProvide an incident response support resource, integral to the organizational incident response capability, that offers advice and assistance to users of the system for the handling and reporting of incidents.\ncontrols IR-7(1) Automation Support for Availability of Information and Support\nIncrease the availability of incident response information and support using {{ automated mechanisms - automated mechanisms used to increase the availability of incident response information and support are defined; }}.", + "guidance": "Incident response support resources provided by organizations include help desks, assistance groups, automated ticketing systems to open and track incident response tickets, and access to forensics services or consumer redress services, when required." + }, + { + "ref": "IR-8", + "title": "Incident Response Plan", + "summary": "Incident Response Plan\na. Develop an incident response plan that:\n1. Provides the organization with a roadmap for implementing its incident response capability;\n2. Describes the structure and organization of the incident response capability;\n3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n5. Defines reportable incidents;\n6. Provides metrics for measuring the incident response capability within the organization;\n7. Defines the resources and management support needed to effectively maintain and mature an incident response capability;\n8. Addresses the sharing of incident information;\n9. Is reviewed and approved by {{ personnel or roles - personnel or roles that review and approve the incident response plan is/are identified; }} at least annually ; and\n10. Explicitly designates responsibility for incident response to {{ entities, personnel, or roles - entities, personnel, or roles with designated responsibility for incident response are defined; }}.\nb. Distribute copies of the incident response plan to see additional FedRAMP Requirements and Guidance;\nc. Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing;\nd. Communicate incident response plan changes to see additional FedRAMP Requirements and Guidance ; and\ne. Protect the incident response plan from unauthorized disclosure and modification.\nIR-8 Additional FedRAMP Requirements and Guidance (b) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.\n(d) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.", + "guidance": "It is important that organizations develop and implement a coordinated approach to incident response. Organizational mission and business functions determine the structure of incident response capabilities. As part of the incident response capabilities, organizations consider the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain. For incidents involving personally identifiable information (i.e., breaches), include a process to determine whether notice to oversight organizations or affected individuals is appropriate and provide that notice accordingly." + }, + { + "ref": "IR-9", + "title": "Information Spillage Response", + "summary": "Information Spillage Response\nRespond to information spills by:\na. Assigning {{ personnel or roles - personnel or roles assigned the responsibility for responding to information spills is/are defined; }} with responsibility for responding to information spills;\nb. Identifying the specific information involved in the system contamination;\nc. Alerting {{ personnel or roles - personnel or roles to be alerted of the information spill using a method of communication not associated with the spill is/are defined; }} of the information spill using a method of communication not associated with the spill;\nd. Isolating the contaminated system or system component;\ne. Eradicating the information from the contaminated system or component;\nf. Identifying other systems or system components that may have been subsequently contaminated; and\ng. Performing the following additional actions: {{ actions - actions to be performed are defined; }}.\ncontrols IR-9(2) Training\nProvide information spillage response training at least annually.\nIR-9(3) Post-spill Operations\nImplement the following procedures to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions: {{ procedures - procedures to be implemented to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions are defined; }}.\nIR-9(4) Exposure to Unauthorized Personnel\nEmploy the following controls for personnel exposed to information not within assigned access authorizations: {{ controls - controls employed for personnel exposed to information not within assigned access authorizations are defined; }}.", + "guidance": "Information spillage refers to instances where information is placed on systems that are not authorized to process such information. Information spills occur when information that is thought to be a certain classification or impact level is transmitted to a system and subsequently is determined to be of a higher classification or impact level. At that point, corrective action is required. The nature of the response is based on the classification or impact level of the spilled information, the security capabilities of the system, the specific nature of the contaminated storage media, and the access authorizations of individuals with authorized access to the contaminated system. The methods used to communicate information about the spill after the fact do not involve methods directly associated with the actual spill to minimize the risk of further spreading the contamination before such contamination is isolated and eradicated." + } + ] + }, + { + "title": "Maintenance", + "controls": [ + { + "ref": "MA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} maintenance policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the maintenance policy and the associated maintenance controls;\nb. Designate an {{ official - an official to manage the maintenance policy and procedures is defined; }} to manage the development, documentation, and dissemination of the maintenance policy and procedures; and\nc. Review and update the current maintenance:\n1. Policy at least annually and following {{ events - events that would require the current maintenance policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Maintenance policy and procedures address the controls in the MA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of maintenance policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to maintenance policy and procedures assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "MA-2", + "title": "Controlled Maintenance", + "summary": "Controlled Maintenance\na. Schedule, document, and review records of maintenance, repair, and replacement on system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\nb. Approve and monitor all maintenance activities, whether performed on site or remotely and whether the system or system components are serviced on site or removed to another location;\nc. Require that {{ personnel or roles - personnel or roles required to explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance or repairs is/are defined; }} explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance, repair, or replacement;\nd. Sanitize equipment to remove the following information from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement: {{ information - information to be removed from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement is defined; }};\ne. Check all potentially impacted controls to verify that the controls are still functioning properly following maintenance, repair, or replacement actions; and\nf. Include the following information in organizational maintenance records: {{ information - information to be included in organizational maintenance records is defined; }}.\ncontrols MA-2(2) Automated Maintenance Activities\n(a) Schedule, conduct, and document maintenance, repair, and replacement actions for the system using {{ organization-defined automated mechanisms }} ; and\n(b) Produce up-to date, accurate, and complete records of all maintenance, repair, and replacement actions requested, scheduled, in process, and completed.", + "guidance": "Controlling system maintenance addresses the information security aspects of the system maintenance program and applies to all types of maintenance to system components conducted by local or nonlocal entities. Maintenance includes peripherals such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes the date and time of maintenance, a description of the maintenance performed, names of the individuals or group performing the maintenance, name of the escort, and system components or equipment that are removed or replaced. Organizations consider supply chain-related risks associated with replacement components for systems." + }, + { + "ref": "MA-3", + "title": "Maintenance Tools", + "summary": "Maintenance Tools\na. Approve, control, and monitor the use of system maintenance tools; and\nb. Review previously approved system maintenance tools at least annually.\ncontrols MA-3(1) Inspect Tools\nInspect the maintenance tools used by maintenance personnel for improper or unauthorized modifications.\nMA-3(2) Inspect Media\nCheck media containing diagnostic and test programs for malicious code before the media are used in the system.\nMA-3(3) Prevent Unauthorized Removal\nPrevent the removal of maintenance equipment containing organizational information by:\n(a) Verifying that there is no organizational information contained on the equipment;\n(b) Sanitizing or destroying the equipment;\n(c) Retaining the equipment within the facility; or\n(d) Obtaining an exemption from the information owner explicitly authorizing removal of the equipment from the facility.", + "guidance": "Approving, controlling, monitoring, and reviewing maintenance tools address security-related issues associated with maintenance tools that are not within system authorization boundaries and are used specifically for diagnostic and repair actions on organizational systems. Organizations have flexibility in determining roles for the approval of maintenance tools and how that approval is documented. A periodic review of maintenance tools facilitates the withdrawal of approval for outdated, unsupported, irrelevant, or no-longer-used tools. Maintenance tools can include hardware, software, and firmware items and may be pre-installed, brought in with maintenance personnel on media, cloud-based, or downloaded from a website. Such tools can be vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into systems. Maintenance tools can include hardware and software diagnostic test equipment and packet sniffers. The hardware and software components that support maintenance and are a part of the system (including the software implementing utilities such as \"ping,\" \"ls,\" \"ipconfig,\" or the hardware and software implementing the monitoring port of an Ethernet switch) are not addressed by maintenance tools." + }, + { + "ref": "MA-4", + "title": "Nonlocal Maintenance", + "summary": "Nonlocal Maintenance\na. Approve and monitor nonlocal maintenance and diagnostic activities;\nb. Allow the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the system;\nc. Employ strong authentication in the establishment of nonlocal maintenance and diagnostic sessions;\nd. Maintain records for nonlocal maintenance and diagnostic activities; and\ne. Terminate session and network connections when nonlocal maintenance is completed.\ncontrols MA-4(3) Comparable Security and Sanitization\n(a) Require that nonlocal maintenance and diagnostic services be performed from a system that implements a security capability comparable to the capability implemented on the system being serviced; or\n(b) Remove the component to be serviced from the system prior to nonlocal maintenance or diagnostic services; sanitize the component (for organizational information); and after the service is performed, inspect and sanitize the component (for potentially malicious software) before reconnecting the component to the system.", + "guidance": "Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network. Local maintenance and diagnostic activities are carried out by individuals who are physically present at the system location and not communicating across a network connection. Authentication techniques used to establish nonlocal maintenance and diagnostic sessions reflect the network access requirements in [IA-2] . Strong authentication requires authenticators that are resistant to replay attacks and employ multi-factor authentication. Strong authenticators include PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing requirements in [MA-4] is accomplished, in part, by other controls. [SP 800-63B] provides additional guidance on strong authentication and authenticators." + }, + { + "ref": "MA-5", + "title": "Maintenance Personnel", + "summary": "Maintenance Personnel\na. Establish a process for maintenance personnel authorization and maintain a list of authorized maintenance organizations or personnel;\nb. Verify that non-escorted personnel performing maintenance on the system possess the required access authorizations; and\nc. Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.\ncontrols MA-5(1) Individuals Without Appropriate Access\n(a) Implement procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements:\n(1) Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified; and\n(2) Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and\n(b) Develop and implement {{ alternate controls - alternate controls to be developed and implemented in the event that a system component cannot be sanitized, removed, or disconnected from the system are defined; }} in the event a system component cannot be sanitized, removed, or disconnected from the system.", + "guidance": "Maintenance personnel refers to individuals who perform hardware or software maintenance on organizational systems, while [PE-2] addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems. Technical competence of supervising individuals relates to the maintenance performed on the systems, while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized maintenance personnel\u2014such as information technology manufacturers, vendors, systems integrators, and consultants\u2014may require privileged access to organizational systems, such as when they are required to conduct maintenance activities with little or no notice. Based on organizational assessments of risk, organizations may issue temporary credentials to these individuals. Temporary credentials may be for one-time use or for very limited time periods." + }, + { + "ref": "MA-6", + "title": "Timely Maintenance", + "summary": "Timely Maintenance\nObtain maintenance support and/or spare parts for {{ system components - system components for which maintenance support and/or spare parts are obtained are defined; }} within a timeframe to support advertised uptime and availability of failure.", + "guidance": "Organizations specify the system components that result in increased risk to organizational operations and assets, individuals, other organizations, or the Nation when the functionality provided by those components is not operational. Organizational actions to obtain maintenance support include having appropriate contracts in place." + } + ] + }, + { + "title": "Media Protection", + "controls": [ + { + "ref": "MP-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} media protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the media protection policy and the associated media protection controls;\nb. Designate an {{ official - an official to manage the media protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the media protection policy and procedures; and\nc. Review and update the current media protection:\n1. Policy at least annually and following {{ events - events that would require the current media protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Media protection policy and procedures address the controls in the MP family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of media protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to media protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "MP-2", + "title": "Media Access", + "summary": "Media Access\nRestrict access to all types of digital and/or non-digital media containing sensitive information to {{ organization-defined personnel or roles }}.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers is an example of restricting access to non-digital media. Limiting access to the design specifications stored on compact discs in the media library to individuals on the system development team is an example of restricting access to digital media." + }, + { + "ref": "MP-3", + "title": "Media Marking", + "summary": "Media Marking\na. Mark system media indicating the distribution limitations, handling caveats, and applicable security markings (if any) of the information; and\nb. Exempt no removable media types from marking if the media remain within organization-defined security safeguards not applicable.\nMP-3 Additional FedRAMP Requirements and Guidance ", + "guidance": "Security marking refers to the application or use of human-readable security attributes. Digital media includes diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), flash drives, compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Controlled unclassified information is defined by the National Archives and Records Administration along with the appropriate safeguarding and dissemination requirements for such information and is codified in [32 CFR 2002] . Security markings are generally not required for media that contains information determined by organizations to be in the public domain or to be publicly releasable. Some organizations may require markings for public information indicating that the information is publicly releasable. System media marking reflects applicable laws, executive orders, directives, policies, regulations, standards, and guidelines." + }, + { + "ref": "MP-4", + "title": "Media Storage", + "summary": "Media Storage\na. Physically control and securely store all types of digital and non-digital media with sensitive information within see additional FedRAMP requirements and guidance ; and\nb. Protect system media types defined in MP-4a until the media are destroyed or sanitized using approved equipment, techniques, and procedures.\nMP-4 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider defines controlled areas within facilities where the information and information system reside.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Physically controlling stored media includes conducting inventories, ensuring procedures are in place to allow individuals to check out and return media to the library, and maintaining accountability for stored media. Secure storage includes a locked drawer, desk, or cabinet or a controlled media library. The type of media storage is commensurate with the security category or classification of the information on the media. Controlled areas are spaces that provide physical and procedural controls to meet the requirements established for protecting information and systems. Fewer controls may be needed for media that contains information determined to be in the public domain, publicly releasable, or have limited adverse impacts on organizations, operations, or individuals if accessed by other than authorized personnel. In these situations, physical access controls provide adequate protection." + }, + { + "ref": "MP-5", + "title": "Media Transport", + "summary": "Media Transport\na. Protect and control all media with sensitive information during transport outside of controlled areas using prior to leaving secure/controlled environment: for digital media, encryption in compliance with Federal requirements and utilizes FIPS validated or NSA approved cryptography (see SC-13.); for non-digital media, secured in locked container;\nb. Maintain accountability for system media during transport outside of controlled areas;\nc. Document activities associated with the transport of system media; and\nd. Restrict the activities associated with the transport of system media to authorized personnel.\nMP-5 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider defines security measures to protect digital and non-digital media in transport. The security measures are approved and accepted by the JAB/AO.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state and magnetic), compact discs, and digital versatile discs. Non-digital media includes microfilm and paper. Controlled areas are spaces for which organizations provide physical or procedural controls to meet requirements established for protecting information and systems. Controls to protect media during transport include cryptography and locked containers. Cryptographic mechanisms can provide confidentiality and integrity protections depending on the mechanisms implemented. Activities associated with media transport include releasing media for transport, ensuring that media enters the appropriate transport processes, and the actual transport. Authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability of media during transport includes restricting transport activities to authorized personnel and tracking and/or obtaining records of transport activities as the media moves through the transportation system to prevent and detect loss, destruction, or tampering. Organizations establish documentation requirements for activities associated with the transport of system media in accordance with organizational assessments of risk. Organizations maintain the flexibility to define record-keeping methods for the different types of media transport as part of a system of transport-related records." + }, + { + "ref": "MP-6", + "title": "Media Sanitization", + "summary": "Media Sanitization\na. Sanitize techniques and procedures IAW NIST SP 800-88 Section 4: Reuse and Disposal of Storage Media and Hardware prior to disposal, release out of organizational control, or release for reuse using {{ organization-defined sanitization techniques and procedures }} ; and\nb. Employ sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information.\ncontrols MP-6(1) Review, Approve, Track, Document, and Verify\nReview, approve, track, document, and verify media sanitization and disposal actions.\nMP-6 (1) Additional FedRAMP Requirements and Guidance Requirement: Must comply with NIST SP 800-88\nMP-6(2) Equipment Testing\nTest sanitization equipment and procedures at least every six (6) months to ensure that the intended sanitization is being achieved.\nMP-6 (2) Additional FedRAMP Requirements and Guidance \nMP-6(3) Nondestructive Techniques\nApply nondestructive sanitization techniques to portable storage devices prior to connecting such devices to the system under the following circumstances: {{ circumstances - circumstances requiring sanitization of portable storage devices are defined; }}.\nMP-6 (3) Additional FedRAMP Requirements and Guidance Requirement: Must comply with NIST SP 800-88", + "guidance": "Media sanitization applies to all digital and non-digital system media subject to disposal or reuse, whether or not the media is considered removable. Examples include digital media in scanners, copiers, printers, notebook computers, workstations, network components, mobile devices, and non-digital media (e.g., paper and microfilm). The sanitization process removes information from system media such that the information cannot be retrieved or reconstructed. Sanitization techniques\u2014including clearing, purging, cryptographic erase, de-identification of personally identifiable information, and destruction\u2014prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal. Organizations determine the appropriate sanitization methods, recognizing that destruction is sometimes necessary when other methods cannot be applied to media requiring sanitization. Organizations use discretion on the employment of approved sanitization techniques and procedures for media that contains information deemed to be in the public domain or publicly releasable or information deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes destruction, removing a classified appendix from an otherwise unclassified document, or redacting selected sections or words from a document by obscuring the redacted sections or words in a manner equivalent in effectiveness to removing them from the document. NSA standards and policies control the sanitization process for media that contains classified information. NARA policies control the sanitization process for controlled unclassified information." + }, + { + "ref": "MP-7", + "title": "Media Use", + "summary": "Media Use\na. {{ restrict OR prohibit }} the use of {{ types of system media - types of system media to be restricted or prohibited from use on systems or system components are defined; }} on {{ systems or system components - systems or system components on which the use of specific types of system media to be restricted or prohibited are defined; }} using {{ controls - controls to restrict or prohibit the use of specific types of system media on systems or system components are defined; }} ; and\nb. Prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", + "guidance": "System media includes both digital and non-digital media. Digital media includes diskettes, magnetic tapes, flash drives, compact discs, digital versatile discs, and removable hard disk drives. Non-digital media includes paper and microfilm. Media use protections also apply to mobile devices with information storage capabilities. In contrast to [MP-2] , which restricts user access to media, MP-7 restricts the use of certain types of media on systems, for example, restricting or prohibiting the use of flash drives or external hard disk drives. Organizations use technical and nontechnical controls to restrict the use of system media. Organizations may restrict the use of portable storage devices, for example, by using physical cages on workstations to prohibit access to certain external ports or disabling or removing the ability to insert, read, or write to such devices. Organizations may also limit the use of portable storage devices to only approved devices, including devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Finally, organizations may restrict the use of portable storage devices based on the type of device, such as by prohibiting the use of writeable, portable storage devices and implementing this restriction by disabling or removing the capability to write to such devices. Requiring identifiable owners for storage devices reduces the risk of using such devices by allowing organizations to assign responsibility for addressing known vulnerabilities in the devices." + } + ] + }, + { + "title": "Physical and Environmental Protection", + "controls": [ + { + "ref": "PE-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} physical and environmental protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the physical and environmental protection policy and the associated physical and environmental protection controls;\nb. Designate an {{ official - an official to manage the physical and environmental protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the physical and environmental protection policy and procedures; and\nc. Review and update the current physical and environmental protection:\n1. Policy at least annually and following {{ events - events that would require the current physical and environmental protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Physical and environmental protection policy and procedures address the controls in the PE family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of physical and environmental protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to physical and environmental protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PE-2", + "title": "Physical Access Authorizations", + "summary": "Physical Access Authorizations\na. Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides;\nb. Issue authorization credentials for facility access;\nc. Review the access list detailing authorized facility access by individuals at least every ninety (90) days ; and\nd. Remove individuals from the facility access list when access is no longer required.", + "guidance": "Physical access authorizations apply to employees and visitors. Individuals with permanent physical access authorization credentials are not considered visitors. Authorization credentials include ID badges, identification cards, and smart cards. Organizations determine the strength of authorization credentials needed consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Physical access authorizations may not be necessary to access certain areas within facilities that are designated as publicly accessible." + }, + { + "ref": "PE-3", + "title": "Physical Access Control", + "summary": "Physical Access Control\na. Enforce physical access authorizations at {{ entry and exit points - entry and exit points to the facility in which the system resides are defined; }} by:\n1. Verifying individual access authorizations before granting access to the facility; and\n2. Controlling ingress and egress to the facility using CSP defined physical access control systems/devices AND guards;\nb. Maintain physical access audit logs for {{ entry or exit points - entry or exit points for which physical access logs are maintained are defined; }};\nc. Control access to areas within the facility designated as publicly accessible by implementing the following controls: {{ physical access controls - physical access controls to control access to areas within the facility designated as publicly accessible are defined; }};\nd. Escort visitors and control visitor activity in all circumstances within restricted access area where the information system resides;\ne. Secure keys, combinations, and other physical access devices;\nf. Inventory {{ physical access devices - physical access devices to be inventoried are defined; }} every at least annually ; and\ng. Change combinations and keys at least annually or earlier as required by a security relevant event. and/or when keys are lost, combinations are compromised, or when individuals possessing the keys or combinations are transferred or terminated.\ncontrols PE-3(1) System Access\nEnforce physical access authorizations to the system in addition to the physical access controls for the facility at {{ physical spaces - physical spaces containing one or more components of the system are defined; }}.", + "guidance": "Physical access control applies to employees and visitors. Individuals with permanent physical access authorizations are not considered visitors. Physical access controls for publicly accessible areas may include physical access control logs/records, guards, or physical access devices and barriers to prevent movement from publicly accessible areas to non-public areas. Organizations determine the types of guards needed, including professional security staff, system users, or administrative staff. Physical access devices include keys, locks, combinations, biometric readers, and card readers. Physical access control systems comply with applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural, automated, or some combination thereof. Physical access points can include facility access points, interior access points to systems that require supplemental access controls, or both. Components of systems may be in areas designated as publicly accessible with organizations controlling access to the components." + }, + { + "ref": "PE-4", + "title": "Access Control for Transmission", + "summary": "Access Control for Transmission\nControl physical access to {{ system distribution and transmission lines - system distribution and transmission lines requiring physical access controls are defined; }} within organizational facilities using {{ security controls - security controls to be implemented to control physical access to system distribution and transmission lines within the organizational facility are defined; }}.", + "guidance": "Security controls applied to system distribution and transmission lines prevent accidental damage, disruption, and physical tampering. Such controls may also be necessary to prevent eavesdropping or modification of unencrypted transmissions. Security controls used to control physical access to system distribution and transmission lines include disconnected or locked spare jacks, locked wiring closets, protection of cabling by conduit or cable trays, and wiretapping sensors." + }, + { + "ref": "PE-5", + "title": "Access Control for Output Devices", + "summary": "Access Control for Output Devices\nControl physical access to output from {{ output devices - output devices that require physical access control to output are defined; }} to prevent unauthorized individuals from obtaining the output.", + "guidance": "Controlling physical access to output devices includes placing output devices in locked rooms or other secured areas with keypad or card reader access controls and allowing access to authorized individuals only, placing output devices in locations that can be monitored by personnel, installing monitor or screen filters, and using headphones. Examples of output devices include monitors, printers, scanners, audio devices, facsimile machines, and copiers." + }, + { + "ref": "PE-6", + "title": "Monitoring Physical Access", + "summary": "Monitoring Physical Access\na. Monitor physical access to the facility where the system resides to detect and respond to physical security incidents;\nb. Review physical access logs at least monthly and upon occurrence of {{ events - events or potential indication of events requiring physical access logs to be reviewed are defined; }} ; and\nc. Coordinate results of reviews and investigations with the organizational incident response capability.\ncontrols PE-6(1) Intrusion Alarms and Surveillance Equipment\nMonitor physical access to the facility where the system resides using physical intrusion alarms and surveillance equipment.\nPE-6(4) Monitoring Physical Access to Systems\nMonitor physical access to the system in addition to the physical access monitoring of the facility at {{ physical spaces - physical spaces containing one or more components of the system are defined; }}.", + "guidance": "Physical access monitoring includes publicly accessible areas within organizational facilities. Examples of physical access monitoring include the employment of guards, video surveillance equipment (i.e., cameras), and sensor devices. Reviewing physical access logs can help identify suspicious activity, anomalous events, or potential threats. The reviews can be supported by audit logging controls, such as [AU-2] , if the access logs are part of an automated system. Organizational incident response capabilities include investigations of physical security incidents and responses to the incidents. Incidents include security violations or suspicious physical access activities. Suspicious physical access activities include accesses outside of normal work hours, repeated accesses to areas not normally accessed, accesses for unusual lengths of time, and out-of-sequence accesses." + }, + { + "ref": "PE-8", + "title": "Visitor Access Records", + "summary": "Visitor Access Records\na. Maintain visitor access records to the facility where the system resides for for a minimum of one (1) year;\nb. Review visitor access records at least monthly ; and\nc. Report anomalies in visitor access records to {{ personnel - personnel to whom visitor access records anomalies are reported to is/are defined; }}.\ncontrols PE-8(1) Automated Records Maintenance and Review\nMaintain and review visitor access records using {{ organization-defined automated mechanisms }}.", + "guidance": "Visitor access records include the names and organizations of individuals visiting, visitor signatures, forms of identification, dates of access, entry and departure times, purpose of visits, and the names and organizations of individuals visited. Access record reviews determine if access authorizations are current and are still required to support organizational mission and business functions. Access records are not required for publicly accessible areas." + }, + { + "ref": "PE-9", + "title": "Power Equipment and Cabling", + "summary": "Power Equipment and Cabling\nProtect power equipment and power cabling for the system from damage and destruction.", + "guidance": "Organizations determine the types of protection necessary for the power equipment and cabling employed at different locations that are both internal and external to organizational facilities and environments of operation. Types of power equipment and cabling include internal cabling and uninterruptable power sources in offices or data centers, generators and power cabling outside of buildings, and power sources for self-contained components such as satellites, vehicles, and other deployable systems." + }, + { + "ref": "PE-10", + "title": "Emergency Shutoff", + "summary": "Emergency Shutoff\na. Provide the capability of shutting off power to {{ system or individual system components - system or individual system components that require the capability to shut off power in emergency situations is/are defined; }} in emergency situations;\nb. Place emergency shutoff switches or devices in near more than one egress point of the IT area and ensures it is labeled and protected by a cover to prevent accidental shut-off to facilitate access for authorized personnel; and\nc. Protect emergency power shutoff capability from unauthorized activation.", + "guidance": "Emergency power shutoff primarily applies to organizational facilities that contain concentrations of system resources, including data centers, mainframe computer rooms, server rooms, and areas with computer-controlled machinery." + }, + { + "ref": "PE-11", + "title": "Emergency Power", + "summary": "Emergency Power\nProvide an uninterruptible power supply to facilitate {{ an orderly shutdown of the system OR transition of the system to long-term alternate power }} in the event of a primary power source loss.\ncontrols PE-11(1) Alternate Power Supply \u2014 Minimal Operational Capability\nProvide an alternate power supply for the system that is activated automatically and that can maintain minimally required operational capability in the event of an extended loss of the primary power source.", + "guidance": "An uninterruptible power supply (UPS) is an electrical system or mechanism that provides emergency power when there is a failure of the main power source. A UPS is typically used to protect computers, data centers, telecommunication equipment, or other electrical equipment where an unexpected power disruption could cause injuries, fatalities, serious mission or business disruption, or loss of data or information. A UPS differs from an emergency power system or backup generator in that the UPS provides near-instantaneous protection from unanticipated power interruptions from the main power source by providing energy stored in batteries, supercapacitors, or flywheels. The battery duration of a UPS is relatively short but provides sufficient time to start a standby power source, such as a backup generator, or properly shut down the system." + }, + { + "ref": "PE-12", + "title": "Emergency Lighting", + "summary": "Emergency Lighting\nEmploy and maintain automatic emergency lighting for the system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "guidance": "The provision of emergency lighting applies primarily to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Emergency lighting provisions for the system are described in the contingency plan for the organization. If emergency lighting for the system fails or cannot be provided, organizations consider alternate processing sites for power-related contingencies." + }, + { + "ref": "PE-13", + "title": "Fire Protection", + "summary": "Fire Protection\nEmploy and maintain fire detection and suppression systems that are supported by an independent energy source.\ncontrols PE-13(1) Detection Systems \u2014 Automatic Activation and Notification\nEmploy fire detection systems that activate automatically and notify service provider building maintenance/physical security personnel and service provider emergency responders with incident response responsibilities in the event of a fire.\nPE-13(2) Suppression Systems \u2014 Automatic Activation and Notification\n(a) Employ fire suppression systems that activate automatically and notify {{ personnel or roles - personnel or roles to be notified in the event of a fire is/are defined; }} and {{ emergency responders - emergency responders to be notified in the event of a fire are defined; }} ; and\n(b) Employ an automatic fire suppression capability when the facility is not staffed on a continuous basis.", + "guidance": "The provision of fire detection and suppression systems applies primarily to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Fire detection and suppression systems that may require an independent energy source include sprinkler systems and smoke detectors. An independent energy source is an energy source, such as a microgrid, that is separate, or can be separated, from the energy sources providing power for the other parts of the facility." + }, + { + "ref": "PE-14", + "title": "Environmental Controls", + "summary": "Environmental Controls\na. Maintain consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments levels within the facility where the system resides at {{ acceptable levels - acceptable levels for environmental controls are defined; }} ; and\nb. Monitor environmental control levels continuously.\nPE-14 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider measures temperature at server inlets and humidity levels by dew point.\ncontrols PE-14(2) Monitoring with Alarms and Notifications\nEmploy environmental control monitoring that provides an alarm or notification of changes potentially harmful to personnel or equipment to {{ personnel or roles - personnel or roles to be notified by environmental control monitoring when environmental changes are potentially harmful to personnel or equipment is/are defined; }}.", + "guidance": "The provision of environmental controls applies primarily to organizational facilities that contain concentrations of system resources (e.g., data centers, mainframe computer rooms, and server rooms). Insufficient environmental controls, especially in very harsh environments, can have a significant adverse impact on the availability of systems and system components that are needed to support organizational mission and business functions." + }, + { + "ref": "PE-15", + "title": "Water Damage Protection", + "summary": "Water Damage Protection\nProtect the system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel.\ncontrols PE-15(1) Automation Support\nDetect the presence of water near the system and alert service provider building maintenance/physical security personnel using {{ automated mechanisms - automated mechanisms used to detect the presence of water near the system are defined; }}.", + "guidance": "The provision of water damage protection primarily applies to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Isolation valves can be employed in addition to or in lieu of master shutoff valves to shut off water supplies in specific areas of concern without affecting entire organizations." + }, + { + "ref": "PE-16", + "title": "Delivery and Removal", + "summary": "Delivery and Removal\na. Authorize and control all information system components entering and exiting the facility; and\nb. Maintain records of the system components.", + "guidance": "Enforcing authorizations for entry and exit of system components may require restricting access to delivery areas and isolating the areas from the system and media libraries." + }, + { + "ref": "PE-17", + "title": "Alternate Work Site", + "summary": "Alternate Work Site\na. Determine and document the {{ alternate work sites - alternate work sites allowed for use by employees are defined; }} allowed for use by employees;\nb. Employ the following controls at alternate work sites: {{ controls - controls to be employed at alternate work sites are defined; }};\nc. Assess the effectiveness of controls at alternate work sites; and\nd. Provide a means for employees to communicate with information security and privacy personnel in case of incidents.", + "guidance": "Alternate work sites include government facilities or the private residences of employees. While distinct from alternative processing sites, alternate work sites can provide readily available alternate locations during contingency operations. Organizations can define different sets of controls for specific alternate work sites or types of sites depending on the work-related activities conducted at the sites. Implementing and assessing the effectiveness of organization-defined controls and providing a means to communicate incidents at alternate work sites supports the contingency planning activities of organizations." + }, + { + "ref": "PE-18", + "title": "Location of System Components", + "summary": "Location of System Components\nPosition system components within the facility to minimize potential damage from physical and environmental hazards identified during threat assessment and to minimize the opportunity for unauthorized access.", + "guidance": "Physical and environmental hazards include floods, fires, tornadoes, earthquakes, hurricanes, terrorism, vandalism, an electromagnetic pulse, electrical interference, and other forms of incoming electromagnetic radiation. Organizations consider the location of entry points where unauthorized individuals, while not being granted access, might nonetheless be near systems. Such proximity can increase the risk of unauthorized access to organizational communications using wireless packet sniffers or microphones, or unauthorized disclosure of information." + } + ] + }, + { + "title": "Planning", + "controls": [ + { + "ref": "PL-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} planning policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the planning policy and the associated planning controls;\nb. Designate an {{ official - an official to manage the planning policy and procedures is defined; }} to manage the development, documentation, and dissemination of the planning policy and procedures; and\nc. Review and update the current planning:\n1. Policy at least annually and following {{ events - events that would require the current planning policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Planning policy and procedures for the controls in the PL family implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to planning policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PL-2", + "title": "System Security and Privacy Plans", + "summary": "System Security and Privacy Plans\na. Develop security and privacy plans for the system that:\n1. Are consistent with the organization\u2019s enterprise architecture;\n2. Explicitly define the constituent system components;\n3. Describe the operational context of the system in terms of mission and business processes;\n4. Identify the individuals that fulfill system roles and responsibilities;\n5. Identify the information types processed, stored, and transmitted by the system;\n6. Provide the security categorization of the system, including supporting rationale;\n7. Describe any specific threats to the system that are of concern to the organization;\n8. Provide the results of a privacy risk assessment for systems processing personally identifiable information;\n9. Describe the operational environment for the system and any dependencies on or connections to other systems or system components;\n10. Provide an overview of the security and privacy requirements for the system;\n11. Identify any relevant control baselines or overlays, if applicable;\n12. Describe the controls in place or planned for meeting the security and privacy requirements, including a rationale for any tailoring decisions;\n13. Include risk determinations for security and privacy architecture and design decisions;\n14. Include security- and privacy-related activities affecting the system that require planning and coordination with to include chief privacy and ISSO and/or similar role or designees ; and\n15. Are reviewed and approved by the authorizing official or designated representative prior to plan implementation.\nb. Distribute copies of the plans and communicate subsequent changes to the plans to to include chief privacy and ISSO and/or similar role;\nc. Review the plans at least annually;\nd. Update the plans to address changes to the system and environment of operation or problems identified during plan implementation or control assessments; and\ne. Protect the plans from unauthorized disclosure and modification.", + "guidance": "System security and privacy plans are scoped to the system and system components within the defined authorization boundary and contain an overview of the security and privacy requirements for the system and the controls selected to satisfy the requirements. The plans describe the intended application of each selected control in the context of the system with a sufficient level of detail to correctly implement the control and to subsequently assess the effectiveness of the control. The control documentation describes how system-specific and hybrid controls are implemented and the plans and expectations regarding the functionality of the system. System security and privacy plans can also be used in the design and development of systems in support of life cycle-based security and privacy engineering processes. System security and privacy plans are living documents that are updated and adapted throughout the system development life cycle (e.g., during capability determination, analysis of alternatives, requests for proposal, and design reviews). [Section 2.1] describes the different types of requirements that are relevant to organizations during the system development life cycle and the relationship between requirements and controls.\n\nOrganizations may develop a single, integrated security and privacy plan or maintain separate plans. Security and privacy plans relate security and privacy requirements to a set of controls and control enhancements. The plans describe how the controls and control enhancements meet the security and privacy requirements but do not provide detailed, technical descriptions of the design or implementation of the controls and control enhancements. Security and privacy plans contain sufficient information (including specifications of control parameter values for selection and assignment operations explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented.\n\nSecurity and privacy plans need not be single documents. The plans can be a collection of various documents, including documents that already exist. Effective security and privacy plans make extensive use of references to policies, procedures, and additional documents, including design and implementation specifications where more detailed information can be obtained. The use of references helps reduce the documentation associated with security and privacy programs and maintains the security- and privacy-related information in other established management and operational areas, including enterprise architecture, system development life cycle, systems engineering, and acquisition. Security and privacy plans need not contain detailed contingency plan or incident response plan information but can instead provide\u2014explicitly or by reference\u2014sufficient information to define what needs to be accomplished by those plans.\n\nSecurity- and privacy-related activities that may require coordination and planning with other individuals or groups within the organization include assessments, audits, inspections, hardware and software maintenance, acquisition and supply chain risk management, patch management, and contingency plan testing. Planning and coordination include emergency and nonemergency (i.e., planned or non-urgent unplanned) situations. The process defined by organizations to plan and coordinate security- and privacy-related activities can also be included in other documents, as appropriate." + }, + { + "ref": "PL-4", + "title": "Rules of Behavior", + "summary": "Rules of Behavior\na. Establish and provide to individuals requiring access to the system, the rules that describe their responsibilities and expected behavior for information and system usage, security, and privacy;\nb. Receive a documented acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the system;\nc. Review and update the rules of behavior at least annually ; and\nd. Require individuals who have acknowledged a previous version of the rules of behavior to read and re-acknowledge at least annually and when the rules are revised or changed.\ncontrols PL-4(1) Social Media and External Site/Application Usage Restrictions\nInclude in the rules of behavior, restrictions on:\n(a) Use of social media, social networking sites, and external sites/applications;\n(b) Posting organizational information on public websites; and\n(c) Use of organization-provided identifiers (e.g., email addresses) and authentication secrets (e.g., passwords) for creating accounts on external sites/applications.", + "guidance": "Rules of behavior represent a type of access agreement for organizational users. Other types of access agreements include nondisclosure agreements, conflict-of-interest agreements, and acceptable use agreements (see [PS-6] ). Organizations consider rules of behavior based on individual user roles and responsibilities and differentiate between rules that apply to privileged users and rules that apply to general users. Establishing rules of behavior for some types of non-organizational users, including individuals who receive information from federal systems, is often not feasible given the large number of such users and the limited nature of their interactions with the systems. Rules of behavior for organizational and non-organizational users can also be established in [AC-8] . The related controls section provides a list of controls that are relevant to organizational rules of behavior. [PL-4b] , the documented acknowledgment portion of the control, may be satisfied by the literacy training and awareness and role-based training programs conducted by organizations if such training includes rules of behavior. Documented acknowledgements for rules of behavior include electronic or physical signatures and electronic agreement check boxes or radio buttons." + }, + { + "ref": "PL-8", + "title": "Security and Privacy Architectures", + "summary": "Security and Privacy Architectures\na. Develop security and privacy architectures for the system that:\n1. Describe the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information;\n2. Describe the requirements and approach to be taken for processing personally identifiable information to minimize privacy risk to individuals;\n3. Describe how the architectures are integrated into and support the enterprise architecture; and\n4. Describe any assumptions about, and dependencies on, external systems and services;\nb. Review and update the architectures at least annually and when a significant change occurs to reflect changes in the enterprise architecture; and\nc. Reflect planned architecture changes in security and privacy plans, Concept of Operations (CONOPS), criticality analysis, organizational procedures, and procurements and acquisitions.\nPL-8 Additional FedRAMP Requirements and Guidance ", + "guidance": "The security and privacy architectures at the system level are consistent with the organization-wide security and privacy architectures described in [PM-7] , which are integral to and developed as part of the enterprise architecture. The architectures include an architectural description, the allocation of security and privacy functionality (including controls), security- and privacy-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. The architectures can also include other information, such as user roles and the access privileges assigned to each role; security and privacy requirements; types of information processed, stored, and transmitted by the system; supply chain risk management requirements; restoration priorities of information and system services; and other protection needs.\n\n [SP 800-160-1] provides guidance on the use of security architectures as part of the system development life cycle process. [OMB M-19-03] requires the use of the systems security engineering concepts described in [SP 800-160-1] for high value assets. Security and privacy architectures are reviewed and updated throughout the system development life cycle, from analysis of alternatives through review of the proposed architecture in the RFP responses to the design reviews before and during implementation (e.g., during preliminary design reviews and critical design reviews).\n\nIn today\u2019s modern computing architectures, it is becoming less common for organizations to control all information resources. There may be key dependencies on external information services and service providers. Describing such dependencies in the security and privacy architectures is necessary for developing a comprehensive mission and business protection strategy. Establishing, developing, documenting, and maintaining under configuration control a baseline configuration for organizational systems is critical to implementing and maintaining effective architectures. The development of the architectures is coordinated with the senior agency information security officer and the senior agency official for privacy to ensure that the controls needed to support security and privacy requirements are identified and effectively implemented. In many circumstances, there may be no distinction between the security and privacy architecture for a system. In other circumstances, security objectives may be adequately satisfied, but privacy objectives may only be partially satisfied by the security requirements. In these cases, consideration of the privacy requirements needed to achieve satisfaction will result in a distinct privacy architecture. The documentation, however, may simply reflect the combined architectures.\n\n [PL-8] is primarily directed at organizations to ensure that architectures are developed for the system and, moreover, that the architectures are integrated with or tightly coupled to the enterprise architecture. In contrast, [SA-17] is primarily directed at the external information technology product and system developers and integrators. [SA-17] , which is complementary to [PL-8] , is selected when organizations outsource the development of systems or components to external entities and when there is a need to demonstrate consistency with the organization\u2019s enterprise architecture and security and privacy architectures." + }, + { + "ref": "PL-10", + "title": "Baseline Selection", + "summary": "Baseline Selection\nSelect a control baseline for the system.\nPL-10 Additional FedRAMP Requirements and Guidance Requirement: Select the appropriate FedRAMP Baseline", + "guidance": "Control baselines are predefined sets of controls specifically assembled to address the protection needs of a group, organization, or community of interest. Controls are chosen for baselines to either satisfy mandates imposed by laws, executive orders, directives, regulations, policies, standards, and guidelines or address threats common to all users of the baseline under the assumptions specific to the baseline. Baselines represent a starting point for the protection of individuals\u2019 privacy, information, and information systems with subsequent tailoring actions to manage risk in accordance with mission, business, or other constraints (see [PL-11] ). Federal control baselines are provided in [SP 800-53B] . The selection of a control baseline is determined by the needs of stakeholders. Stakeholder needs consider mission and business requirements as well as mandates imposed by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. For example, the control baselines in [SP 800-53B] are based on the requirements from [FISMA] and [PRIVACT] . The requirements, along with the NIST standards and guidelines implementing the legislation, direct organizations to select one of the control baselines after the reviewing the information types and the information that is processed, stored, and transmitted on the system; analyzing the potential adverse impact of the loss or compromise of the information or system on the organization\u2019s operations and assets, individuals, other organizations, or the Nation; and considering the results from system and organizational risk assessments. [CNSSI 1253] provides guidance on control baselines for national security systems." + }, + { + "ref": "PL-11", + "title": "Baseline Tailoring", + "summary": "Baseline Tailoring\nTailor the selected control baseline by applying specified tailoring actions.", + "guidance": "The concept of tailoring allows organizations to specialize or customize a set of baseline controls by applying a defined set of tailoring actions. Tailoring actions facilitate such specialization and customization by allowing organizations to develop security and privacy plans that reflect their specific mission and business functions, the environments where their systems operate, the threats and vulnerabilities that can affect their systems, and any other conditions or situations that can impact their mission or business success. Tailoring guidance is provided in [SP 800-53B] . Tailoring a control baseline is accomplished by identifying and designating common controls, applying scoping considerations, selecting compensating controls, assigning values to control parameters, supplementing the control baseline with additional controls as needed, and providing information for control implementation. The general tailoring actions in [SP 800-53B] can be supplemented with additional actions based on the needs of organizations. Tailoring actions can be applied to the baselines in [SP 800-53B] in accordance with the security and privacy requirements from [FISMA], [PRIVACT] , and [OMB A-130] . Alternatively, other communities of interest adopting different control baselines can apply the tailoring actions in [SP 800-53B] to specialize or customize the controls that represent the specific needs and concerns of those entities." + } + ] + }, + { + "title": "Personnel Security", + "controls": [ + { + "ref": "PS-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} personnel security policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the personnel security policy and the associated personnel security controls;\nb. Designate an {{ official - an official to manage the personnel security policy and procedures is defined; }} to manage the development, documentation, and dissemination of the personnel security policy and procedures; and\nc. Review and update the current personnel security:\n1. Policy at least annually and following {{ events - events that would require the current personnel security policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Personnel security policy and procedures for the controls in the PS family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to personnel security policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PS-2", + "title": "Position Risk Designation", + "summary": "Position Risk Designation\na. Assign a risk designation to all organizational positions;\nb. Establish screening criteria for individuals filling those positions; and\nc. Review and update position risk designations at least annually.", + "guidance": "Position risk designations reflect Office of Personnel Management (OPM) policy and guidance. Proper position designation is the foundation of an effective and consistent suitability and personnel security program. The Position Designation System (PDS) assesses the duties and responsibilities of a position to determine the degree of potential damage to the efficiency or integrity of the service due to misconduct of an incumbent of a position and establishes the risk level of that position. The PDS assessment also determines if the duties and responsibilities of the position present the potential for position incumbents to bring about a material adverse effect on national security and the degree of that potential effect, which establishes the sensitivity level of a position. The results of the assessment determine what level of investigation is conducted for a position. Risk designations can guide and inform the types of authorizations that individuals receive when accessing organizational information and information systems. Position screening criteria include explicit information security role appointment requirements. Parts 1400 and 731 of Title 5, Code of Federal Regulations, establish the requirements for organizations to evaluate relevant covered positions for a position sensitivity and position risk designation commensurate with the duties and responsibilities of those positions." + }, + { + "ref": "PS-3", + "title": "Personnel Screening", + "summary": "Personnel Screening\na. Screen individuals prior to authorizing access to the system; and\nb. Rescreen individuals in accordance with for national security clearances; a reinvestigation is required during the fifth (5th) year for top secret security clearance, the tenth (10th) year for secret security clearance, and fifteenth (15th) year for confidential security clearance.\n\nFor moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the fifth (5th) year. There is no reinvestigation for other moderate risk positions or any low risk positions.\ncontrols PS-3(3) Information Requiring Special Protective Measures\nVerify that individuals accessing a system processing, storing, or transmitting information requiring special protection:\n(a) Have valid access authorizations that are demonstrated by assigned official government duties; and\n(b) Satisfy personnel screening criteria \u2013 as required by specific information.", + "guidance": "Personnel screening and rescreening activities reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, and specific criteria established for the risk designations of assigned positions. Examples of personnel screening include background investigations and agency checks. Organizations may define different rescreening conditions and frequencies for personnel accessing systems based on types of information processed, stored, or transmitted by the systems." + }, + { + "ref": "PS-4", + "title": "Personnel Termination", + "summary": "Personnel Termination\nUpon termination of individual employment:\na. Disable system access within one (1) hour;\nb. Terminate or revoke any authenticators and credentials associated with the individual;\nc. Conduct exit interviews that include a discussion of {{ information security topics - information security topics to be discussed when conducting exit interviews are defined; }};\nd. Retrieve all security-related organizational system-related property; and\ne. Retain access to organizational information and systems formerly controlled by terminated individual.\ncontrols PS-4(2) Automated Actions\nUse {{ automated mechanisms - automated mechanisms to notify personnel or roles of individual termination actions and/or to disable access to system resources are defined; }} to access control personnel responsible for disabling access to the system.", + "guidance": "System property includes hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that proper accountability is achieved for system-related property. Security topics at exit interviews include reminding individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not always be possible for some individuals, including in cases related to the unavailability of supervisors, illnesses, or job abandonment. Exit interviews are important for individuals with security clearances. The timely execution of termination actions is essential for individuals who have been terminated for cause. In certain situations, organizations consider disabling the system accounts of individuals who are being terminated prior to the individuals being notified." + }, + { + "ref": "PS-5", + "title": "Personnel Transfer", + "summary": "Personnel Transfer\na. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization;\nb. Initiate {{ transfer or reassignment actions - transfer or reassignment actions to be initiated following transfer or reassignment are defined; }} within twenty-four (24) hours;\nc. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and\nd. Notify including access control personnel responsible for the system within twenty-four (24) hours.", + "guidance": "Personnel transfer applies when reassignments or transfers of individuals are permanent or of such extended duration as to make the actions warranted. Organizations define actions appropriate for the types of reassignments or transfers, whether permanent or extended. Actions that may be required for personnel transfers or reassignments to other positions within organizations include returning old and issuing new keys, identification cards, and building passes; closing system accounts and establishing new accounts; changing system access authorizations (i.e., privileges); and providing for access to official records to which individuals had access at previous work locations and in previous system accounts." + }, + { + "ref": "PS-6", + "title": "Access Agreements", + "summary": "Access Agreements\na. Develop and document access agreements for organizational systems;\nb. Review and update the access agreements at least annually ; and\nc. Verify that individuals requiring access to organizational information and systems:\n1. Sign appropriate access agreements prior to being granted access; and\n2. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated or at least annually and any time there is a change to the user's level of access.", + "guidance": "Access agreements include nondisclosure agreements, acceptable use agreements, rules of behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with organizational systems to which access is authorized. Organizations can use electronic signatures to acknowledge access agreements unless specifically prohibited by organizational policy." + }, + { + "ref": "PS-7", + "title": "External Personnel Security", + "summary": "External Personnel Security\na. Establish personnel security requirements, including security roles and responsibilities for external providers;\nb. Require external providers to comply with personnel security policies and procedures established by the organization;\nc. Document personnel security requirements;\nd. Require external providers to notify including access control personnel responsible for the system and/or facilities, as appropriate of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within terminations: immediately; transfers: within twenty-four (24) hours ; and\ne. Monitor provider compliance with personnel security requirements.", + "guidance": "External provider refers to organizations other than the organization operating or acquiring the system. External providers include service bureaus, contractors, and other organizations that provide system development, information technology services, testing or assessment services, outsourced applications, and network/security management. Organizations explicitly include personnel security requirements in acquisition-related documents. External providers may have personnel working at organizational facilities with credentials, badges, or system privileges issued by organizations. Notifications of external personnel changes ensure the appropriate termination of privileges and credentials. Organizations define the transfers and terminations deemed reportable by security-related characteristics that include functions, roles, and the nature of credentials or privileges associated with transferred or terminated individuals." + }, + { + "ref": "PS-8", + "title": "Personnel Sanctions", + "summary": "Personnel Sanctions\na. Employ a formal sanctions process for individuals failing to comply with established information security and privacy policies and procedures; and\nb. Notify to include the ISSO and/or similar role within the organization within 24 hours when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction.", + "guidance": "Organizational sanctions reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Sanctions processes are described in access agreements and can be included as part of general personnel policies for organizations and/or specified in security and privacy policies. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions." + }, + { + "ref": "PS-9", + "title": "Position Descriptions", + "summary": "Position Descriptions\nIncorporate security and privacy roles and responsibilities into organizational position descriptions.", + "guidance": "Specification of security and privacy roles in individual organizational position descriptions facilitates clarity in understanding the security or privacy responsibilities associated with the roles and the role-based security and privacy training requirements for the roles." + } + ] + }, + { + "title": "Risk Assessment", + "controls": [ + { + "ref": "RA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} risk assessment policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the risk assessment policy and the associated risk assessment controls;\nb. Designate an {{ official - an official to manage the risk assessment policy and procedures is defined; }} to manage the development, documentation, and dissemination of the risk assessment policy and procedures; and\nc. Review and update the current risk assessment:\n1. Policy at least annually and following {{ events - events that would require the current risk assessment policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Risk assessment policy and procedures address the controls in the RA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of risk assessment policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to risk assessment policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "RA-2", + "title": "Security Categorization", + "summary": "Security Categorization\na. Categorize the system and information it processes, stores, and transmits;\nb. Document the security categorization results, including supporting rationale, in the security plan for the system; and\nc. Verify that the authorizing official or authorizing official designated representative reviews and approves the security categorization decision.", + "guidance": "Security categories describe the potential adverse impacts or negative consequences to organizational operations, organizational assets, and individuals if organizational information and systems are compromised through a loss of confidentiality, integrity, or availability. Security categorization is also a type of asset loss characterization in systems security engineering processes that is carried out throughout the system development life cycle. Organizations can use privacy risk assessments or privacy impact assessments to better understand the potential adverse effects on individuals. [CNSSI 1253] provides additional guidance on categorization for national security systems.\n\nOrganizations conduct the security categorization process as an organization-wide activity with the direct involvement of chief information officers, senior agency information security officers, senior agency officials for privacy, system owners, mission and business owners, and information owners or stewards. Organizations consider the potential adverse impacts to other organizations and, in accordance with [USA PATRIOT] and Homeland Security Presidential Directives, potential national-level adverse impacts.\n\nSecurity categorization processes facilitate the development of inventories of information assets and, along with [CM-8] , mappings to specific system components where information is processed, stored, or transmitted. The security categorization process is revisited throughout the system development life cycle to ensure that the security categories remain accurate and relevant." + }, + { + "ref": "RA-3", + "title": "Risk Assessment", + "summary": "Risk Assessment\na. Conduct a risk assessment, including:\n1. Identifying threats to and vulnerabilities in the system;\n2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and\n3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;\nb. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments;\nc. Document risk assessment results in security assessment report;\nd. Review risk assessment results at least annually and whenever a significant change occurs;\ne. Disseminate risk assessment results to {{ personnel or roles - personnel or roles to whom risk assessment results are to be disseminated is/are defined; }} ; and\nf. Update the risk assessment annually or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.\nRA-3 Additional FedRAMP Requirements and Guidance (e) Requirement: Include all Authorizing Officials; for JAB authorizations to include FedRAMP.\ncontrols RA-3(1) Supply Chain Risk Assessment\n(a) Assess supply chain risks associated with {{ systems, system components, and system services - systems, system components, and system services to assess supply chain risks are defined; }} ; and\n(b) Update the supply chain risk assessment {{ frequency - the frequency at which to update the supply chain risk assessment is defined; }} , when there are significant changes to the relevant supply chain, or when changes to the system, environments of operation, or other conditions may necessitate a change in the supply chain.", + "guidance": "Risk assessments consider threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation. Risk assessments also consider risk from external parties, including contractors who operate systems on behalf of the organization, individuals who access organizational systems, service providers, and outsourcing entities.\n\nOrganizations can conduct risk assessments at all three levels in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any stage in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including preparation, categorization, control selection, control implementation, control assessment, authorization, and control monitoring. Risk assessment is an ongoing activity carried out throughout the system development life cycle.\n\nRisk assessments can also address information related to the system, including system design, the intended use of the system, testing results, and supply chain-related information or artifacts. Risk assessments can play an important role in control selection processes, particularly during the application of tailoring guidance and in the earliest phases of capability determination." + }, + { + "ref": "RA-5", + "title": "Vulnerability Monitoring and Scanning", + "summary": "Vulnerability Monitoring and Scanning\na. Monitor and scan for vulnerabilities in the system and hosted applications monthly operating system/infrastructure; monthly web applications (including APIs) and databases and when new vulnerabilities potentially affecting the system are identified and reported;\nb. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n1. Enumerating platforms, software flaws, and improper configurations;\n2. Formatting checklists and test procedures; and\n3. Measuring vulnerability impact;\nc. Analyze vulnerability scan reports and results from vulnerability monitoring;\nd. Remediate legitimate vulnerabilities high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery in accordance with an organizational assessment of risk;\ne. Share information obtained from the vulnerability monitoring process and control assessments with {{ personnel or roles - personnel or roles with whom information obtained from the vulnerability scanning process and control assessments is to be shared; }} to help eliminate similar vulnerabilities in other systems; and\nf. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.\nRA-5 Additional FedRAMP Requirements and Guidance (a) Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.\n(d) Requirement: If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.\n(e) Requirement: to include all Authorizing Officials; for JAB authorizations to include FedRAMP\ncontrols RA-5(2) Update Vulnerabilities to Be Scanned\nUpdate the system vulnerabilities to be scanned within 24 hours prior to running scans.\nRA-5(3) Breadth and Depth of Coverage\nDefine the breadth and depth of vulnerability scanning coverage.\nRA-5(4) Discoverable Information\nDetermine information about the system that is discoverable and take notify appropriate service provider personnel and follow procedures for organization and service provider-defined corrective actions.\nRA-5(5) Privileged Access\nImplement privileged access authorization to all components that support authentication for all scans.\nRA-5(8) Review Historic Audit Logs\nReview historic audit logs to determine if a vulnerability identified in a {{ system - a system whose historic audit logs are to be reviewed is defined; }} has been previously exploited within an {{ time period - a time period for a potential previous exploit of a system is defined; }}.\nRA-5(8) Additional FedRAMP Requirement Requirement: This enhancement is required for all high (or critical) vulnerability scan findings.\nRA-5(11) Public Disclosure Program\nEstablish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components.", + "guidance": "Security categorization of information and systems guides the frequency and comprehensiveness of vulnerability monitoring (including scans). Organizations determine the required vulnerability monitoring for system components, ensuring that the potential sources of vulnerabilities\u2014such as infrastructure components (e.g., switches, routers, guards, sensors), networked printers, scanners, and copiers\u2014are not overlooked. The capability to readily update vulnerability monitoring tools as new vulnerabilities are discovered and announced and as new scanning methods are developed helps to ensure that new vulnerabilities are not missed by employed vulnerability monitoring tools. The vulnerability monitoring tool update process helps to ensure that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability monitoring and analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can use these analysis approaches in source code reviews and in a variety of tools, including web-based application scanners, static analysis tools, and binary analyzers.\n\nVulnerability monitoring includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for flow control mechanisms that are improperly configured or operating incorrectly. Vulnerability monitoring may also include continuous vulnerability monitoring tools that use instrumentation to continuously analyze components. Instrumentation-based tools may improve accuracy and may be run throughout an organization without scanning. Vulnerability monitoring tools that facilitate interoperability include tools that are Security Content Automated Protocol (SCAP)-validated. Thus, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Control assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan. Organizations also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS).\n\nVulnerability monitoring includes a channel and process for receiving reports of security vulnerabilities from the public at-large. Vulnerability disclosure programs can be as simple as publishing a monitored email address or web form that can receive reports, including notification authorizing good-faith research and disclosure of security vulnerabilities. Organizations generally expect that such research is happening with or without their authorization and can use public vulnerability disclosure channels to increase the likelihood that discovered vulnerabilities are reported directly to the organization for remediation.\n\nOrganizations may also employ the use of financial incentives (also known as \"bug bounties\" ) to further encourage external security researchers to report discovered vulnerabilities. Bug bounty programs can be tailored to the organization\u2019s needs. Bounties can be operated indefinitely or over a defined period of time and can be offered to the general public or to a curated group. Organizations may run public and private bounties simultaneously and could choose to offer partially credentialed access to certain participants in order to evaluate security vulnerabilities from privileged vantage points." + }, + { + "ref": "RA-7", + "title": "Risk Response", + "summary": "Risk Response\nRespond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance.", + "guidance": "Organizations have many options for responding to risk including mitigating risk by implementing new controls or strengthening existing controls, accepting risk with appropriate justification or rationale, sharing or transferring risk, or avoiding risk. The risk tolerance of the organization influences risk response decisions and actions. Risk response addresses the need to determine an appropriate response to risk before generating a plan of action and milestones entry. For example, the response may be to accept risk or reject risk, or it may be possible to mitigate the risk immediately so that a plan of action and milestones entry is not needed. However, if the risk response is to mitigate the risk, and the mitigation cannot be completed immediately, a plan of action and milestones entry is generated." + }, + { + "ref": "RA-9", + "title": "Criticality Analysis", + "summary": "Criticality Analysis\nIdentify critical system components and functions by performing a criticality analysis for {{ systems, system components, or system services - systems, system components, or system services to be analyzed for criticality are defined; }} at {{ decision points in the system development life cycle - decision points in the system development life cycle when a criticality analysis is to be performed are defined; }}.", + "guidance": "Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, executive orders, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and external to the system.\n\nThe operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber-physical systems, devices, system-of-systems, and outsourced IT services. System components that allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.\n\nCriticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design. Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in [RA-2]." + } + ] + }, + { + "title": "System and Services Acquisition", + "controls": [ + { + "ref": "SA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} system and services acquisition policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;\nb. Designate an {{ official - an official to manage the system and services acquisition policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and\nc. Review and update the current system and services acquisition:\n1. Policy at least annually and following {{ events - events that would require the current system and services acquisition policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SA-2", + "title": "Allocation of Resources", + "summary": "Allocation of Resources\na. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;\nb. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and\nc. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.", + "guidance": "Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle." + }, + { + "ref": "SA-3", + "title": "System Development Life Cycle", + "summary": "System Development Life Cycle\na. Acquire, develop, and manage the system using {{ system-development life cycle - system development life cycle is defined; }} that incorporates information security and privacy considerations;\nb. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;\nc. Identify individuals having information security and privacy roles and responsibilities; and\nd. Integrate the organizational information security and privacy risk management process into system development life cycle activities.", + "guidance": "A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in [SA-8] help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.\n\nThe effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle." + }, + { + "ref": "SA-4", + "title": "Acquisition Process", + "summary": "Acquisition Process\nInclude the following requirements, descriptions, and criteria, explicitly or by reference, using {{ one or more: standardized contract language, {{ contract language - contract language is defined (if selected); }} }} in the acquisition contract for the system, system component, or system service:\na. Security and privacy functional requirements;\nb. Strength of mechanism requirements;\nc. Security and privacy assurance requirements;\nd. Controls needed to satisfy the security and privacy requirements.\ne. Security and privacy documentation requirements;\nf. Requirements for protecting security and privacy documentation;\ng. Description of the system development environment and environment in which the system is intended to operate;\nh. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and\ni. Acceptance criteria.\nSA-4 Additional FedRAMP Requirements and Guidance Requirement: The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).\ncontrols SA-4(1) Functional Properties of Controls\nRequire the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.\nSA-4(2) Design and Implementation Information for Controls\nRequire the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: at a minimum to include security-relevant external system interfaces; high-level design; low-level design; source code or network and data flow diagram;\n\norganization-defined design/implementation information at {{ level of detail - level of detail is defined; }}.\nSA-4(5) System, Component, and Service Configurations\nRequire the developer of the system, system component, or system service to:\n(a) Deliver the system, component, or service with The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available. implemented; and\n(b) Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.\nSA-4(9) Functions, Ports, Protocols, and Services in Use\nRequire the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.\nSA-4(10) Use of Approved PIV Products\nEmploy only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.", + "guidance": "Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in [SA-2] . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1] describes the process of requirements engineering as part of the system development life cycle.\n\nControls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle.\n\nSecurity and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement." + }, + { + "ref": "SA-5", + "title": "System Documentation", + "summary": "System Documentation\na. Obtain or develop administrator documentation for the system, system component, or system service that describes:\n1. Secure configuration, installation, and operation of the system, component, or service;\n2. Effective use and maintenance of security and privacy functions and mechanisms; and\n3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;\nb. Obtain or develop user documentation for the system, system component, or system service that describes:\n1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;\n2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and\n3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;\nc. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take {{ actions - actions to take when system, system component, or system service documentation is either unavailable or nonexistent are defined; }} in response; and\nd. Distribute documentation to at a minimum, the ISSO (or similar role within the organization).", + "guidance": "System documentation helps personnel understand the implementation and operation of controls. Organizations consider establishing specific measures to determine the quality and completeness of the content provided. System documentation may be used to support the management of supply chain risk, incident response, and other functions. Personnel or roles that require documentation include system owners, system security officers, and system administrators. Attempts to obtain documentation include contacting manufacturers or suppliers and conducting web-based searches. The inability to obtain documentation may occur due to the age of the system or component or the lack of support from developers and contractors. When documentation cannot be obtained, organizations may need to recreate the documentation if it is essential to the implementation or operation of the controls. The protection provided for the documentation is commensurate with the security category or classification of the system. Documentation that addresses system vulnerabilities may require an increased level of protection. Secure operation of the system includes initially starting the system and resuming secure system operation after a lapse in system operation." + }, + { + "ref": "SA-8", + "title": "Security and Privacy Engineering Principles", + "summary": "Security and Privacy Engineering Principles\nApply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: {{ organization-defined systems security and privacy engineering principles }}.", + "guidance": "Systems security and privacy engineering principles are closely related to and implemented throughout the system development life cycle (see [SA-3] ). Organizations can apply systems security and privacy engineering principles to new systems under development or to systems undergoing upgrades. For existing systems, organizations apply systems security and privacy engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems.\n\nThe application of systems security and privacy engineering principles helps organizations develop trustworthy, secure, and resilient systems and reduces the susceptibility to disruptions, hazards, threats, and the creation of privacy problems for individuals. Examples of system security engineering principles include: developing layered protections; establishing security and privacy policies, architecture, and controls as the foundation for design and development; incorporating security and privacy requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; tailoring controls to meet organizational needs; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk.\n\nOrganizations that apply systems security and privacy engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk management decisions. System security engineering principles can also be used to protect against certain supply chain risks, including incorporating tamper-resistant hardware into a design." + }, + { + "ref": "SA-9", + "title": "External System Services", + "summary": "External System Services\na. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: Appropriate FedRAMP Security Controls Baseline (s) if Federal information is processed or stored within the external system;\nb. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and\nc. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored.\ncontrols SA-9(1) Risk Assessments and Organizational Approvals\n(a) Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and\n(b) Verify that the acquisition or outsourcing of dedicated information security services is approved by {{ personnel or roles - personnel or roles that approve the acquisition or outsourcing of dedicated information security services is/are defined; }}.\nSA-9(2) Identification of Functions, Ports, Protocols, and Services\nRequire providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: all external systems where Federal information is processed or stored.\nSA-9(5) Processing, Storage, and Service Location\nRestrict the location of information processing, information or data, AND system services to U.S./U.S. Territories or geographic locations where there is U.S. jurisdiction based on all High impact data, systems, or services.", + "guidance": "External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust vary based on relationships between organizations and the external providers. Organizations document the basis for the trust relationships so that the relationships can be monitored. External system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define the expectations of performance for implemented controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance." + }, + { + "ref": "SA-10", + "title": "Developer Configuration Management", + "summary": "Developer Configuration Management\nRequire the developer of the system, system component, or system service to:\na. Perform configuration management during system, component, or service development, implementation, AND operation;\nb. Document, manage, and control the integrity of changes to {{ configuration items - configuration items under configuration management are defined; }};\nc. Implement only organization-approved changes to the system, component, or service;\nd. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and\ne. Track security flaws and flaw resolution within the system, component, or service and report findings to {{ personnel - personnel to whom security flaws and flaw resolutions within the system, component, or service are reported is/are defined; }}.\nSA-10 Additional FedRAMP Requirements and Guidance (e) Requirement: track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP.", + "guidance": "Organizations consider the quality and completeness of configuration management activities conducted by developers as direct evidence of applying effective security controls. Controls include protecting the master copies of material used to generate security-relevant portions of the system hardware, software, and firmware from unauthorized modification or destruction. Maintaining the integrity of changes to the system, system component, or system service requires strict configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.\n\nThe configuration items that are placed under configuration management include the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the current running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and source code with previous versions; and test fixtures and documentation. Depending on the mission and business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance stage of the system development life cycle." + }, + { + "ref": "SA-11", + "title": "Developer Testing and Evaluation", + "summary": "Developer Testing and Evaluation\nRequire the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:\na. Develop and implement a plan for ongoing security and privacy control assessments;\nb. Perform {{ one or more: unit, integration, system, regression }} testing/evaluation {{ frequency to conduct - frequency at which to conduct {{ one or more: unit, integration, system, regression }} testing/evaluation is defined; }} at {{ depth and coverage - depth and coverage of {{ one or more: unit, integration, system, regression }} testing/evaluation is defined; }};\nc. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;\nd. Implement a verifiable flaw remediation process; and\ne. Correct flaws identified during testing and evaluation.\ncontrols SA-11(1) Static Code Analysis\nRequire the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.\nSA-11(1) Additional FedRAMP Requirements Requirement: The service provider must document its methodology for reviewing newly developed code for the Service in its Continuous Monitoring Plan.\n\nIf Static code analysis cannot be performed (for example, when the source code is not available), then dynamic code analysis must be performed (see SA-11 (8))\nSA-11(2) Threat Modeling and Vulnerability Analyses\nRequire the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that:\n(a) Uses the following contextual information: {{ information - information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels to be used as contextual information for threat modeling and vulnerability analyses is defined; }};\n(b) Employs the following tools and methods: {{ tools and methods - the tools and methods to be employed for threat modeling and vulnerability analyses are defined; }};\n(c) Conducts the modeling and analyses at the following level of rigor: {{ organization-defined breadth and depth of modeling and analyses }} ; and\n(d) Produces evidence that meets the following acceptance criteria: {{ organization-defined acceptance criteria }}.", + "guidance": "Developmental testing and evaluation confirms that the required controls are implemented correctly, operating as intended, enforcing the desired security and privacy policies, and meeting established security and privacy requirements. Security properties of systems and the privacy of individuals may be affected by the interconnection of system components or changes to those components. The interconnections or changes\u2014including upgrading or replacing applications, operating systems, and firmware\u2014may adversely affect previously implemented controls. Ongoing assessment during development allows for additional types of testing and evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as manual code review, security architecture review, and penetration testing, as well as and static analysis, dynamic analysis, binary analysis, or a hybrid of the three analysis approaches.\n\nDevelopers can use the analysis approaches, along with security instrumentation and fuzzing, in a variety of tools and in source code reviews. The security and privacy assessment plans include the specific activities that developers plan to carry out, including the types of analyses, testing, evaluation, and reviews of software and firmware components; the degree of rigor to be applied; the frequency of the ongoing testing and evaluation; and the types of artifacts produced during those processes. The depth of testing and evaluation refers to the rigor and level of detail associated with the assessment process. The coverage of testing and evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security and privacy assessment plans, flaw remediation processes, and the evidence that the plans and processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the system. Contracts may specify protection requirements for documentation." + }, + { + "ref": "SA-15", + "title": "Development Process, Standards, and Tools", + "summary": "Development Process, Standards, and Tools\na. Require the developer of the system, system component, or system service to follow a documented development process that:\n1. Explicitly addresses security and privacy requirements;\n2. Identifies the standards and tools used in the development process;\n3. Documents the specific tool options and tool configurations used in the development process; and\n4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and\nb. Review the development process, standards, tools, tool options, and tool configurations frequency as before first use and annually thereafter to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: {{ organization-defined security and privacy requirements }}.\ncontrols SA-15(3) Criticality Analysis\nRequire the developer of the system, system component, or system service to perform a criticality analysis:\n(a) At the following decision points in the system development life cycle: {{ decision points - decision points in the system development life cycle are defined; }} ; and\n(b) At the following level of rigor: {{ organization-defined breadth and depth of criticality analysis }}.", + "guidance": "Development tools include programming languages and computer-aided design systems. Reviews of development processes include the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes facilitates effective supply chain risk assessment and mitigation. Such integrity requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes." + }, + { + "ref": "SA-16", + "title": "Developer-provided Training", + "summary": "Developer-provided Training\nRequire the developer of the system, system component, or system service to provide the following training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms: {{ training - training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms provided by the developer of the system, system component, or system service is defined; }}.", + "guidance": "Developer-provided training applies to external and internal (in-house) developers. Training personnel is essential to ensuring the effectiveness of the controls implemented within organizational systems. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Organizations can also request training materials from developers to conduct in-house training or offer self-training to organizational personnel. Organizations determine the type of training necessary and may require different types of training for different security and privacy functions, controls, and mechanisms." + }, + { + "ref": "SA-17", + "title": "Developer Security and Privacy Architecture and Design", + "summary": "Developer Security and Privacy Architecture and Design\nRequire the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:\na. Is consistent with the organization\u2019s security and privacy architecture that is an integral part the organization\u2019s enterprise architecture;\nb. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and\nc. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.", + "guidance": "Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, [PL-8] is directed at internal developers to ensure that organizations develop a security and privacy architecture that is integrated with the enterprise architecture. The distinction between SA-17 and [PL-8] is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. [ISO 15408-2], [ISO 15408-3] , and [SP 800-160-1] provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing." + }, + { + "ref": "SA-21", + "title": "Developer Screening", + "summary": "Developer Screening\nRequire that the developer of {{ system, systems component, or system service - the system, systems component, or system service that the developer has access to is/are defined; }}:\na. Has appropriate access authorizations as determined by assigned {{ official government duties - official government duties assigned to the developer are defined; }} ; and\nb. Satisfies the following additional personnel screening criteria: {{ additional personnel screening criteria - additional personnel screening criteria for the developer are defined; }}.", + "guidance": "Developer screening is directed at external developers. Internal developer screening is addressed by [PS-3] . Because the system, system component, or system service may be used in critical activities essential to the national or economic security interests of the United States, organizations have a strong interest in ensuring that developers are trustworthy. The degree of trust required of developers may need to be consistent with that of the individuals who access the systems, system components, or system services once deployed. Authorization and personnel screening criteria include clearances, background checks, citizenship, and nationality. Developer trustworthiness may also include a review and analysis of company ownership and relationships that the company has with entities that may potentially affect the quality and reliability of the systems, components, or services being developed. Satisfying the required access authorizations and personnel screening criteria includes providing a list of all individuals who are authorized to perform development activities on the selected system, system component, or system service so that organizations can validate that the developer has satisfied the authorization and screening requirements." + }, + { + "ref": "SA-22", + "title": "Unsupported System Components", + "summary": "Unsupported System Components\na. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or\nb. Provide the following options for alternative sources for continued support for unsupported components {{ one or more: in-house support, {{ support from external providers - support from external providers is defined (if selected); }} }}.", + "guidance": "Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option.\n\nAlternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation." + } + ] + }, + { + "title": "System and Communications Protection", + "controls": [ + { + "ref": "SC-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business-process-level, system-level }} system and communications protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls;\nb. Designate an {{ official - an official to manage the system and communications protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and\nc. Review and update the current system and communications protection:\n1. Policy at least annually and following {{ events - events that would require the current system and communications protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and communications protection policy and procedures address the controls in the SC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and communications protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and communications protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SC-2", + "title": "Separation of System and User Functionality", + "summary": "Separation of System and User Functionality\nSeparate user functionality, including user interface services, from system management functionality.", + "guidance": "System management functionality includes functions that are necessary to administer databases, network components, workstations, or servers. These functions typically require privileged user access. The separation of user functions from system management functions is physical or logical. Organizations may separate system management functions from user functions by using different computers, instances of operating systems, central processing units, or network addresses; by employing virtualization techniques; or some combination of these or other methods. Separation of system management functions from user functions includes web administrative interfaces that employ separate authentication methods for users of any other system resources. Separation of system and user functions may include isolating administrative interfaces on different domains and with additional access controls. The separation of system and user functionality can be achieved by applying the systems security engineering design principles in [SA-8] , including [SA-8(1)], [SA-8(3)], [SA-8(4)], [SA-8(10)], [SA-8(12)], [SA-8(13)], [SA-8(14)] , and [SA-8(18)]." + }, + { + "ref": "SC-3", + "title": "Security Function Isolation", + "summary": "Security Function Isolation\nIsolate security functions from nonsecurity functions.", + "guidance": "Security functions are isolated from nonsecurity functions by means of an isolation boundary implemented within a system via partitions and domains. The isolation boundary controls access to and protects the integrity of the hardware, software, and firmware that perform system security functions. Systems implement code separation in many ways, such as through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that protect the code on disk and address space protections that protect executing code. Systems can restrict access to security functions using access control mechanisms and by implementing least privilege capabilities. While the ideal is for all code within the defined security function isolation boundary to only contain security-relevant code, it is sometimes necessary to include nonsecurity functions as an exception. The isolation of security functions from nonsecurity functions can be achieved by applying the systems security engineering design principles in [SA-8] , including [SA-8(1)], [SA-8(3)], [SA-8(4)], [SA-8(10)], [SA-8(12)], [SA-8(13)], [SA-8(14)] , and [SA-8(18)]." + }, + { + "ref": "SC-4", + "title": "Information in Shared System Resources", + "summary": "Information in Shared System Resources\nPrevent unauthorized and unintended information transfer via shared system resources.", + "guidance": "Preventing unauthorized and unintended information transfer via shared system resources stops information produced by the actions of prior users or roles (or the actions of processes acting on behalf of prior users or roles) from being available to current users or roles (or current processes acting on behalf of current users or roles) that obtain access to shared system resources after those resources have been released back to the system. Information in shared system resources also applies to encrypted representations of information. In other contexts, control of information in shared system resources is referred to as object reuse and residual information protection. Information in shared system resources does not address information remanence, which refers to the residual representation of data that has been nominally deleted; covert channels (including storage and timing channels), where shared system resources are manipulated to violate information flow restrictions; or components within systems for which there are only single users or roles." + }, + { + "ref": "SC-5", + "title": "Denial-of-service Protection", + "summary": "Denial-of-service Protection\na. Protect against the effects of the following types of denial-of-service events: at a minimum: ICMP (ping) flood, SYN flood, slowloris, buffer overflow attack, and volume attack ; and\nb. Employ the following controls to achieve the denial-of-service objective: {{ controls by type of denial-of-service event - controls to achieve the denial-of-service objective by type of denial-of-service event are defined; }}.", + "guidance": "Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events." + }, + { + "ref": "SC-7", + "title": "Boundary Protection", + "summary": "Boundary Protection\na. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;\nb. Implement subnetworks for publicly accessible system components that are {{ physically OR logically }} separated from internal organizational networks; and\nc. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.\nSC-7 Additional FedRAMP Requirements and Guidance \ncontrols SC-7(3) Access Points\nLimit the number of external network connections to the system.\nSC-7(4) External Telecommunications Services\n(a) Implement a managed interface for each external telecommunication service;\n(b) Establish a traffic flow policy for each managed interface;\n(c) Protect the confidentiality and integrity of the information being transmitted across each interface;\n(d) Document each exception to the traffic flow policy with a supporting mission or business need and duration of that need;\n(e) Review exceptions to the traffic flow policy at least every ninety (90) days or whenever there is a change in the threat environment that warrants a review of the exceptions and remove exceptions that are no longer supported by an explicit mission or business need;\n(f) Prevent unauthorized exchange of control plane traffic with external networks;\n(g) Publish information to enable remote networks to detect unauthorized control plane traffic from internal networks; and\n(h) Filter unauthorized control plane traffic from external networks.\nSC-7(5) Deny by Default \u2014 Allow by Exception\nDeny network communications traffic by default and allow network communications traffic by exception any systems.\nSC-7 (5) Additional FedRAMP Requirements and Guidance \nSC-7(7) Split Tunneling for Remote Devices\nPrevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using {{ safeguards - safeguards to securely provision split tunneling are defined; }}.\nSC-7(8) Route Traffic to Authenticated Proxy Servers\nRoute {{ internal communications traffic - internal communications traffic to be routed to external networks is defined; }} to any network outside of organizational control and any network outside the authorization boundary through authenticated proxy servers at managed interfaces.\nSC-7(10) Prevent Exfiltration\n(a) Prevent the exfiltration of information; and\n(b) Conduct exfiltration tests {{ frequency - the frequency for conducting exfiltration tests is defined; }}.\nSC-7(12) Host-based Protection\nImplement Host Intrusion Prevention System (HIPS), Host Intrusion Detection System (HIDS), or minimally a host-based firewall at {{ system components - system components where host-based boundary protection mechanisms are to be implemented are defined; }}.\nSC-7(18) Fail Secure\nPrevent systems from entering unsecure states in the event of an operational failure of a boundary protection device.\nSC-7(20) Dynamic Isolation and Segregation\nProvide the capability to dynamically isolate {{ system components - system components to be dynamically isolated from other system components are defined; }} from other system components.\nSC-7(21) Isolation of System Components\nEmploy boundary protection mechanisms to isolate {{ system components - system components to be isolated by boundary protection mechanisms are defined; }} supporting {{ missions and/or business functions - missions and/or business functions to be supported by system components isolated by boundary protection mechanisms are defined; }}.", + "guidance": "Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. [SP 800-189] provides additional information on source address validation techniques to prevent ingress and egress of traffic with spoofed addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary)." + }, + { + "ref": "SC-8", + "title": "Transmission Confidentiality and Integrity", + "summary": "Transmission Confidentiality and Integrity\nProtect the confidentiality AND integrity of transmitted information.\nSC-8 Additional FedRAMP Requirements and Guidance \ncontrols SC-8(1) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure of information AND detect changes to information during transmission.\nSC-8 (1) Additional FedRAMP Requirements and Guidance Requirement: Please ensure SSP Section 10.3 Cryptographic Modules Implemented for Data At Rest (DAR) and Data In Transit (DIT) is fully populated for reference in this control.", + "guidance": "Protecting the confidentiality and integrity of transmitted information applies to internal and external networks as well as any system components that can transmit information, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of information can be accomplished by physical or logical means. Physical protection can be achieved by using protected distribution systems. A protected distribution system is a wireline or fiber-optics telecommunications system that includes terminals and adequate electromagnetic, acoustical, electrical, and physical controls to permit its use for the unencrypted transmission of classified information. Logical protection can be achieved by employing encryption techniques.\n\nOrganizations that rely on commercial providers who offer transmission services as commodity services rather than as fully dedicated services may find it difficult to obtain the necessary assurances regarding the implementation of needed controls for transmission confidentiality and integrity. In such situations, organizations determine what types of confidentiality or integrity services are available in standard, commercial telecommunications service packages. If it is not feasible to obtain the necessary controls and assurances of control effectiveness through appropriate contracting vehicles, organizations can implement appropriate compensating controls." + }, + { + "ref": "SC-10", + "title": "Network Disconnect", + "summary": "Network Disconnect\nTerminate the network connection associated with a communications session at the end of the session or after no longer than ten (10) minutes for privileged sessions and no longer than fifteen (15) minutes for user sessions of inactivity.", + "guidance": "Network disconnect applies to internal and external networks. Terminating network connections associated with specific communications sessions includes de-allocating TCP/IP address or port pairs at the operating system level and de-allocating the networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. Periods of inactivity may be established by organizations and include time periods by type of network access or for specific network accesses." + }, + { + "ref": "SC-12", + "title": "Cryptographic Key Establishment and Management", + "summary": "Cryptographic Key Establishment and Management\nEstablish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: In accordance with Federal requirements.\nSC-12 Additional FedRAMP Requirements and Guidance \ncontrols SC-12(1) Availability\nMaintain availability of information in the event of the loss of cryptographic keys by users.", + "guidance": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment." + }, + { + "ref": "SC-13", + "title": "Cryptographic Protection", + "summary": "Cryptographic Protection\na. Determine the {{ cryptographic uses - cryptographic uses are defined; }} ; and\nb. Implement the following types of cryptography required for each specified cryptographic use: FIPS-validated or NSA-approved cryptography.\nSC-13 Additional FedRAMP Requirements and Guidance ", + "guidance": "Cryptography can be employed to support a variety of security solutions, including the protection of classified information and controlled unclassified information, the provision and implementation of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances but lack the necessary formal access approvals. Cryptography can also be used to support random number and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. For example, organizations that need to protect classified information may specify the use of NSA-approved cryptography. Organizations that need to provision and implement digital signatures may specify the use of FIPS-validated cryptography. Cryptography is implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "SC-15", + "title": "Collaborative Computing Devices and Applications", + "summary": "Collaborative Computing Devices and Applications\na. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: no exceptions for computing devices ; and\nb. Provide an explicit indication of use to users physically present at the devices.\nSC-15 Additional FedRAMP Requirements and Guidance Requirement: The information system provides disablement (instead of physical disconnect) of collaborative computing devices in a manner that supports ease of use.", + "guidance": "Collaborative computing devices and applications include remote meeting devices and applications, networked white boards, cameras, and microphones. The explicit indication of use includes signals to users when collaborative computing devices and applications are activated." + }, + { + "ref": "SC-17", + "title": "Public Key Infrastructure Certificates", + "summary": "Public Key Infrastructure Certificates\na. Issue public key certificates under an {{ certificate policy - a certificate policy for issuing public key certificates is defined; }} or obtain public key certificates from an approved service provider; and\nb. Include only approved trust anchors in trust stores or certificate stores managed by the organization.", + "guidance": "Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates." + }, + { + "ref": "SC-18", + "title": "Mobile Code", + "summary": "Mobile Code\na. Define acceptable and unacceptable mobile code and mobile code technologies; and\nb. Authorize, monitor, and control the use of mobile code within the system.", + "guidance": "Mobile code includes any program, application, or content that can be transmitted across a network (e.g., embedded in an email, document, or website) and executed on a remote system. Decisions regarding the use of mobile code within organizational systems are based on the potential for the code to cause damage to the systems if used maliciously. Mobile code technologies include Java applets, JavaScript, HTML5, WebGL, and VBScript. Usage restrictions and implementation guidelines apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices, including notebook computers and smart phones. Mobile code policy and procedures address specific actions taken to prevent the development, acquisition, and introduction of unacceptable mobile code within organizational systems, including requiring mobile code to be digitally signed by a trusted source." + }, + { + "ref": "SC-20", + "title": "Secure Name/Address Resolution Service (Authoritative Source)", + "summary": "Secure Name/Address Resolution Service (Authoritative Source)\na. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and\nb. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.\nSC-20 Additional FedRAMP Requirements and Guidance Requirement: Authoritative DNS servers must be geolocated in accordance with SA-9 (5).", + "guidance": "Providing authoritative source information enables external clients, including remote Internet clients, to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Systems that provide name and address resolution services include domain name system (DNS) servers. Additional artifacts include DNS Security Extensions (DNSSEC) digital signatures and cryptographic keys. Authoritative data includes DNS resource records. The means for indicating the security status of child zones include the use of delegation signer resource records in the DNS. Systems that use technologies other than the DNS to map between host and service names and network addresses provide other means to assure the authenticity and integrity of response data." + }, + { + "ref": "SC-21", + "title": "Secure Name/Address Resolution Service (Recursive or Caching Resolver)", + "summary": "Secure Name/Address Resolution Service (Recursive or Caching Resolver)\nRequest and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.\nSC-21 Additional FedRAMP Requirements and Guidance Requirement: Internal recursive DNS servers must be located inside an authorized environment. It is typically within the boundary, or leveraged from an underlying IaaS/PaaS.", + "guidance": "Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Systems that provide name and address resolution services for local clients include recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Systems that use technologies other than the DNS to map between host and service names and network addresses provide some other means to enable clients to verify the authenticity and integrity of response data." + }, + { + "ref": "SC-22", + "title": "Architecture and Provisioning for Name/Address Resolution Service", + "summary": "Architecture and Provisioning for Name/Address Resolution Service\nEnsure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.", + "guidance": "Systems that provide name and address resolution services include domain name system (DNS) servers. To eliminate single points of failure in systems and enhance redundancy, organizations employ at least two authoritative domain name system servers\u2014one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks, including the Internet). Organizations specify clients that can access authoritative DNS servers in certain roles (e.g., by address ranges and explicit lists)." + }, + { + "ref": "SC-23", + "title": "Session Authenticity", + "summary": "Session Authenticity\nProtect the authenticity of communications sessions.", + "guidance": "Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of communications sessions in the ongoing identities of other parties and the validity of transmitted information. Authenticity protection includes protecting against \"man-in-the-middle\" attacks, session hijacking, and the insertion of false information into sessions." + }, + { + "ref": "SC-24", + "title": "Fail in Known State", + "summary": "Fail in Known State\nFail to a {{ known system state - known system state to which system components fail in the event of a system failure is defined; }} for the following failures on the indicated components while preserving {{ system state information - system state information to be preserved in the event of a system failure is defined; }} in failure: {{ types of system failures on system components - types of system failures for which the system components fail to a known state are defined; }}.", + "guidance": "Failure in a known state addresses security concerns in accordance with the mission and business needs of organizations. Failure in a known state prevents the loss of confidentiality, integrity, or availability of information in the event of failures of organizational systems or system components. Failure in a known safe state helps to prevent systems from failing to a state that may cause injury to individuals or destruction to property. Preserving system state information facilitates system restart and return to the operational mode with less disruption of mission and business processes." + }, + { + "ref": "SC-28", + "title": "Protection of Information at Rest", + "summary": "Protection of Information at Rest\nProtect the confidentiality AND integrity of the following information at rest: {{ information at rest - information at rest requiring protection is defined; }}.\nSC-28 Additional FedRAMP Requirements and Guidance \ncontrols SC-28(1) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on all information system components storing Federal data or system data that must be protected at the High or Moderate impact levels: {{ information - information requiring cryptographic protection is defined; }}.\nSC-28 (1) Additional FedRAMP Requirements and Guidance ", + "guidance": "Information at rest refers to the state of information when it is not in process or in transit and is located on system components. Such components include internal or external hard disk drives, storage area network devices, or databases. However, the focus of protecting information at rest is not on the type of storage device or frequency of access but rather on the state of the information. Information at rest addresses the confidentiality and integrity of information and covers user information and system information. System-related information that requires protection includes configurations or rule sets for firewalls, intrusion detection and prevention systems, filtering routers, and authentication information. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing write-once-read-many (WORM) technologies. When adequate protection of information at rest cannot otherwise be achieved, organizations may employ other controls, including frequent scanning to identify malicious code at rest and secure offline storage in lieu of online storage." + }, + { + "ref": "SC-39", + "title": "Process Isolation", + "summary": "Process Isolation\nMaintain a separate execution domain for each executing system process.", + "guidance": "Systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. Process isolation technologies, including sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. Process isolation helps limit the access of potentially untrusted software to other system resources. The capability to maintain separate execution domains is available in commercial operating systems that employ multi-state processor technologies." + }, + { + "ref": "SC-45", + "title": "System Time Synchronization", + "summary": "System Time Synchronization\nSynchronize system clocks within and between systems and system components.\ncontrols SC-45(1) Synchronization with Authoritative Time Source\n(a) Compare the internal system clocks At least hourly with http://tf.nist.gov/tf-cgi/servers.cgi ; and\n(b) Synchronize the internal system clocks to the authoritative time source when the time difference is greater than any difference.\nSC-45(1) Additional FedRAMP Requirements and Guidance Requirement: The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.", + "guidance": "Time synchronization of system clocks is essential for the correct execution of many system services, including identification and authentication processes that involve certificates and time-of-day restrictions as part of access control. Denial of service or failure to deny expired credentials may result without properly synchronized clocks within and between systems and system components. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, such as clocks synchronizing within hundreds of milliseconds or tens of milliseconds. Organizations may define different time granularities for system components. Time service can be critical to other security capabilities\u2014such as access control and identification and authentication\u2014depending on the nature of the mechanisms used to support the capabilities." + } + ] + }, + { + "title": "System and Information Integrity", + "controls": [ + { + "ref": "SI-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} system and information integrity policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and information integrity policy and the associated system and information integrity controls;\nb. Designate an {{ official - an official to manage the system and information integrity policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and information integrity policy and procedures; and\nc. Review and update the current system and information integrity:\n1. Policy at least annually and following {{ events - events that would require the current system and information integrity policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and information integrity policy and procedures address the controls in the SI family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and information integrity policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and information integrity policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SI-2", + "title": "Flaw Remediation", + "summary": "Flaw Remediation\na. Identify, report, and correct system flaws;\nb. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;\nc. Install security-relevant software and firmware updates within within thirty (30) days of release of updates of the release of the updates; and\nd. Incorporate flaw remediation into the organizational configuration management process.\ncontrols SI-2(2) Automated Flaw Remediation Status\nDetermine if system components have applicable security-relevant software and firmware updates installed using {{ automated mechanisms - automated mechanisms to determine if applicable security-relevant software and firmware updates are installed on system components are defined; }} at least monthly.\nSI-2(3) Time to Remediate Flaws and Benchmarks for Corrective Actions\n(a) Measure the time between flaw identification and flaw remediation; and\n(b) Establish the following benchmarks for taking corrective actions: {{ benchmarks - the benchmarks for taking corrective actions are defined; }}.", + "guidance": "The need to remediate system flaws applies to all types of software and firmware. Organizations identify systems affected by software flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security and privacy responsibilities. Security-relevant updates include patches, service packs, and malicious code signatures. Organizations also address flaws discovered during assessments, continuous monitoring, incident response activities, and system error handling. By incorporating flaw remediation into configuration management processes, required remediation actions can be tracked and verified.\n\nOrganization-defined time periods for updating security-relevant software and firmware may vary based on a variety of risk factors, including the security category of the system, the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw), the organizational risk tolerance, the mission supported by the system, or the threat environment. Some types of flaw remediation may require more testing than other types. Organizations determine the type of testing needed for the specific type of flaw remediation activity under consideration and the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software or firmware updates is not necessary or practical, such as when implementing simple malicious code signature updates. In testing decisions, organizations consider whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures." + }, + { + "ref": "SI-3", + "title": "Malicious Code Protection", + "summary": "Malicious Code Protection\na. Implement signature based and non-signature based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code;\nb. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures;\nc. Configure malicious code protection mechanisms to:\n1. Perform periodic scans of the system at least weekly and real-time scans of files from external sources at to include endpoints and network entry and exit points as the files are downloaded, opened, or executed in accordance with organizational policy; and\n2. to include blocking and quarantining malicious code ; and send alert to {{ personnel or roles - personnel or roles to be alerted when malicious code is detected is/are defined; }} in response to malicious code detection; and\nd. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system.", + "guidance": "System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world-wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code.\n\nMalicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions.\n\nIn situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files." + }, + { + "ref": "SI-4", + "title": "System Monitoring", + "summary": "System Monitoring\na. Monitor the system to detect:\n1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: {{ monitoring objectives - monitoring objectives to detect attacks and indicators of potential attacks on the system are defined; }} ; and\n2. Unauthorized local, network, and remote connections;\nb. Identify unauthorized use of the system through the following techniques and methods: {{ techniques and methods - techniques and methods used to identify unauthorized use of the system are defined; }};\nc. Invoke internal monitoring capabilities or deploy monitoring devices:\n1. Strategically within the system to collect organization-determined essential information; and\n2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;\nd. Analyze detected events and anomalies;\ne. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation;\nf. Obtain legal opinion regarding system monitoring activities; and\ng. Provide {{ system monitoring information - system monitoring information to be provided to personnel or roles is defined; }} to {{ personnel or roles - personnel or roles to whom system monitoring information is to be provided is/are defined; }} {{ one or more: as needed, {{ frequency - a frequency for providing system monitoring to personnel or roles is defined (if selected); }} }}.\nSI-4 Additional FedRAMP Requirements and Guidance \ncontrols SI-4(1) System-wide Intrusion Detection System\nConnect and configure individual intrusion detection tools into a system-wide intrusion detection system.\nSI-4(2) Automated Tools and Mechanisms for Real-time Analysis\nEmploy automated tools and mechanisms to support near real-time analysis of events.\nSI-4(4) Inbound and Outbound Communications Traffic\n(a) Determine criteria for unusual or unauthorized activities or conditions for inbound and outbound communications traffic;\n(b) Monitor inbound and outbound communications traffic continuously for {{ organization-defined unusual or unauthorized activities or conditions }}.\nSI-4(5) System-generated Alerts\nAlert {{ personnel or roles - personnel or roles to be alerted when indications of compromise or potential compromise occur is/are defined; }} when the following system-generated indications of compromise or potential compromise occur: {{ compromise indicators - compromise indicators are defined; }}.\nSI-4 (5) Additional FedRAMP Requirements and Guidance \nSI-4(10) Visibility of Encrypted Communications\nMake provisions so that {{ encrypted communications traffic - encrypted communications traffic to be made visible to system monitoring tools and mechanisms is defined; }} is visible to {{ system monitoring tools and mechanisms - system monitoring tools and mechanisms to be provided access to encrypted communications traffic are defined; }}.\nSI-4 (10) Additional FedRAMP Requirements and Guidance Requirement: The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf) and M-22-09 (https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf).\nSI-4(11) Analyze Communications Traffic Anomalies\nAnalyze outbound communications traffic at the external interfaces to the system and selected {{ interior points - interior points within the system where communications traffic is to be analyzed are defined; }} to discover anomalies.\nSI-4(12) Automated Organization-generated Alerts\nAlert {{ personnel or roles - personnel or roles to be alerted when indications of inappropriate or unusual activity with security or privacy implications occur is/are defined; }} using {{ automated mechanisms - automated mechanisms used to alert personnel or roles are defined; }} when the following indications of inappropriate or unusual activities with security or privacy implications occur: {{ activities that trigger alerts - activities that trigger alerts to personnel or are defined; }}.\nSI-4(14) Wireless Intrusion Detection\nEmploy a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises or breaches to the system.\nSI-4(16) Correlate Monitoring Information\nCorrelate information from monitoring tools and mechanisms employed throughout the system.\nSI-4(18) Analyze Traffic and Covert Exfiltration\nAnalyze outbound communications traffic at external interfaces to the system and at the following interior points to detect covert exfiltration of information: {{ interior points - interior points within the system where communications traffic is to be analyzed are defined; }}.\nSI-4(19) Risk for Individuals\nImplement {{ additional monitoring - additional monitoring of individuals who have been identified as posing an increased level of risk is defined; }} of individuals who have been identified by {{ sources - sources that identify individuals who pose an increased level of risk are defined; }} as posing an increased level of risk.\nSI-4(20) Privileged Users\nImplement the following additional monitoring of privileged users: {{ additional monitoring - additional monitoring of privileged users is defined; }}.\nSI-4(22) Unauthorized Network Services\n(a) Detect network services that have not been authorized or approved by {{ authorization or approval processes - authorization or approval processes for network services are defined; }} ; and\n(b) {{ one or more: audit, alert {{ personnel or roles - personnel or roles to be alerted upon the detection of network services that have not been authorized or approved by authorization or approval processes is/are defined (if selected); }} }} when detected.\nSI-4(23) Host-based Devices\nImplement the following host-based monitoring mechanisms at {{ system components - system components where host-based monitoring is to be implemented are defined; }}: {{ host-based monitoring mechanisms - host-based monitoring mechanisms to be implemented on system components are defined; }}.", + "guidance": "System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at external interfaces to the system. Internal monitoring includes the observation of events occurring within the system. Organizations monitor systems by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives guide and inform the determination of the events. System monitoring capabilities are achieved through a variety of tools and techniques, including intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software.\n\nDepending on the security architecture, the distribution and configuration of monitoring devices may impact throughput at key internal and external boundaries as well as at other locations across a network due to the introduction of network throughput latency. If throughput management is needed, such devices are strategically located and deployed as part of an established organization-wide security architecture. Strategic locations for monitoring devices include selected perimeter locations and near key servers and server farms that support critical applications. Monitoring devices are typically employed at the managed interfaces associated with controls [SC-7] and [AC-17] . The information collected is a function of the organizational monitoring objectives and the capability of systems to support such objectives. Specific types of transactions of interest include Hypertext Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring is an integral part of organizational continuous monitoring and incident response programs, and output from system monitoring serves as input to those programs. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other controls (e.g., [AC-2g], [AC-2(7)], [AC-2(12)(a)], [AC-17(1)], [AU-13], [AU-13(1)], [AU-13(2)], [CM-3f], [CM-6d], [MA-3a], [MA-4a], [SC-5(3)(b)], [SC-7a], [SC-7(24)(b)], [SC-18b], [SC-43b] ). Adjustments to levels of system monitoring are based on law enforcement information, intelligence information, or other sources of information. The legality of system monitoring activities is based on applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "SI-5", + "title": "Security Alerts, Advisories, and Directives", + "summary": "Security Alerts, Advisories, and Directives\na. Receive system security alerts, advisories, and directives from to include US-CERT and Cybersecurity and Infrastructure Security Agency (CISA) Directives on an ongoing basis;\nb. Generate internal security alerts, advisories, and directives as deemed necessary;\nc. Disseminate security alerts, advisories, and directives to: to include system security personnel and administrators with configuration/patch-management responsibilities ; and\nd. Implement security directives in accordance with established time frames, or notify the issuing organization of the degree of noncompliance.\nRequirement: Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.\ncontrols SI-5(1) Automated Alerts and Advisories\nBroadcast security alert and advisory information throughout the organization using {{ automated mechanisms - automated mechanisms used to broadcast security alert and advisory information throughout the organization are defined; }}.", + "guidance": "The Cybersecurity and Infrastructure Security Agency (CISA) generates security alerts and advisories to maintain situational awareness throughout the Federal Government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance with security directives is essential due to the critical nature of many of these directives and the potential (immediate) adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include supply chain partners, external mission or business partners, external service providers, and other peer or supporting organizations." + }, + { + "ref": "SI-6", + "title": "Security and Privacy Function Verification", + "summary": "Security and Privacy Function Verification\na. Verify the correct operation of {{ organization-defined security and privacy functions }};\nb. Perform the verification of the functions specified in SI-6a {{ one or more: to include upon system startup and/or restart , upon command by user with appropriate privilege, at least monthly }};\nc. Alert to include system administrators and security personnel to failed security and privacy verification tests; and\nd. {{ one or more: shut the system down, restart the system, {{ alternative action(s) - alternative action(s) to be performed when anomalies are discovered are defined (if selected); }} }} when anomalies are discovered.", + "guidance": "Transitional states for systems include system startup, restart, shutdown, and abort. System notifications include hardware indicator lights, electronic alerts to system administrators, and messages to local computer consoles. In contrast to security function verification, privacy function verification ensures that privacy functions operate as expected and are approved by the senior agency official for privacy or that privacy attributes are applied or used as expected." + }, + { + "ref": "SI-7", + "title": "Software, Firmware, and Information Integrity", + "summary": "Software, Firmware, and Information Integrity\na. Employ integrity verification tools to detect unauthorized changes to the following software, firmware, and information: {{ organization-defined software, firmware, and information }} ; and\nb. Take the following actions when unauthorized changes to the software, firmware, and information are detected: {{ organization-defined actions }}.\ncontrols SI-7(1) Integrity Checks\nPerform an integrity check of {{ organization-defined software, firmware, and information }} {{ one or more: at startup, at selection to include security relevant event , at least monthly }}.\nSI-7(2) Automated Notifications of Integrity Violations\nEmploy automated tools that provide notification to to include the ISSO and/or similar role within the organization upon discovering discrepancies during integrity verification.\nSI-7(5) Automated Response to Integrity Violations\nAutomatically {{ one or more: shut down the system, restart the system, implement {{ controls - controls to be implemented automatically when integrity violations are discovered are defined (if selected); }} }} when integrity violations are discovered.\nSI-7(7) Integration of Detection and Response\nIncorporate the detection of the following unauthorized changes into the organizational incident response capability: {{ changes - security-relevant changes to the system are defined; }}.\nSI-7(15) Code Authentication\nImplement cryptographic mechanisms to authenticate the following software or firmware components prior to installation: to include all software and firmware inside the boundary.", + "guidance": "Unauthorized changes to software, firmware, and information can occur due to errors or malicious activity. Software includes operating systems (with key internal components, such as kernels or drivers), middleware, and applications. Firmware interfaces include Unified Extensible Firmware Interface (UEFI) and Basic Input/Output System (BIOS). Information includes personally identifiable information and metadata that contains security and privacy attributes associated with information. Integrity-checking mechanisms\u2014including parity checks, cyclical redundancy checks, cryptographic hashes, and associated tools\u2014can automatically monitor the integrity of systems and hosted applications." + }, + { + "ref": "SI-8", + "title": "Spam Protection", + "summary": "Spam Protection\na. Employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages; and\nb. Update spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures.\nSI-8 Additional FedRAMP Requirements and Guidance \ncontrols SI-8(2) Automatic Updates\nAutomatically update spam protection mechanisms {{ frequency - the frequency at which to automatically update spam protection mechanisms is defined; }}.", + "guidance": "System entry and exit points include firewalls, remote-access servers, electronic mail servers, web servers, proxy servers, workstations, notebook computers, and mobile devices. Spam can be transported by different means, including email, email attachments, and web accesses. Spam protection mechanisms include signature definitions." + }, + { + "ref": "SI-10", + "title": "Information Input Validation", + "summary": "Information Input Validation\nCheck the validity of the following information inputs: {{ information inputs - information inputs to the system requiring validity checks are defined; }}.\nSI-10 Additional FedRAMP Requirements and Guidance Requirement: Validate all information inputs and document any exceptions", + "guidance": "Checking the valid syntax and semantics of system inputs\u2014including character set, length, numerical range, and acceptable values\u2014verifies that inputs match specified definitions for format and content. For example, if the organization specifies that numerical values between 1-100 are the only acceptable inputs for a field in a given application, inputs of \"387,\" \"abc,\" or \"%K%\" are invalid inputs and are not accepted as input to the system. Valid inputs are likely to vary from field to field within a software application. Applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the corrupted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing them to interpreters prevents the content from being unintentionally interpreted as commands. Input validation ensures accurate and correct inputs and prevents attacks such as cross-site scripting and a variety of injection attacks." + }, + { + "ref": "SI-11", + "title": "Error Handling", + "summary": "Error Handling\na. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and\nb. Reveal error messages only to to include the ISSO and/or similar role within the organization.", + "guidance": "Organizations consider the structure and content of error messages. The extent to which systems can handle error conditions is guided and informed by organizational policy and operational requirements. Exploitable information includes stack traces and implementation details; erroneous logon attempts with passwords mistakenly entered as the username; mission or business information that can be derived from, if not stated explicitly by, the information recorded; and personally identifiable information, such as account numbers, social security numbers, and credit card numbers. Error messages may also provide a covert channel for transmitting information." + }, + { + "ref": "SI-12", + "title": "Information Management and Retention", + "summary": "Information Management and Retention\nManage and retain information within the system and information output from the system in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements.", + "guidance": "Information management and retention requirements cover the full life cycle of information, in some cases extending beyond system disposal. Information to be retained may also include policies, procedures, plans, reports, data output from control implementation, and other types of administrative information. The National Archives and Records Administration (NARA) provides federal policy and guidance on records retention and schedules. If organizations have a records management office, consider coordinating with records management personnel. Records produced from the output of implemented controls that may require management and retention include, but are not limited to: All XX-1, [AC-6(9)], [AT-4], [AU-12], [CA-2], [CA-3], [CA-5], [CA-6], [CA-7], [CA-8], [CA-9], [CM-2], [CM-3], [CM-4], [CM-6], [CM-8], [CM-9], [CM-12], [CM-13], [CP-2], [IR-6], [IR-8], [MA-2], [MA-4], [PE-2], [PE-8], [PE-16], [PE-17], [PL-2], [PL-4], [PL-7], [PL-8], [PM-5], [PM-8], [PM-9], [PM-18], [PM-21], [PM-27], [PM-28], [PM-30], [PM-31], [PS-2], [PS-6], [PS-7], [PT-2], [PT-3], [PT-7], [RA-2], [RA-3], [RA-5], [RA-8], [SA-4], [SA-5], [SA-8], [SA-10], [SI-4], [SR-2], [SR-4], [SR-8]." + }, + { + "ref": "SI-16", + "title": "Memory Protection", + "summary": "Memory Protection\nImplement the following controls to protect the system memory from unauthorized code execution: {{ controls - controls to be implemented to protect the system memory from unauthorized code execution are defined; }}.", + "guidance": "Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Controls employed to protect memory include data execution prevention and address space layout randomization. Data execution prevention controls can either be hardware-enforced or software-enforced with hardware enforcement providing the greater strength of mechanism." + } + ] + }, + { + "title": "Supply Chain Risk Management", + "controls": [ + { + "ref": "SR-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to to include chief privacy and ISSO and/or similar role or designees:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} supply chain risk management policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the supply chain risk management policy and the associated supply chain risk management controls;\nb. Designate an {{ official - an official to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures is defined; }} to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures; and\nc. Review and update the current supply chain risk management:\n1. Policy at least annually and following {{ events - events that require the current supply chain risk management policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Supply chain risk management policy and procedures address the controls in the SR family as well as supply chain-related controls in other families that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of supply chain risk management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to supply chain risk management policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SR-2", + "title": "Supply Chain Risk Management Plan", + "summary": "Supply Chain Risk Management Plan\na. Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of the following systems, system components or system services: {{ systems, system components, or system services - systems, system components, or system services for which a supply chain risk management plan is developed are defined; }};\nb. Review and update the supply chain risk management plan at least annually or as required, to address threat, organizational or environmental changes; and\nc. Protect the supply chain risk management plan from unauthorized disclosure and modification.\ncontrols SR-2(1) Establish SCRM Team\nEstablish a supply chain risk management team consisting of {{ personnel, roles and responsibilities - the personnel, roles, and responsibilities of the supply chain risk management team are defined; }} to lead and support the following SCRM activities: {{ supply chain risk management activities - supply chain risk management activities are defined; }}.", + "guidance": "The dependence on products, systems, and services from external providers, as well as the nature of the relationships with those providers, present an increasing level of risk to an organization. Threat actions that may increase security or privacy risks include unauthorized production, the insertion or use of counterfeits, tampering, theft, insertion of malicious software and hardware, and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system element or component, a system, an organization, a sector, or the Nation. Managing supply chain risk is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders. Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against plans. The SCRM plan (at the system-level) is implementation specific, providing policy implementation, requirements, constraints and implications. It can either be stand-alone, or incorporated into system security and privacy plans. The SCRM plan addresses managing, implementation, and monitoring of SCRM controls and the development/sustainment of systems across the SDLC to support mission and business functions.\n\nBecause supply chains can differ significantly across and within organizations, SCRM plans are tailored to the individual program, organizational, and operational contexts. Tailored SCRM plans provide the basis for determining whether a technology, service, system component, or system is fit for purpose, and as such, the controls need to be tailored accordingly. Tailored SCRM plans help organizations focus their resources on the most critical mission and business functions based on mission and business requirements and their risk environment. Supply chain risk management plans include an expression of the supply chain risk tolerance for the organization, acceptable supply chain risk mitigation strategies or controls, a process for consistently evaluating and monitoring supply chain risk, approaches for implementing and communicating the plan, a description of and justification for supply chain risk mitigation measures taken, and associated roles and responsibilities. Finally, supply chain risk management plans address requirements for developing trustworthy, secure, privacy-protective, and resilient system components and systems, including the application of the security design principles implemented as part of life cycle-based systems security engineering processes (see [SA-8])." + }, + { + "ref": "SR-3", + "title": "Supply Chain Controls and Processes", + "summary": "Supply Chain Controls and Processes\na. Establish a process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes of {{ system or system component - the system or system component requiring a process or processes to identify and address weaknesses or deficiencies is defined; }} in coordination with {{ supply chain personnel - supply chain personnel with whom to coordinate the process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes is/are defined; }};\nb. Employ the following controls to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events: {{ supply chain controls - supply chain controls employed to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events are defined; }} ; and\nc. Document the selected and implemented supply chain processes and controls in {{ one or more: security and privacy plans, supply chain risk management plan, {{ document - the document identifying the selected and implemented supply chain processes and controls is defined (if selected); }} }}.\nSR-3 Additional FedRAMP Requirements and Guidance Requirement: CSO must document and maintain the supply chain custody, including replacement devices, to ensure the integrity of the devices before being introduced to the boundary.", + "guidance": "Supply chain elements include organizations, entities, or tools employed for the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, and firmware development processes; shipping and handling procedures; personnel security and physical security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components. Supply chain elements and processes may be provided by organizations, system integrators, or external providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to cause harm to the organization and affect its ability to carry out its core missions or business functions. Supply chain personnel are individuals with roles and responsibilities in the supply chain." + }, + { + "ref": "SR-5", + "title": "Acquisition Strategies, Tools, and Methods", + "summary": "Acquisition Strategies, Tools, and Methods\nEmploy the following acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks: {{ strategies, tools, and methods - acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks are defined; }}.", + "guidance": "The use of the acquisition process provides an important vehicle to protect the supply chain. There are many useful tools and techniques available, including obscuring the end use of a system or system component, using blind or filtered buys, requiring tamper-evident packaging, or using trusted or controlled distribution. The results from a supply chain risk assessment can guide and inform the strategies, tools, and methods that are most applicable to the situation. Tools and techniques may provide protections against unauthorized production, theft, tampering, insertion of counterfeits, insertion of malicious software or backdoors, and poor development practices throughout the system development life cycle. Organizations also consider providing incentives for suppliers who implement controls, promote transparency into their processes and security and privacy practices, provide contract language that addresses the prohibition of tainted or counterfeit components, and restrict purchases from untrustworthy suppliers. Organizations consider providing training, education, and awareness programs for personnel regarding supply chain risk, available mitigation strategies, and when the programs should be employed. Methods for reviewing and protecting development plans, documentation, and evidence are commensurate with the security and privacy requirements of the organization. Contracts may specify documentation protection requirements." + }, + { + "ref": "SR-6", + "title": "Supplier Assessments and Reviews", + "summary": "Supplier Assessments and Reviews\nAssess and review the supply chain-related risks associated with suppliers or contractors and the system, system component, or system service they provide at least annually.\nSR-6 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure that their supply chain vendors build and test their systems in alignment with NIST SP 800-171 or a commensurate security and compliance framework. CSOs must ensure that vendors are compliant with physical facility access and logical access controls to supplied products.", + "guidance": "An assessment and review of supplier risk includes security and supply chain risk management processes, foreign ownership, control or influence (FOCI), and the ability of the supplier to effectively assess subordinate second-tier and third-tier suppliers and contractors. The reviews may be conducted by the organization or by an independent third party. The reviews consider documented processes, documented controls, all-source intelligence, and publicly available information related to the supplier or contractor. Organizations can use open-source information to monitor for indications of stolen information, poor development and quality control practices, information spillage, or counterfeits. In some cases, it may be appropriate or required to share assessment and review results with other organizations in accordance with any applicable rules, policies, or inter-organizational agreements or contracts." + }, + { + "ref": "SR-8", + "title": "Notification Agreements", + "summary": "Notification Agreements\nEstablish agreements and procedures with entities involved in the supply chain for the system, system component, or system service for the notification of supply chain compromises and results of assessment or audits.\nSR-8 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure and document how they receive notifications from their supply chain vendor of newly discovered vulnerabilities including zero-day vulnerabilities.", + "guidance": "The establishment of agreements and procedures facilitates communications among supply chain entities. Early notification of compromises and potential compromises in the supply chain that can potentially adversely affect or have adversely affected organizational systems or system components is essential for organizations to effectively respond to such incidents. The results of assessments or audits may include open-source information that contributed to a decision or result and could be used to help the supply chain entity resolve a concern or improve its processes." + }, + { + "ref": "SR-9", + "title": "Tamper Resistance and Detection", + "summary": "Tamper Resistance and Detection\nImplement a tamper protection program for the system, system component, or system service.\nSR-9 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure vendors provide authenticity of software and patches supplied to the service provider including documenting the safeguards in place.\ncontrols SR-9(1) Multiple Stages of System Development Life Cycle\nEmploy anti-tamper technologies, tools, and techniques throughout the system development life cycle.", + "guidance": "Anti-tamper technologies, tools, and techniques provide a level of protection for systems, system components, and services against many threats, including reverse engineering, modification, and substitution. Strong identification combined with tamper resistance and/or tamper detection is essential to protecting systems and components during distribution and when in use." + }, + { + "ref": "SR-10", + "title": "Inspection of Systems or Components", + "summary": "Inspection of Systems or Components\nInspect the following systems or system components {{ one or more: at random, at {{ frequency - frequency at which to inspect systems or system components is defined (if selected); }} , upon {{ indications of need for inspection - indications of the need for an inspection of systems or system components are defined (if selected); }} }} to detect tampering: {{ systems or system components - systems or system components that require inspection are defined; }}.", + "guidance": "The inspection of systems or systems components for tamper resistance and detection addresses physical and logical tampering and is applied to systems and system components removed from organization-controlled areas. Indications of a need for inspection include changes in packaging, specifications, factory location, or entity in which the part is purchased, and when individuals return from travel to high-risk locations." + }, + { + "ref": "SR-11", + "title": "Component Authenticity", + "summary": "Component Authenticity\na. Develop and implement anti-counterfeit policy and procedures that include the means to detect and prevent counterfeit components from entering the system; and\nb. Report counterfeit system components to {{ one or more: source of counterfeit component, {{ external reporting organizations - external reporting organizations to whom counterfeit system components are to be reported is/are defined (if selected); }} , {{ personnel or roles - personnel or roles to whom counterfeit system components are to be reported is/are defined (if selected); }} }}.\nSR-11 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure that their supply chain vendors provide authenticity of software and patches and the vendor must have a plan to protect the development pipeline.\ncontrols SR-11(1) Anti-counterfeit Training\nTrain {{ personnel or roles - personnel or roles requiring training to detect counterfeit system components (including hardware, software, and firmware) is/are defined; }} to detect counterfeit system components (including hardware, software, and firmware).\nSR-11(2) Configuration Control for Component Service and Repair\nMaintain configuration control over the following system components awaiting service or repair and serviced or repaired components awaiting return to service: all.", + "guidance": "Sources of counterfeit components include manufacturers, developers, vendors, and contractors. Anti-counterfeiting policies and procedures support tamper resistance and provide a level of protection against the introduction of malicious code. External reporting organizations include CISA." + }, + { + "ref": "SR-12", + "title": "Component Disposal", + "summary": "Component Disposal\nDispose of {{ data, documentation, tools, or system components - data, documentation, tools, or system components to be disposed of are defined; }} using the following techniques and methods: {{ techniques and methods - techniques and methods for disposing of data, documentation, tools, or system components are defined; }}.", + "guidance": "Data, documentation, tools, or system components can be disposed of at any time during the system development life cycle (not only in the disposal or retirement phase of the life cycle). For example, disposal can occur during research and development, design, prototyping, or operations/maintenance and include methods such as disk cleaning, removal of cryptographic keys, partial reuse of components. Opportunities for compromise during disposal affect physical and logical data, including system documentation in paper-based or digital files; shipping and delivery documentation; memory sticks with software code; or complete routers or servers that include permanent media, which contain sensitive or proprietary information. Additionally, proper disposal of system components helps to prevent such components from entering the gray market." + } + ] } - ] - } - ] + ] } \ No newline at end of file diff --git a/templates/standards/fedramp/v5/fedramp-low.json b/templates/standards/fedramp/v5/fedramp-low.json index 73f82a2..8803247 100644 --- a/templates/standards/fedramp/v5/fedramp-low.json +++ b/templates/standards/fedramp/v5/fedramp-low.json @@ -1,718 +1,908 @@ { - "standard": "FedRAMP Low", - "version": "NIST 800-53r4", - "basedOn": "NIST 800-53r4", - "webLink": "https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx", - "domains": [ - { - "title": "ACCESS CONTROL", - "controls": [ - { - "ref": "AC-1", - "title": "Access Control Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the access control policy and associated access controls; and\n b. Reviews and updates the current:\n 1. Access control policy **at least every 3 years**; and\n 2. Access control procedures **at least annually**." - }, - { - "ref": "AC-2", - "title": "Account Management", - "summary": "The organization:\n a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];\n b. Assigns account managers for information system accounts;\n c. Establishes conditions for group and role membership;\n d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;\n e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;\n f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];\n g. Monitors the use of, information system accounts;\n h. Notifies account managers:\n 1. When accounts are no longer required;\n 2. When users are terminated or transferred; and\n 3. When individual information system usage or need-to-know changes;\n i. Authorizes access to the information system based on:\n 1. A valid access authorization;\n 2. Intended system usage; and\n 3. Other attributes as required by the organization or associated missions/business functions;\n j. Reviews accounts for compliance with account management requirements **at least annually**; and\n k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group." - }, - { - "ref": "AC-3", - "title": "Access Enforcement", - "summary": "The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies." - }, - { - "ref": "AC-7", - "title": "Unsuccessful Logon Attempts", - "summary": "The information system:\n a. Enforces a limit of **not more than three (3)** consecutive invalid logon attempts by a user during a **fifteen (15) minutes**; and\n b. Automatically [Selection: locks the account/node for an **locks the account/node for thirty minutes**; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded." - }, - { - "ref": "AC-8", - "title": "System Use Notification", - "summary": "The information system:\n a. Displays to users **see additional Requirements and Guidance** before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that:\n 1. Users are accessing a U.S. Government information system;\n 2. Information system usage may be monitored, recorded, and subject to audit;\n 3. Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and\n 4. Use of the information system indicates consent to monitoring and recording;\n b. Retains the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the information system; and \n c. For publicly accessible systems:\n 1. Displays system use information [Assignment: organization-defined conditions], before granting further access;\n 2. Displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and\n 3. Includes a description of the authorized uses of the system." - }, - { - "ref": "AC-14", - "title": "Permitted Actions Without Identification or Authentication", - "summary": "The organization:\n a. Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and\n b. Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication." - }, - { - "ref": "AC-17", - "title": "Remote Access", - "summary": "The organization:\n a. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\n b. Authorizes remote access to the information system prior to allowing such connections." - }, - { - "ref": "AC-18", - "title": "Wireless Access", - "summary": "The organization:\n a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and\n b. Authorizes wireless access to the information system prior to allowing such connections." - }, - { - "ref": "AC-19", - "title": "Access Control for Mobile Devices", - "summary": "The organization:\n a. Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and\n b. Authorizes the connection of mobile devices to organizational information systems." - }, - { - "ref": "AC-20", - "title": "Use of External Information Systems", - "summary": "The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:\n a. Access the information system from external information systems; and\n b. Process, store, or transmit organization-controlled information using external information systems." - }, - { - "ref": "AC-22", - "title": "Publicly Accessible Content", - "summary": "The organization:\n a. Designates individuals authorized to post information onto a publicly accessible information system;\n b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\n c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and\n d. Reviews the content on the publicly accessible information system for nonpublic information **at least quarterly** and removes such information, if discovered." - } - ] - }, - { - "title": "AWARENESS AND TRAINING", - "controls": [ - { - "ref": "AT-1", - "title": "Security Awareness and Training Policy Andprocedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security awareness and training policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security awareness and training policy and associated security awareness and training controls; and\n b. Reviews and updates the current:\n 1. Security awareness and training policy **at least every 3 years**; and\n 2. Security awareness and training procedures **at least annually**." - }, - { - "ref": "AT-2", - "title": "Security Awareness Training", - "summary": "The organization provides basic security awareness training to information system users (including managers, senior executives, and contractors):\n a. As part of initial training for new users;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "AT-3", - "title": "Role-Based Security Training", - "summary": "The organization provides role-based security training to personnel with assigned security roles and responsibilities:\na. Before authorizing access to the information system or performing assigned duties;\nb. When required by information system changes; and\nc. **at least annually** thereafter." - }, - { - "ref": "AT-4", - "title": "Security Training Records", - "summary": "The organization:\n a. Documents and monitors individual information system security training activities including basic security awareness training and specific information system security training; and\n b. Retains individual training records for **At least one year**." - } - ] - }, - { - "title": "AUDIT AND ACCOUNTABILITY", - "controls": [ - { - "ref": "AU-1", - "title": "Audit and Accountability Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and\n b. Reviews and updates the current:\n 1. Audit and accountability policy **at least every 3 years**; and\n 2. Audit and accountability procedures **at least annually**." - }, - { - "ref": "AU-2", - "title": "Audit Events", - "summary": "The organization:\n a. Determines that the information system is capable of auditing the following events: **successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes**;\n b. Coordinates the security audit function with other organizational entities requiring audit- related information to enhance mutual support and to help guide the selection of auditable events;\n c. Provides a rationale for why the auditable events are deemed to be adequate to support after- the-fact investigations of security incidents; and\n d. Determines that the following events are to be audited within the information system: **organization-defined subset of the auditable events defined in AU-2 a to be audited continually for each identified event**." - }, - { - "ref": "AU-3", - "title": "Content of Audit Records", - "summary": "The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event." - }, - { - "ref": "AU-4", - "title": "Audit Storage Capacity", - "summary": "The organization allocates audit record storage capacity in accordance with [Assignment:\norganization-defined audit record storage requirements]." - }, - { - "ref": "AU-5", - "title": "Response To Audit Processing Failures", - "summary": "The information system:\n a. Alerts [Assignment: organization-defined personnel or roles] in the event of an audit processing failure; and\n b. Takes the following additional actions: [Assignment: organization-defined actions to be taken (e.g., shut down information system, overwrite oldest audit records, stop generating audit records)]." - }, - { - "ref": "AU-6", - "title": "Audit Review, Analysis, and Reporting", - "summary": "The organization:\n a. Reviews and analyzes information system audit records **at least weekly** for indications of [Assignment: organization-defined inappropriate or unusual activity]; and\n b. Reports findings to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "AU-8", - "title": "Time Stamps", - "summary": "The information system:\n a. Uses internal system clocks to generate time stamps for audit records; and\n b. Records time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) and meets [Assignment: organization-defined granularity of time measurement]." - }, - { - "ref": "AU-9", - "title": "Protection of Audit Information", - "summary": "The information system protects audit information and audit tools from unauthorized access, modification, and deletion." - }, - { - "ref": "AU-11", - "title": "Audit Record Retention", - "summary": "The organization retains audit records for **at least ninety days** to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements." - }, - { - "ref": "AU-12", - "title": "Audit Generation", - "summary": "The information system:\n a. Provides audit record generation capability for the auditable events defined in AU-2 a. at **all information system and network components where audit capability is deployed/available**;\n b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and\n c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3." - } - ] - }, - { - "title": "SECURITY ASSESSMENT AND AUTHORIZATION", - "controls": [ - { - "ref": "CA-1", - "title": "Security Assessment and Authorization Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security assessment and authorization policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security assessment and authorization policy and associated security assessment and authorization controls; and\n b. Reviews and updates the current:\n 1. Security assessment and authorization policy **at least every 3 years**; and\n 2. Security assessment and authorization procedures **at least annually**." - }, - { - "ref": "CA-2", - "title": "Security Assessments", - "summary": "The organization:\n a. Develops a security assessment plan that describes the scope of the assessment including:\n 1. Security controls and control enhancements under assessment;\n 2. Assessment procedures to be used to determine security control effectiveness; and\n 3. Assessment environment, assessment team, and assessment roles and responsibilities;\n b. Assesses the security controls in the information system and its environment of operation **at least annually** to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements;\n c. Produces a security assessment report that documents the results of the assessment; and\n d. Provides the results of the security control assessment to **individuals or roles to include FedRAMP PMO**." - }, - { - "ref": "CA-2 (1)", - "title": "Security Assessments | Independent Assessors", - "summary": "The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to conduct security control assessments." - }, - { - "ref": "CA-3", - "title": "System Interconnections", - "summary": "The organization:\n a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements;\n b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and\n c. Reviews and updates Interconnection Security Agreements **at least annually and on input from FedRAMP**." - }, - { - "ref": "CA-5", - "title": "Plan of Action and Milestones", - "summary": "The organization:\n a. Develops a plan of action and milestones for the information system to document the organization’s planned remedial actions to correct weaknesses or deficiencies noted during\nthe assessment of the security controls and to reduce or eliminate known vulnerabilities in the system; and\n b. Updates existing plan of action and milestones **at least monthly** based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities." - }, - { - "ref": "CA-6", - "title": "Security Authorization", - "summary": "The organization:\n a. Assigns a senior-level executive or manager as the authorizing official for the information system;\n b. Ensures that the authorizing official authorizes the information system for processing before commencing operations; and\n c. Updates the security authorization **at least every three years or when a significant change occurs**." - }, - { - "ref": "CA-7", - "title": "Continuous Monitoring", - "summary": "The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:\n a. Establishment of [Assignment: organization-defined metrics] to be monitored;\n b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;\n c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;\n d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;\n e. Correlation and analysis of security-related information generated by assessments and monitoring;\n f. Response actions to address results of the analysis of security-related information; and\n g. Reporting the security status of organization and the information system to **to meet Federal and FedRAMP requirements** [Assignment: organization-defined frequency]." - }, - { - "ref": "CA-9", - "title": "Internal System Connections", - "summary": "The organization:\n a. Authorizes internal connections of [Assignment: organization-defined information system components or classes of components] to the information system; and\n b. Documents, for each internal connection, the interface characteristics, security requirements, and the nature of the information communicated." - } - ] - }, - { - "title": "CONFIGURATION MANAGEMENT", - "controls": [ - { - "ref": "CM-1", - "title": "Configuration Management Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the configuration management policy and associated configuration management controls; and\n b. Reviews and updates the current:\n 1. Configuration management policy **at least every 3 years**; and\n 2. Configuration management procedures **at least annually**." - }, - { - "ref": "CM-2", - "title": "Baseline Configuration", - "summary": "The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system." - }, - { - "ref": "CM-4", - "title": "Security Impact Analysis", - "summary": "The organization analyzes changes to the information system to determine potential security impacts prior to change implementation." - }, - { - "ref": "CM-6", - "title": "Configuration Settings", - "summary": "The organization:\n a. Establishes and documents configuration settings for information technology products employed within the information system using **United States Government Configuration Baseline (USGCB)** that reflect the most restrictive mode consistent with operational requirements;\n b. Implements the configuration settings;\n c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and\n d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures." - }, - { - "ref": "CM-7", - "title": "Least Functionality", - "summary": "The organization:\n a. Configures the information system to provide only essential capabilities; and\n b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: **United States Government Configuration Baseline (USGCB)**." - }, - { - "ref": "CM-8", - "title": "Information System Component Inventory", - "summary": "The organization:\n a. Develops and documents an inventory of information system components that:\n 1. Accurately reflects the current information system;\n 2. Includes all components within the authorization boundary of the information system;\n 3. Is at the level of granularity deemed necessary for tracking and reporting; and\n 4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\n b. Reviews and updates the information system component inventory **at least monthly**." - }, - { - "ref": "CM-10", - "title": "Software Usage Restrictions", - "summary": "The organization:\na. Uses software and associated documentation in accordance with contract agreements and copyright laws;\nb. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Controls and documents the use of 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." - }, - { - "ref": "CM-11", - "title": "User-Installed Software", - "summary": "The organization:\n a. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\n b. Enforces software installation policies through [Assignment: organization-defined methods]; and\n c. Monitors policy compliance at **Continuously (via CM-7 (5))**." - } - ] - }, - { - "title": "CONTINGENCY PLANNING", - "controls": [ - { - "ref": "CP-1", - "title": "Contingency Planning Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A contingency planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls; and\n b. Reviews and updates the current:\n 1. Contingency planning policy **at least every 3 years**; and\n 2. Contingency planning procedures **at least annually**." - }, - { - "ref": "CP-2", - "title": "Contingency Plan", - "summary": "The organization:\n a. Develops a contingency plan for the information system that:\n 1. Identifies essential missions and business functions and associated contingency requirements;\n 2. Provides recovery objectives, restoration priorities, and metrics;\n 3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;\n 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and\n 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];\n c. Coordinates contingency planning activities with incident handling activities;\n d. Reviews the contingency plan for the information system **at least annually**;\n e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\n f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and\n g. Protects the contingency plan from unauthorized disclosure and modification." - }, - { - "ref": "CP-3", - "title": "Contingency Training", - "summary": "The organization provides contingency training to information system users consistent with assigned roles and responsibilities:\n a. Within **ten (10) days** of assuming a contingency role or responsibility;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "CP-4", - "title": "Contingency Plan Testing", - "summary": "The organization:\n a. Tests the contingency plan for the information system **at least annually for moderate impact systems; at least every three years for low impact systems** using **functional exercises for moderate impact systems; classroom exercises/table top written tests for low impact systems** to determine the effectiveness of the plan and the organizational readiness to execute the plan;\n b. Reviews the contingency plan test results; and\n c. Initiates corrective actions, if needed." - }, - { - "ref": "CP-9", - "title": "Information System Backup", - "summary": "The organization:\na. Conducts backups of user-level information contained in the information system **daily incremental; weekly full**;\nb. Conducts backups of system-level information contained in the information system **daily incremental; weekly full**;\nc. Conducts backups of information system documentation including security-related documentation **daily incremental; weekly full**; and\nd. Protects the confidentiality, integrity, and availability of backup information at storage locations." - }, - { - "ref": "CP-10", - "title": "Information System Recovery and Reconstitution", - "summary": "The organization provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure." - } - ] - }, - { - "title": "IDENTIFICATION AND AUTHENTICATION", - "controls": [ - { - "ref": "IA-1", - "title": "Identification and Authentication Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the identification and authentication policy and associated identification and authentication controls; and\n b. Reviews and updates the current:\n 1. Identification and authentication policy **at least every 3 years**; and\n 2. Identification and authentication procedures **at least annually**." - }, - { - "ref": "IA-2", - "title": "Identification and Authentication (Organizational Users)", - "summary": "The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users)." - }, - { - "ref": "IA-2 (1)", - "title": "Identification and Authentication | Network Access To Privileged Accounts", - "summary": "The information system implements multifactor authentication for network access to privileged accounts." - }, - { - "ref": "IA-2 (12)", - "title": "Identification and Authentication | Acceptance of Piv Credentials", - "summary": "The information system accepts and electronically verifies Personal Identity Verification (PIV)\ncredentials." - }, - { - "ref": "IA-4", - "title": "Identifier Management", - "summary": "The organization manages information system identifiers by:\n a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier;\n b. Selecting an identifier that identifies an individual, group, role, or device;\n c. Assigning the identifier to the intended individual, group, role, or device;\n d. Preventing reuse of identifiers for **at least two years**; and\n e. Disabling the identifier after **ninety days for user identifiers**." - }, - { - "ref": "IA-5", - "title": "Authenticator Management", - "summary": "The organization manages information system authenticators by:\n a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator;\n b. Establishing initial authenticator content for authenticators defined by the organization;\n c. Ensuring that authenticators have sufficient strength of mechanism for their intended use;\n d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators;\n e. Changing default content of authenticators prior to information system installation;\n f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators;\n g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type];\n h. Protecting authenticator content from unauthorized disclosure and modification;\n i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and\n j. Changing authenticators for group/role accounts when membership to those accounts changes." - }, - { - "ref": "IA-5 (1)", - "title": "Authenticator Management | Password-Based Authentication", - "summary": "The information system, for password-based authentication:\n (a) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type];\n (b) Enforces at least the following number of changed characters when new passwords are created: [Assignment: organization-defined number];\n (c) Stores and transmits only encrypted representations of passwords;\n (d) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization- defined numbers for lifetime minimum, lifetime maximum];\n (e) Prohibits password reuse for [Assignment: organization-defined number] generations; and\n (f) Allows the use of a temporary password for system logons with an immediate change to a permanent password." - }, - { - "ref": "IA-5 (11)", - "title": "Authenticator Management | Hardware Token-Based Authentication", - "summary": "The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]." - }, - { - "ref": "IA-6", - "title": "Authenticator Feedback", - "summary": "The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals." - }, - { - "ref": "IA-7", - "title": "Cryptographic Module Authentication", - "summary": "The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication." - }, - { - "ref": "IA-8", - "title": "Identification and Authentication (Non- Organizational Users)", - "summary": "The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users)." - }, - { - "ref": "IA-8 (1)", - "title": "Identification and Authentication | Acceptance of Piv Credentials From Other Agencies", - "summary": "The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies." - }, - { - "ref": "IA-8 (2)", - "title": "Identification and Authentication | Acceptance of Third-Party Credentials", - "summary": "The information system accepts only FICAM-approved third-party credentials." - }, - { - "ref": "IA-8 (3)", - "title": "Identification and Authentication | Use of Ficam-Approved Products", - "summary": "The organization employs only FICAM-approved information system components in [Assignment:\norganization-defined information systems] to accept third-party credentials." - }, - { - "ref": "IA-8 (4)", - "title": "Identification and Authentication | Use of Ficam-Issued Profiles", - "summary": "The information system conforms to FICAM-issued profiles." - } - ] - }, - { - "title": "INCIDENT RESPONSE", - "controls": [ - { - "ref": "IR-1", - "title": "Incident Response Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the incident response policy and associated incident response controls; and\n b. Reviews and updates the current:\n 1. Incident response policy **at least every 3 years**; and\n 2. Incident response procedures **at least annually**." - }, - { - "ref": "IR-2", - "title": "Incident Response Training", - "summary": "The organization provides incident response training to information system users consistent with assigned roles and responsibilities:\n a. Within [Assignment: organization-defined time period] of assuming an incident response role or responsibility;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "IR-4", - "title": "Incident Handling", - "summary": "The organization:\na. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;\nb. Coordinates incident handling activities with contingency planning activities; and\nc. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly." - }, - { - "ref": "IR-5", - "title": "Incident Monitoring", - "summary": "The organization tracks and documents information system security incidents." - }, - { - "ref": "IR-6", - "title": "Incident Reporting", - "summary": "The organization:\n a. Requires personnel to report suspected security incidents to the organizational incident response capability within **US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended)**; and\n b. Reports security incident information to [Assignment: organization-defined authorities]." - }, - { - "ref": "IR-7", - "title": "Incident Response Assistance", - "summary": "The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents." - }, - { - "ref": "IR-8", - "title": "Incident Response Plan", - "summary": "The organization:\n a. Develops an incident response plan that:\n 1. Provides the organization with a roadmap for implementing its incident response capability;\n 2. Describes the structure and organization of the incident response capability;\n 3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n 4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n 5. Defines reportable incidents;\n 6. Provides metrics for measuring the incident response capability within the organization;\n 7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and\n 8. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the incident response plan to **see additional FedRAMP Requirements and Guidance**;\n c. Reviews the incident response plan **at least annually**;\n d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;\n e. Communicates incident response plan changes to **see additional FedRAMP Requirements and Guidance**; and\nf. Protects the incident response plan from unauthorized disclosure and modification." - } - ] - }, - { - "title": "MAINTENANCE", - "controls": [ - { - "ref": "MA-1", - "title": "System Maintenance Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system maintenance policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system maintenance policy and associated system maintenance controls; and\n b. Reviews and updates the current:\n 1. System maintenance policy **at least every 3 years**; and\n 2. System maintenance procedures **at least annually**." - }, - { - "ref": "MA-2", - "title": "Controlled Maintenance", - "summary": "The organization:\n a. Schedules, performs, documents, and reviews records of maintenance and repairs on information system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\n b. Approves and monitors all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location;\n c. Requires that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the information system or system components from organizational facilities for off-site maintenance or repairs;\n d. Sanitizes equipment to remove all information from associated media prior to removal from organizational facilities for off-site maintenance or repairs;\n e. Checks all potentially impacted security controls to verify that the controls are still functioning properly following maintenance or repair actions; and\n f. Includes [Assignment: organization-defined maintenance-related information] in organizational maintenance records." - }, - { - "ref": "MA-4", - "title": "Nonlocal Maintenance", - "summary": "The organization:\n a. Approves and monitors nonlocal maintenance and diagnostic activities;\n b. Allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system;\n c. Employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions;\n d. Maintains records for nonlocal maintenance and diagnostic activities; and\n e. Terminates session and network connections when nonlocal maintenance is completed." - }, - { - "ref": "MA-5", - "title": "Maintenance Personnel", - "summary": "The organization:\n a. Establishes a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel;\n b. Ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and\n c. Designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations." - } - ] - }, - { - "title": "MEDIA PROTECTION", - "controls": [ - { - "ref": "MP-1", - "title": "Media Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A media protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the media protection policy and associated media protection controls; and\n b. Reviews and updates the current:\n 1. Media protection policy **at least every 3 years**; and\n 2. Media protection procedures **at least annually**." - }, - { - "ref": "MP-2", - "title": "Media Access", - "summary": "The organization restricts access to [Assignment: organization-defined types of digital and/or non-digital media] to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "MP-6", - "title": "Media Sanitization", - "summary": "The organization:\n a. Sanitizes [Assignment: organization-defined information system media] prior to disposal, release out of organizational control, or release for reuse using [Assignment: organization- defined sanitization techniques and procedures] in accordance with applicable federal and organizational standards and policies; and\n b. Employs sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information." - }, - { - "ref": "MP-7", - "title": "Media Use", - "summary": "The organization [Selection: restricts; prohibits] the use of [Assignment: organization- defined types of information system media] on [Assignment: organization-defined information systems or system components] using [Assignment: organization-defined security safeguards]." - } - ] - }, - { - "title": "PHYSICAL AND ENVIRONMENTAL PROTECTION", - "controls": [ - { - "ref": "PE-1", - "title": "Physical and Environmental Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A physical and environmental protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the physical and environmental protection policy and associated physical and environmental protection controls; and\n b. Reviews and updates the current:\n 1. Physical and environmental protection policy **at least every 3 years**; and\n 2. Physical and environmental protection procedures **at least annually**." - }, - { - "ref": "PE-2", - "title": "Physical Access Authorizations", - "summary": "The organization:\n a. Develops, approves, and maintains a list of individuals with authorized access to the facility where the information system resides;\n b. Issues authorization credentials for facility access;\n c. Reviews the access list detailing authorized facility access by individuals **at least annually**; and\n d. Removes individuals from the facility access list when access is no longer required." - }, - { - "ref": "PE-3", - "title": "Physical Access Control", - "summary": "The organization:\n a. Enforces physical access authorizations at [Assignment: organization-defined entry/exit points to the facility where the information system resides] by;\n 1. Verifying individual access authorizations before granting access to the facility; and\n 2. Controlling ingress/egress to the facility using [Selection (one or more): **CSP defined physical access control systems/devices AND guards**; guards];\n b. Maintains physical access audit logs for [Assignment: organization-defined entry/exit points];\n c. Provides [Assignment: organization-defined security safeguards] to control access to areas within the facility officially designated as publicly accessible;\n d. Escorts visitors and monitors visitor activity **in all circumstances within restricted access area where the information system resides**;\n e. Secures keys, combinations, and other physical access devices;\n f. Inventories **at least annually** every [Assignment: organization-defined frequency]; and\n g. Changes combinations and keys **at least annually** and/or when keys are lost, combinations are compromised, or individuals are transferred or terminated." - }, - { - "ref": "PE-6", - "title": "Monitoring Physical Access", - "summary": "The organization:\n a. Monitors physical access to the facility where the information system resides to detect and respond to physical security incidents;\n b. Reviews physical access logs **at least monthly** and upon occurrence of [Assignment: organization-defined events or potential indications of events]; and\n c. Coordinates results of reviews and investigations with the organizational incident response capability." - }, - { - "ref": "PE-8", - "title": "Visitor Access Records", - "summary": "The organization:\n a. Maintains visitor access records to the facility where the information system resides for **for a minimum of one (1) year**; and\n b. Reviews visitor access records **at least monthly**." - }, - { - "ref": "PE-12", - "title": "Emergency Lighting", - "summary": "The organization employs and maintains automatic emergency lighting for the information system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility." - }, - { - "ref": "PE-13", - "title": "Fire Protection", - "summary": "The organization employs and maintains fire suppression and detection devices/systems for the information system that are supported by an independent energy source." - }, - { - "ref": "PE-14", - "title": "Temperature and Humidity Controls", - "summary": "The organization:\n a. Maintains temperature and humidity levels within the facility where the information system resides at **consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments**; and\n b. Monitors temperature and humidity levels **continuously**." - }, - { - "ref": "PE-15", - "title": "Water Damage Protection", - "summary": "The organization protects the information system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel." - }, - { - "ref": "PE-16", - "title": "Delivery and Removal", - "summary": "The organization authorizes, monitors, and controls **all information system components** entering and exiting the facility and maintains records of those items." - } - ] - }, - { - "title": "PLANNING", - "controls": [ - { - "ref": "PL-1", - "title": "Security Planning Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and\n b. Reviews and updates the current:\n 1. Security planning policy **at least every 3 years**; and\n 2. Security planning procedures **at least annually**." - }, - { - "ref": "PL-2", - "title": "System Security Plan", - "summary": "The organization:\n a. Develops a security plan for the information system that:\n 1. Is consistent with the organization’s enterprise architecture;\n 2. Explicitly defines the authorization boundary for the system;\n 3. Describes the operational context of the information system in terms of missions and business processes;\n 4. Provides the security categorization of the information system including supporting rationale;\n 5. Describes the operational environment for the information system and relationships with or connections to other information systems;\n 6. Provides an overview of the security requirements for the system;\n 7. Identifies any relevant overlays, if applicable;\n 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and\n 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;\n b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles];\n c. Reviews the security plan for the information system **at least annually**;\n d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and\n e. Protects the security plan from unauthorized disclosure and modification." - }, - { - "ref": "PL-4", - "title": "Rules of Behavior", - "summary": "The organization:\n a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage;\n b. Receives a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system;\n c. Reviews and updates the rules of behavior **At least every 3 years**; and d. Requires individuals who have signed a previous version of the rules of behavior to read and\nresign when the rules of behavior are revised/updated." - } - ] - }, - { - "title": "PERSONNEL SECURITY", - "controls": [ - { - "ref": "PS-1", - "title": "Personnel Security Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A personnel security policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the personnel security policy and associated personnel security controls; and\n b. Reviews and updates the current:\n 1. Personnel security policy **at least every 3 years**; and\n 2. Personnel security procedures **at least annually**." - }, - { - "ref": "PS-2", - "title": "Position Risk Designation", - "summary": "The organization:\n a. Assigns a risk designation to all organizational positions;\n b. Establishes screening criteria for individuals filling those positions; and\n c. Reviews and updates position risk designations **at least every three years**." - }, - { - "ref": "PS-3", - "title": "Personnel Screening", - "summary": "The organization:\n a. Screens individuals prior to authorizing access to the information system; and\n b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening]." - }, - { - "ref": "PS-4", - "title": "Personnel Termination", - "summary": "The organization, upon termination of individual employment:\n a. Disables information system access within **same day**;\n b. Terminates/revokes any authenticators/credentials associated with the individual;\n c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics];\n d. Retrieves all security-related organizational information system-related property;\n e. Retains access to organizational information and information systems formerly controlled by terminated individual; and\n f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]." - }, - { - "ref": "PS-5", - "title": "Personnel Transfer", - "summary": "The organization:\n a. Reviews and confirms ongoing operational need for current logical and physical access authorizations to information systems/facilities when individuals are reassigned or transferred to other positions within the organization;\n b. Initiates [Assignment: organization-defined transfer or reassignment actions] within [Assignment: organization-defined time period following the formal transfer action];\n c. Modifies access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and\n d. Notifies **five days of the time period following the formal transfer action (DoD 24 hours)** within [Assignment: organization-defined time period]." - }, - { - "ref": "PS-6", - "title": "Access Agreements", - "summary": "The organization:\n a. Develops and documents access agreements for organizational information systems;\n b. Reviews and updates the access agreements **at least annually**; and\n c. Ensures that individuals requiring access to organizational information and information systems:\n 1. Sign appropriate access agreements prior to being granted access; and\n 2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or **at least annually**." - }, - { - "ref": "PS-7", - "title": "Third-Party Personnel Security", - "summary": "The organization:\n a. Establishes personnel security requirements including security roles and responsibilities for third-party providers;\n b. Requires third-party providers to comply with personnel security policies and procedures established by the organization;\n c. Documents personnel security requirements;\n d. Requires third-party providers to notify **organization-defined time period – same day** of any personnel transfers or terminations of third-party personnel who possess organizational credentials and/or badges, or who have information system privileges within [Assignment: organization-defined time period]; and\n e. Monitors provider compliance." - }, - { - "ref": "PS-8", - "title": "Personnel Sanctions", - "summary": "The organization:\n a. Employs a formal sanctions process for individuals failing to comply with established information security policies and procedures; and\n b. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction." - } - ] - }, - { - "title": "RISK ASSESSMENT", - "controls": [ - { - "ref": "RA-1", - "title": "Risk Assessment Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the risk assessment policy and associated risk assessment controls; and\n b. Reviews and updates the current:\n 1. Risk assessment policy **at least every 3 years**; and\n 2. Risk assessment procedures **at least annually**." - }, - { - "ref": "RA-2", - "title": "Security Categorization", - "summary": "The organization:\n a. Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Documents the security categorization results (including supporting rationale) in the security plan for the information system; and\n c. Ensures that the security categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative." - }, - { - "ref": "RA-3", - "title": "Risk Assessment", - "summary": "The organization:\n a. Conducts an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits;\n b. Documents risk assessment results in [Selection: security plan; risk assessment report; **security assessment report**];\n c. Reviews risk assessment results **at least every three (3) years or when a significant change occurs**;\n d. Disseminates risk assessment results to [Assignment: organization-defined personnel or roles]; and\n e. Updates the risk assessment **at least every three (3) years or when a significant change occurs** or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system." - }, - { - "ref": "RA-5", - "title": "Vulnerability Scanning", - "summary": "The organization:\n a. Scans for vulnerabilities in the information system and hosted applications **monthly operating system/infrastructure; monthly web applications and databases** and when new vulnerabilities potentially affecting the system/applications are identified and reported;\n b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n 1. Enumerating platforms, software flaws, and improper configurations;\n 2. Formatting checklists and test procedures; and\n 3. Measuring vulnerability impact;\n c. Analyzes vulnerability scan reports and results from security control assessments;\n d. Remediates legitimate vulnerabilities **high-risk vulnerabilities mitigated within thirty days from date of discovery; moderate-risk vulnerabilities mitigated within ninety days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery**, in accordance with an organizational assessment of risk; and\n e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies)." - } - ] - }, - { - "title": "SYSTEM AND SERVICES ACQUISITION", - "controls": [ - { - "ref": "SA-1", - "title": "System and Services Acquisition Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and services acquisition policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls; and\n b. Reviews and updates the current:\n 1. System and services acquisition policy **at least every 3 years**; and\n 2. System and services acquisition procedures **at least annually**." - }, - { - "ref": "SA-2", - "title": "Allocation of Resources", - "summary": "The organization:\n a. Determines information security requirements for the information system or information system service in mission/business process planning;\n b. Determines, documents, and allocates the resources required to protect the information system or information system service as part of its capital planning and investment control process; and\n c. Establishes a discrete line item for information security in organizational programming and budgeting documentation." - }, - { - "ref": "SA-3", - "title": "System Development Life Cycle", - "summary": "The organization:\n a. Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;\n b. Defines and documents information security roles and responsibilities throughout the system development life cycle;\n c. Identifies individuals having information security roles and responsibilities; and\n d. Integrates the organizational information security risk management process into system development life cycle activities." - }, - { - "ref": "SA-4", - "title": "Acquisition Process", - "summary": "The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs:\n a. Security functional requirements;\n b. Security strength requirements;\n c. Security assurance requirements;\n d. Security-related documentation requirements;\n e. Requirements for protecting security-related documentation;\n f. Description of the information system development environment and environment in which the system is intended to operate; and\n g. Acceptance criteria." - }, - { - "ref": "SA-5", - "title": "Information System Documentation", - "summary": "The organization:\n a. Obtains administrator documentation for the information system, system component, or information system service that describes:\n 1. Secure configuration, installation, and operation of the system, component, or service;\n 2. Effective use and maintenance of security functions/mechanisms; and\n 3. Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions;\n b. Obtains user documentation for the information system, system component, or information system service that describes:\n 1. User-accessible security functions/mechanisms and how to effectively use those security functions/mechanisms;\n 2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner; and\n 3. User responsibilities in maintaining the security of the system, component, or service;\n c. Documents attempts to obtain information system, system component, or information system service documentation when such documentation is either unavailable or nonexistent and [Assignment: organization-defined actions] in response;\n d. Protects documentation as required, in accordance with the risk management strategy; and e. Distributes documentation to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SA-9", - "title": "External Information System Services", - "summary": "The organization:\n a. Requires that providers of external information system services comply with organizational information security requirements and employ **FedRAMP Security Controls Baseline(s) if Federal information is processed or stored within the external system** in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and\n c. Employs **Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored** to monitor security control compliance by external service providers on an ongoing basis." - } - ] - }, - { - "title": "SYSTEM AND COMMUNICATIONS PROTECTION", - "controls": [ - { - "ref": "SC-1", - "title": "System and Communications Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and communications protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and communications protection policy and associated system and communications protection controls; and\n b. Reviews and updates the current:\n 1. System and communications protection policy **at least every 3 years**; and\n 2. System and communications protection procedures **at least annually**." - }, - { - "ref": "SC-5", - "title": "Denial of Service Protection", - "summary": "The information system protects against or limits the effects of the following types of denial of service attacks: [Assignment: organization-defined types of denial of service attacks or reference to source for such information] by employing [Assignment: organization-defined security safeguards]." - }, - { - "ref": "SC-7", - "title": "Boundary Protection", - "summary": "The information system:\n a. Monitors and controls communications at the external boundary of the system and at key internal boundaries within the system;\n b. Implements subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and\n c. Connects to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture." - }, - { - "ref": "SC-12", - "title": "Cryptographic Key Establishment and Management", - "summary": "The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]." - }, - { - "ref": "SC-13", - "title": "Cryptographic Protection", - "summary": "The information system implements **FIPS-validated or NSA-approved cryptography** in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards." - }, - { - "ref": "SC-15", - "title": "Collaborative Computing Devices", - "summary": "The information system:\n a. Prohibits remote activation of collaborative computing devices with the following exceptions: **no exceptions**; and\n b. Provides an explicit indication of use to users physically present at the devices." - }, - { - "ref": "SC-20", - "title": "Secure Name /Address Resolution Service (Authoritative Source)", - "summary": "The information system:\n a. Provides additional data origin and integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and\n b. Provides the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace." - }, - { - "ref": "SC-21", - "title": "Secure Name /Address Resolution Service (Recursive or Caching Resolver)", - "summary": "The information system requests and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources." - }, - { - "ref": "SC-22", - "title": "Architecture and Provisioning for Name/Address Resolution Service", - "summary": "The information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation." - }, - { - "ref": "SC-39", - "title": "Process Isolation", - "summary": "The information system maintains a separate execution domain for each executing process." - } - ] - }, - { - "title": "SYSTEM AND INFORMATION INTEGRITY", - "controls": [ - { - "ref": "SI-1", - "title": "System and Information Integrity Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and information integrity policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and information integrity policy and associated system and information integrity controls; and\n b. Reviews and updates the current:\n 1. System and information integrity policy **at least every 3 years**; and\n 2. System and information integrity procedures **at least annually**." - }, - { - "ref": "SI-2", - "title": "Flaw Remediation", - "summary": "The organization:\na. Identifies, reports, and corrects information system flaws;\nb. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;\nc. Installs security-relevant software and firmware updates within **thirty (30) days of release of updates** of the release of the updates; and\nd. Incorporates flaw remediation into the organizational configuration management process." - }, - { - "ref": "SI-3", - "title": "Malicious Code Protection", - "summary": "The organization:\n a. Employs malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code;\n b. Updates malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures;\n c. Configures malicious code protection mechanisms to:\n 1. Perform periodic scans of the information system **at least weekly** and real-time scans of files from external sources at [Selection (one or more); endpoint; network entry/exit points] as the files are downloaded, opened, or executed in accordance with organizational security policy; and\n 2. [Selection (one or more): block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined action, **to include alerting administrator or defined security personnel**]] in response to malicious code detection; and\n d. Addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system." - }, - { - "ref": "SI-4", - "title": "Information System Monitoring", - "summary": "The organization:\n a. Monitors the information system to detect:\n 1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and\n 2. Unauthorized local, network, and remote connections;\n b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods];\n c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;\n d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;\n e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;\n f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and\n g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]]." - }, - { - "ref": "SI-5", - "title": "Security Alerts, Advisories, and Directives", - "summary": "The organization:\n a. Receives information system security alerts, advisories, and directives from [Assignment: organization-defined external organizations, **to include US-CERT**] on an ongoing basis;\n b. Generates internal security alerts, advisories, and directives as deemed necessary;\n c. Disseminates security alerts, advisories, and directives to: [Selection (one or more): [Assignment: organization-defined personnel or roles, **to include system security personnel and administrators with configuration/patch-management responsibilities**]; [Assignment: organization-defined elements within the organization]; [Assignment: organization-defined external organizations]]; and\n d. Implements security directives in accordance with established time frames, or notifies the issuing organization of the degree of noncompliance." - }, - { - "ref": "SI-12", - "title": "Information Handling and Retention", - "summary": "The organization handles and retains information within the information system and information output from the system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and operational requirements." - }, - { - "ref": "SI-16", - "title": "Memory Protection", - "summary": "The information system implements [Assignment: organization-defined security safeguards] to protect its memory from unauthorized code execution." + "standard": "FedRAMP Rev 5 Low Baseline", + "version": "Rev 5", + "basedOn": "fedramp-2.0.0-oscal1.0.4", + "webLink": "https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_LOW-baseline-resolved-profile_catalog.json", + "domains": [ + { + "title": "Access Control", + "controls": [ + { + "ref": "AC-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} access control policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the access control policy and the associated access controls;\nb. Designate an {{ official - an official to manage the access control policy and procedures is defined; }} to manage the development, documentation, and dissemination of the access control policy and procedures; and\nc. Review and update the current access control:\n1. Policy at least every 3 years and following {{ events - events that would require the current access control policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AC-2", + "title": "Account Management", + "summary": "Account Management\na. Define and document the types of accounts allowed and specifically prohibited for use within the system;\nb. Assign account managers;\nc. Require {{ prerequisites and criteria - prerequisites and criteria for group and role membership are defined; }} for group and role membership;\nd. Specify:\n1. Authorized users of the system;\n2. Group and role membership; and\n3. Access authorizations (i.e., privileges) and {{ attributes (as required) - attributes (as required) for each account are defined; }} for each account;\ne. Require approvals by {{ personnel or roles - personnel or roles required to approve requests to create accounts is/are defined; }} for requests to create accounts;\nf. Create, enable, modify, disable, and remove accounts in accordance with {{ policy, procedures, prerequisites, and criteria - policy, procedures, prerequisites, and criteria for account creation, enabling, modification, disabling, and removal are defined; }};\ng. Monitor the use of accounts;\nh. Notify account managers and {{ personnel or roles - personnel or roles to be notified is/are defined; }} within:\n1. twenty-four (24) hours when accounts are no longer required;\n2. eight (8) hours when users are terminated or transferred; and\n3. eight (8) hours when system usage or need-to-know changes for an individual;\ni. Authorize access to the system based on:\n1. A valid access authorization;\n2. Intended system usage; and\n3. {{ attributes (as required) - attributes needed to authorize system access (as required) are defined; }};\nj. Review accounts for compliance with account management requirements at least annually;\nk. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and\nl. Align account management processes with personnel termination and transfer processes.", + "guidance": "Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.\n\nWhere access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.\n\nTemporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training." + }, + { + "ref": "AC-3", + "title": "Access Enforcement", + "summary": "Access Enforcement\nEnforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.", + "guidance": "Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection ( [PE] ) family." + }, + { + "ref": "AC-7", + "title": "Unsuccessful Logon Attempts", + "summary": "Unsuccessful Logon Attempts\na. Enforce a limit of {{ number - the number of consecutive invalid logon attempts by a user allowed during a time period is defined; }} consecutive invalid logon attempts by a user during a {{ time period - the time period to which the number of consecutive invalid logon attempts by a user is limited is defined; }} ; and\nb. Automatically {{ one or more: lock the account or node for {{ time period - time period for an account or node to be locked is defined (if selected); }} , lock the account or node until released by an administrator, delay next logon prompt per {{ delay algorithm - delay algorithm for the next logon prompt is defined (if selected); }} , notify system administrator, take other {{ action - other action to be taken when the maximum number of unsuccessful attempts is exceeded is defined (if selected); }} }} when the maximum number of unsuccessful attempts is exceeded.\nAC-7 Additional FedRAMP Requirements and Guidance Requirement: In alignment with NIST SP 800-63B", + "guidance": "The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need." + }, + { + "ref": "AC-8", + "title": "System Use Notification", + "summary": "System Use Notification\na. Display see additional Requirements and Guidance to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:\n1. Users are accessing a U.S. Government system;\n2. System usage may be monitored, recorded, and subject to audit;\n3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and\n4. Use of the system indicates consent to monitoring and recording;\nb. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and\nc. For publicly accessible systems:\n1. Display system use information see additional Requirements and Guidance , before granting further access to the publicly accessible system;\n2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and\n3. Include a description of the authorized uses of the system.\nAC-8 Additional FedRAMP Requirements and Guidance Requirement: If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO.", + "guidance": "System use notifications can be implemented using messages or warning banners displayed before individuals log in to systems. System use notifications are used only for access via logon interfaces with human users. Notifications are not required when human interfaces do not exist. Based on an assessment of risk, organizations consider whether or not a secondary system use notification is needed to access applications or other system resources after the initial network logon. Organizations consider system use notification messages or banners displayed in multiple languages based on organizational needs and the demographics of system users. Organizations consult with the privacy office for input regarding privacy messaging and the Office of the General Counsel or organizational equivalent for legal review and approval of warning banner content." + }, + { + "ref": "AC-14", + "title": "Permitted Actions Without Identification or Authentication", + "summary": "Permitted Actions Without Identification or Authentication\na. Identify {{ user actions - user actions that can be performed on the system without identification or authentication are defined; }} that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and\nb. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.", + "guidance": "Specific user actions may be permitted without identification or authentication if organizations determine that identification and authentication are not required for the specified user actions. Organizations may allow a limited number of user actions without identification or authentication, including when individuals access public websites or other publicly accessible federal systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations identify actions that normally require identification or authentication but may, under certain circumstances, allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. Permitting actions without identification or authentication does not apply to situations where identification and authentication have already occurred and are not repeated but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational systems without identification and authentication, and therefore, the value for the assignment operation can be \"none.\" " + }, + { + "ref": "AC-17", + "title": "Remote Access", + "summary": "Remote Access\na. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\nb. Authorize each type of remote access to the system prior to allowing such connections.", + "guidance": "Remote access is access to organizational systems (or processes acting on behalf of users) that communicate through external networks such as the Internet. Types of remote access include dial-up, broadband, and wireless. Organizations use encrypted virtual private networks (VPNs) to enhance confidentiality and integrity for remote connections. The use of encrypted VPNs provides sufficient assurance to the organization that it can effectively treat such connections as internal networks if the cryptographic mechanisms used are implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. VPNs with encrypted tunnels can also affect the ability to adequately monitor network communications traffic for malicious code. Remote access controls apply to systems other than public web servers or systems designed for public access. Authorization of each remote access type addresses authorization prior to allowing remote access without specifying the specific formats for such authorization. While organizations may use information exchange and system connection security agreements to manage remote access connections to other systems, such agreements are addressed as part of [CA-3] . Enforcing access restrictions for remote access is addressed via [AC-3]." + }, + { + "ref": "AC-18", + "title": "Wireless Access", + "summary": "Wireless Access\na. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and\nb. Authorize each type of wireless access to the system prior to allowing such connections.", + "guidance": "Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. Wireless networks use authentication protocols that provide authenticator protection and mutual authentication." + }, + { + "ref": "AC-19", + "title": "Access Control for Mobile Devices", + "summary": "Access Control for Mobile Devices\na. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and\nb. Authorize the connection of mobile devices to organizational systems.", + "guidance": "A mobile device is a computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile device functionality may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of notebook/desktop systems, depending on the nature and intended purpose of the device. Protection and control of mobile devices is behavior or policy-based and requires users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which organizations provide physical or procedural controls to meet the requirements established for protecting information and systems.\n\nDue to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions and specific implementation guidance for mobile devices include configuration management, device identification and authentication, implementation of mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware.\n\nUsage restrictions and authorization to connect may vary among organizational systems. For example, the organization may authorize the connection of mobile devices to its network and impose a set of usage restrictions, while a system owner may withhold authorization for mobile device connection to specific applications or impose additional usage restrictions before allowing mobile device connections to a system. Adequate security for mobile devices goes beyond the requirements specified in [AC-19] . Many safeguards for mobile devices are reflected in other controls. [AC-20] addresses mobile devices that are not organization-controlled." + }, + { + "ref": "AC-20", + "title": "Use of External Systems", + "summary": "Use of External Systems\na. {{ one or more: establish {{ terms and conditions - terms and conditions consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems are defined (if selected); }} , identify {{ controls asserted - controls asserted to be implemented on external systems consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems are defined (if selected); }} }} , consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:\n1. Access the system from external systems; and\n2. Process, store, or transmit organization-controlled information using external systems; or\nb. Prohibit the use of {{ prohibited types of external systems - types of external systems prohibited from use are defined; }}.\nAC-20 Additional FedRAMP Requirements and Guidance ", + "guidance": "External systems are systems that are used by but not part of organizational systems, and for which the organization has no direct control over the implementation of required controls or the assessment of control effectiveness. External systems include personally owned systems, components, or devices; privately owned computing and communications devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; systems managed by contractors; and federal information systems that are not owned by, operated by, or under the direct supervision or authority of the organization. External systems also include systems owned or operated by other components within the same organization and systems within the organization with different authorization boundaries. Organizations have the option to prohibit the use of any type of external system or prohibit the use of specified types of external systems, (e.g., prohibit the use of any external system that is not organizationally owned or prohibit the use of personally-owned systems).\n\nFor some external systems (i.e., systems operated by other organizations), the trust relationships that have been established between those organizations and the originating organization may be such that no explicit terms and conditions are required. Systems within these organizations may not be considered external. These situations occur when, for example, there are pre-existing information exchange agreements (either implicit or explicit) established between organizations or components or when such agreements are specified by applicable laws, executive orders, directives, regulations, policies, or standards. Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to organizational systems and over which organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals need not be uniform, as the restrictions may vary depending on trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments.\n\nExternal systems used to access public interfaces to organizational systems are outside the scope of [AC-20] . Organizations establish specific terms and conditions for the use of external systems in accordance with organizational security policies and procedures. At a minimum, terms and conditions address the specific types of applications that can be accessed on organizational systems from external systems and the highest security category of information that can be processed, stored, or transmitted on external systems. If the terms and conditions with the owners of the external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems." + }, + { + "ref": "AC-22", + "title": "Publicly Accessible Content", + "summary": "Publicly Accessible Content\na. Designate individuals authorized to make information publicly accessible;\nb. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\nc. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and\nd. Review the content on the publicly accessible system for nonpublic information at least quarterly and remove such information, if discovered.", + "guidance": "In accordance with applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the public is not authorized to have access to nonpublic information, including information protected under the [PRIVACT] and proprietary information. Publicly accessible content addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Posting information on non-organizational systems (e.g., non-organizational public websites, forums, and social media) is covered by organizational policy. While organizations may have individuals who are responsible for developing and implementing policies about the information that can be made publicly accessible, publicly accessible content addresses the management of the individuals who make such information publicly accessible." + } + ] + }, + { + "title": "Awareness and Training", + "controls": [ + { + "ref": "AT-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} awareness and training policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the awareness and training policy and the associated awareness and training controls;\nb. Designate an {{ official - an official to manage the awareness and training policy and procedures is defined; }} to manage the development, documentation, and dissemination of the awareness and training policy and procedures; and\nc. Review and update the current awareness and training:\n1. Policy at least every 3 years and following {{ events - events that would require the current awareness and training policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Awareness and training policy and procedures address the controls in the AT family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of awareness and training policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to awareness and training policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AT-2", + "title": "Literacy Training and Awareness", + "summary": "Literacy Training and Awareness\na. Provide security and privacy literacy training to system users (including managers, senior executives, and contractors):\n1. As part of initial training for new users and at least annually thereafter; and\n2. When required by system changes or following {{ organization-defined events }};\nb. Employ the following techniques to increase the security and privacy awareness of system users {{ awareness techniques - techniques to be employed to increase the security and privacy awareness of system users are defined; }};\nc. Update literacy training and awareness content at least annually and following {{ events - events that would require literacy training and awareness content to be updated are defined; }} ; and\nd. Incorporate lessons learned from internal or external security incidents or breaches into literacy training and awareness techniques.\ncontrols AT-2(2) Insider Threat\nProvide literacy training on recognizing and reporting potential indicators of insider threat.", + "guidance": "Organizations provide basic and advanced levels of literacy training to system users, including measures to test the knowledge level of users. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and privacy as well as actions by users to maintain security and personal privacy and to respond to suspected incidents. The content addresses the need for operations security and the handling of personally identifiable information.\n\nAwareness techniques include displaying posters, offering supplies inscribed with security and privacy reminders, displaying logon screen messages, generating email advisories or notices from organizational officials, and conducting awareness events. Literacy training after the initial training described in [AT-2a.1] is conducted at a minimum frequency consistent with applicable laws, directives, regulations, and policies. Subsequent literacy training may be satisfied by one or more short ad hoc sessions and include topical information on recent attack schemes, changes to organizational security and privacy policies, revised security and privacy expectations, or a subset of topics from the initial training. Updating literacy training and awareness content on a regular basis helps to ensure that the content remains relevant. Events that may precipitate an update to literacy training and awareness content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "AT-3", + "title": "Role-based Training", + "summary": "Role-based Training\na. Provide role-based security and privacy training to personnel with the following roles and responsibilities: {{ organization-defined roles and responsibilities }}:\n1. Before authorizing access to the system, information, or performing assigned duties, and at least annually thereafter; and\n2. When required by system changes;\nb. Update role-based training content at least annually and following {{ events - events that require role-based training content to be updated are defined; }} ; and\nc. Incorporate lessons learned from internal or external security incidents or breaches into role-based training.", + "guidance": "Organizations determine the content of training based on the assigned roles and responsibilities of individuals as well as the security and privacy requirements of organizations and the systems to which personnel have authorized access, including technical training specifically tailored for assigned duties. Roles that may require role-based training include senior leaders or management officials (e.g., head of agency/chief executive officer, chief information officer, senior accountable official for risk management, senior agency information security officer, senior agency official for privacy), system owners; authorizing officials; system security officers; privacy officers; acquisition and procurement officials; enterprise architects; systems engineers; software developers; systems security engineers; privacy engineers; system, network, and database administrators; auditors; personnel conducting configuration management activities; personnel performing verification and validation activities; personnel with access to system-level software; control assessors; personnel with contingency planning and incident response duties; personnel with privacy management responsibilities; and personnel with access to personally identifiable information.\n\nComprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls. Role-based training also includes policies, procedures, tools, methods, and artifacts for the security and privacy roles defined. Organizations provide the training necessary for individuals to fulfill their responsibilities related to operations and supply chain risk management within the context of organizational security and privacy programs. Role-based training also applies to contractors who provide services to federal agencies. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Updating role-based training on a regular basis helps to ensure that the content remains relevant and effective. Events that may precipitate an update to role-based training content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "AT-4", + "title": "Training Records", + "summary": "Training Records\na. Document and monitor information security and privacy training activities, including security and privacy awareness training and specific role-based security and privacy training; and\nb. Retain individual training records for at least one (1) year or 1 year after completion of a specific training program.", + "guidance": "Documentation for specialized training may be maintained by individual supervisors at the discretion of the organization. The National Archives and Records Administration provides guidance on records retention for federal agencies." + } + ] + }, + { + "title": "Audit and Accountability", + "controls": [ + { + "ref": "AU-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} audit and accountability policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the audit and accountability policy and the associated audit and accountability controls;\nb. Designate an {{ official - an official to manage the audit and accountability policy and procedures is defined; }} to manage the development, documentation, and dissemination of the audit and accountability policy and procedures; and\nc. Review and update the current audit and accountability:\n1. Policy at least every 3 years and following {{ events - events that would require the current audit and accountability policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Audit and accountability policy and procedures address the controls in the AU family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of audit and accountability policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to audit and accountability policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AU-2", + "title": "Event Logging", + "summary": "Event Logging\na. Identify the types of events that the system is capable of logging in support of the audit function: successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes;\nb. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;\nc. Specify the following event types for logging within the system: organization-defined subset of the auditable events defined in AU-2a to be audited continually for each identified event.;\nd. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and\ne. Review and update the event types selected for logging annually and whenever there is a change in the threat environment.\nAU-2 Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.", + "guidance": "An event is an observable occurrence in a system. The types of events that require logging are those events that are significant and relevant to the security of systems and the privacy of individuals. Event logging also supports specific monitoring and auditing needs. Event types include password changes, failed logons or failed accesses related to systems, security or privacy attribute changes, administrative privilege usage, PIV credential usage, data action changes, query parameters, or external credential usage. In determining the set of event types that require logging, organizations consider the monitoring and auditing appropriate for each of the controls to be implemented. For completeness, event logging includes all protocols that are operational and supported by the system.\n\nTo balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. The types of events that organizations desire to be logged may change. Reviewing and updating the set of logged events is necessary to help ensure that the events remain relevant and continue to support the needs of the organization. Organizations consider how the types of logging events can reveal information about individuals that may give rise to privacy risk and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the logging event is based on patterns or time of usage.\n\nEvent logging requirements, including the need to log specific event types, may be referenced in other controls and control enhancements. These include [AC-2(4)], [AC-3(10)], [AC-6(9)], [AC-17(1)], [CM-3f], [CM-5(1)], [IA-3(3)(b)], [MA-4(1)], [MP-4(2)], [PE-3], [PM-21], [PT-7], [RA-8], [SC-7(9)], [SC-7(15)], [SI-3(8)], [SI-4(22)], [SI-7(8)] , and [SI-10(1)] . Organizations include event types that are required by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Audit records can be generated at various levels, including at the packet level as information traverses the network. Selecting the appropriate level of event logging is an important part of a monitoring and auditing capability and can identify the root causes of problems. When defining event types, organizations consider the logging necessary to cover related event types, such as the steps in distributed, transaction-based processes and the actions that occur in service-oriented architectures." + }, + { + "ref": "AU-3", + "title": "Content of Audit Records", + "summary": "Content of Audit Records\nEnsure that audit records contain information that establishes the following:\na. What type of event occurred;\nb. When the event occurred;\nc. Where the event occurred;\nd. Source of the event;\ne. Outcome of the event; and\nf. Identity of any individuals, subjects, or objects/entities associated with the event.", + "guidance": "Audit record content that may be necessary to support the auditing function includes event descriptions (item a), time stamps (item b), source and destination addresses (item c), user or process identifiers (items d and f), success or fail indications (item e), and filenames involved (items a, c, e, and f) . Event outcomes include indicators of event success or failure and event-specific results, such as the system security and privacy posture after the event occurred. Organizations consider how audit records can reveal information about individuals that may give rise to privacy risks and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the trail records inputs or is based on patterns or time of usage." + }, + { + "ref": "AU-4", + "title": "Audit Log Storage Capacity", + "summary": "Audit Log Storage Capacity\nAllocate audit log storage capacity to accommodate {{ audit log retention requirements - audit log retention requirements are defined; }}.", + "guidance": "Organizations consider the types of audit logging to be performed and the audit log processing requirements when allocating audit log storage capacity. Allocating sufficient audit log storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of audit logging capability." + }, + { + "ref": "AU-5", + "title": "Response to Audit Logging Process Failures", + "summary": "Response to Audit Logging Process Failures\na. Alert {{ personnel or roles - personnel or roles receiving audit logging process failure alerts are defined; }} within {{ time period - time period for personnel or roles receiving audit logging process failure alerts is defined; }} in the event of an audit logging process failure; and\nb. Take the following additional actions: overwrite oldest record.", + "guidance": "Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Organization-defined actions include overwriting oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel." + }, + { + "ref": "AU-6", + "title": "Audit Record Review, Analysis, and Reporting", + "summary": "Audit Record Review, Analysis, and Reporting\na. Review and analyze system audit records at least weekly for indications of {{ inappropriate or unusual activity - inappropriate or unusual activity is defined; }} and the potential impact of the inappropriate or unusual activity;\nb. Report findings to {{ personnel or roles - personnel or roles to receive findings from reviews and analyses of system records is/are defined; }} ; and\nc. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.\nAU-6 Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO. In multi-tenant environments, capability and means for providing review, analysis, and reporting to consumer for data pertaining to consumer shall be documented.", + "guidance": "Audit record review, analysis, and reporting covers information security- and privacy-related logging performed by organizations, including logging that results from the monitoring of account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, use of maintenance tools and non-local maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at system interfaces, and use of mobile code or Voice over Internet Protocol (VoIP). Findings can be reported to organizational entities that include the incident response team, help desk, and security or privacy offices. If organizations are prohibited from reviewing and analyzing audit records or unable to conduct such activities, the review or analysis may be carried out by other organizations granted such authority. The frequency, scope, and/or depth of the audit record review, analysis, and reporting may be adjusted to meet organizational needs based on new information received." + }, + { + "ref": "AU-8", + "title": "Time Stamps", + "summary": "Time Stamps\na. Use internal system clocks to generate time stamps for audit records; and\nb. Record time stamps for audit records that meet one second granularity of time measurement and that use Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or that include the local time offset as part of the time stamp.", + "guidance": "Time stamps generated by the system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., clocks synchronizing within hundreds of milliseconds or tens of milliseconds). Organizations may define different time granularities for different system components. Time service can be critical to other security capabilities such as access control and identification and authentication, depending on the nature of the mechanisms used to support those capabilities." + }, + { + "ref": "AU-9", + "title": "Protection of Audit Information", + "summary": "Protection of Audit Information\na. Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and\nb. Alert {{ personnel or roles - personnel or roles to be alerted upon detection of unauthorized access, modification, or deletion of audit information is/are defined; }} upon detection of unauthorized access, modification, or deletion of audit information.", + "guidance": "Audit information includes all information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are those programs and devices used to conduct system audit and logging activities. Protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by both media protection controls and physical and environmental protection controls." + }, + { + "ref": "AU-11", + "title": "Audit Record Retention", + "summary": "Audit Record Retention\nRetain audit records for a time period in compliance with M-21-31 to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.\nAU-11 Additional FedRAMP Requirements and Guidance Requirement: The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf)", + "guidance": "Organizations retain audit records until it is determined that the records are no longer needed for administrative, legal, audit, or other operational purposes. This includes the retention and availability of audit records relative to Freedom of Information Act (FOIA) requests, subpoenas, and law enforcement actions. Organizations develop standard categories of audit records relative to such types of actions and standard response processes for each type of action. The National Archives and Records Administration (NARA) General Records Schedules provide federal policy on records retention." + }, + { + "ref": "AU-12", + "title": "Audit Record Generation", + "summary": "Audit Record Generation\na. Provide audit record generation capability for the event types the system is capable of auditing as defined in [AU-2a] on all information system and network components where audit capability is deployed/available;\nb. Allow {{ personnel or roles - personnel or roles allowed to select the event types that are to be logged by specific components of the system is/are defined; }} to select the event types that are to be logged by specific components of the system; and\nc. Generate audit records for the event types defined in [AU-2c] that include the audit record content defined in [AU-3].", + "guidance": "Audit records can be generated from many different system components. The event types specified in [AU-2d] are the event types for which audit logs are to be generated and are a subset of all event types for which the system can generate audit records." + } + ] + }, + { + "title": "Assessment, Authorization, and Monitoring", + "controls": [ + { + "ref": "CA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} assessment, authorization, and monitoring policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the assessment, authorization, and monitoring policy and the associated assessment, authorization, and monitoring controls;\nb. Designate an {{ official - an official to manage the assessment, authorization, and monitoring policy and procedures is defined; }} to manage the development, documentation, and dissemination of the assessment, authorization, and monitoring policy and procedures; and\nc. Review and update the current assessment, authorization, and monitoring:\n1. Policy at least every 3 years and following {{ events - events that would require the current assessment, authorization, and monitoring policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Assessment, authorization, and monitoring policy and procedures address the controls in the CA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of assessment, authorization, and monitoring policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to assessment, authorization, and monitoring policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CA-2", + "title": "Control Assessments", + "summary": "Control Assessments\na. Select the appropriate assessor or assessment team for the type of assessment to be conducted;\nb. Develop a control assessment plan that describes the scope of the assessment including:\n1. Controls and control enhancements under assessment;\n2. Assessment procedures to be used to determine control effectiveness; and\n3. Assessment environment, assessment team, and assessment roles and responsibilities;\nc. Ensure the control assessment plan is reviewed and approved by the authorizing official or designated representative prior to conducting the assessment;\nd. Assess the controls in the system and its environment of operation at least annually to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements;\ne. Produce a control assessment report that document the results of the assessment; and\nf. Provide the results of the control assessment to individuals or roles to include FedRAMP PMO.\nCA-2 Additional FedRAMP Requirements and Guidance \ncontrols CA-2(1) Independent Assessors\nEmploy independent assessors or assessment teams to conduct control assessments.", + "guidance": "Organizations ensure that control assessors possess the required skills and technical expertise to develop effective assessment plans and to conduct assessments of system-specific, hybrid, common, and program management controls, as appropriate. The required skills include general knowledge of risk management concepts and approaches as well as comprehensive knowledge of and experience with the hardware, software, and firmware system components implemented.\n\nOrganizations assess controls in systems and the environments in which those systems operate as part of initial and ongoing authorizations, continuous monitoring, FISMA annual assessments, system design and development, systems security engineering, privacy engineering, and the system development life cycle. Assessments help to ensure that organizations meet information security and privacy requirements, identify weaknesses and deficiencies in the system design and development process, provide essential information needed to make risk-based decisions as part of authorization processes, and comply with vulnerability mitigation procedures. Organizations conduct assessments on the implemented controls as documented in security and privacy plans. Assessments can also be conducted throughout the system development life cycle as part of systems engineering and systems security engineering processes. The design for controls can be assessed as RFPs are developed, responses assessed, and design reviews conducted. If a design to implement controls and subsequent implementation in accordance with the design are assessed during development, the final control testing can be a simple confirmation utilizing previously completed control assessment and aggregating the outcomes.\n\nOrganizations may develop a single, consolidated security and privacy assessment plan for the system or maintain separate plans. A consolidated assessment plan clearly delineates the roles and responsibilities for control assessment. If multiple organizations participate in assessing a system, a coordinated approach can reduce redundancies and associated costs.\n\nOrganizations can use other types of assessment activities, such as vulnerability scanning and system monitoring, to maintain the security and privacy posture of systems during the system life cycle. Assessment reports document assessment results in sufficient detail, as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting requirements. Assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of authorization decisions are provided to authorizing officials, senior agency officials for privacy, senior agency information security officers, and authorizing official designated representatives.\n\nTo satisfy annual assessment requirements, organizations can use assessment results from the following sources: initial or ongoing system authorizations, continuous monitoring, systems engineering processes, or system development life cycle activities. Organizations ensure that assessment results are current, relevant to the determination of control effectiveness, and obtained with the appropriate level of assessor independence. Existing control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. After the initial authorizations, organizations assess controls during continuous monitoring. Organizations also establish the frequency for ongoing assessments in accordance with organizational continuous monitoring strategies. External audits, including audits by external entities such as regulatory agencies, are outside of the scope of [CA-2]." + }, + { + "ref": "CA-3", + "title": "Information Exchange", + "summary": "Information Exchange\na. Approve and manage the exchange of information between the system and other systems using {{ one or more: interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service level agreements, user agreements, non-disclosure agreements, {{ type of agreement - the type of agreement used to approve and manage the exchange of information is defined (if selected); }} }};\nb. Document, as part of each exchange agreement, the interface characteristics, security and privacy requirements, controls, and responsibilities for each system, and the impact level of the information communicated; and\nc. Review and update the agreements at least annually and on input from JAB/AO.", + "guidance": "System information exchange requirements apply to information exchanges between two or more systems. System information exchanges include connections via leased lines or virtual private networks, connections to internet service providers, database sharing or exchanges of database transaction information, connections and exchanges with cloud services, exchanges via web-based services, or exchanges of files via file transfer protocols, network protocols (e.g., IPv4, IPv6), email, or other organization-to-organization communications. Organizations consider the risk related to new or increased threats that may be introduced when systems exchange information with other systems that may have different security and privacy requirements and controls. This includes systems within the same organization and systems that are external to the organization. A joint authorization of the systems exchanging information, as described in [CA-6(1)] or [CA-6(2)] , may help to communicate and reduce risk.\n\nAuthorizing officials determine the risk associated with system information exchange and the controls needed for appropriate risk mitigation. The types of agreements selected are based on factors such as the impact level of the information being exchanged, the relationship between the organizations exchanging information (e.g., government to government, government to business, business to business, government or business to service provider, government or business to individual), or the level of access to the organizational system by users of the other system. If systems that exchange information have the same authorizing official, organizations need not develop agreements. Instead, the interface characteristics between the systems (e.g., how the information is being exchanged. how the information is protected) are described in the respective security and privacy plans. If the systems that exchange information have different authorizing officials within the same organization, the organizations can develop agreements or provide the same information that would be provided in the appropriate agreement type from [CA-3a] in the respective security and privacy plans for the systems. Organizations may incorporate agreement information into formal contracts, especially for information exchanges established between federal agencies and nonfederal organizations (including service providers, contractors, system developers, and system integrators). Risk considerations include systems that share the same networks." + }, + { + "ref": "CA-5", + "title": "Plan of Action and Milestones", + "summary": "Plan of Action and Milestones\na. Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and\nb. Update existing plan of action and milestones at least monthly based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.\nCA-5 Additional FedRAMP Requirements and Guidance Requirement: POA&Ms must be provided at least monthly.", + "guidance": "Plans of action and milestones are useful for any type of organization to track planned remedial actions. Plans of action and milestones are required in authorization packages and subject to federal reporting requirements established by OMB." + }, + { + "ref": "CA-6", + "title": "Authorization", + "summary": "Authorization\na. Assign a senior official as the authorizing official for the system;\nb. Assign a senior official as the authorizing official for common controls available for inheritance by organizational systems;\nc. Ensure that the authorizing official for the system, before commencing operations:\n1. Accepts the use of common controls inherited by the system; and\n2. Authorizes the system to operate;\nd. Ensure that the authorizing official for common controls authorizes the use of those controls for inheritance by organizational systems;\ne. Update the authorizations in accordance with OMB A-130 requirements or when a significant change occurs.\nCA-6 Additional FedRAMP Requirements and Guidance ", + "guidance": "Authorizations are official management decisions by senior officials to authorize operation of systems, authorize the use of common controls for inheritance by organizational systems, and explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon controls. Authorizing officials provide budgetary oversight for organizational systems and common controls or assume responsibility for the mission and business functions supported by those systems or common controls. The authorization process is a federal responsibility, and therefore, authorizing officials must be federal employees. Authorizing officials are both responsible and accountable for security and privacy risks associated with the operation and use of organizational systems. Nonfederal organizations may have similar processes to authorize systems and senior officials that assume the authorization role and associated responsibilities.\n\nAuthorizing officials issue ongoing authorizations of systems based on evidence produced from implemented continuous monitoring programs. Robust continuous monitoring programs reduce the need for separate reauthorization processes. Through the employment of comprehensive continuous monitoring processes, the information contained in authorization packages (i.e., security and privacy plans, assessment reports, and plans of action and milestones) is updated on an ongoing basis. This provides authorizing officials, common control providers, and system owners with an up-to-date status of the security and privacy posture of their systems, controls, and operating environments. To reduce the cost of reauthorization, authorizing officials can leverage the results of continuous monitoring processes to the maximum extent possible as the basis for rendering reauthorization decisions." + }, + { + "ref": "CA-7", + "title": "Continuous Monitoring", + "summary": "Continuous Monitoring\nDevelop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes:\na. Establishing the following system-level metrics to be monitored: {{ system-level metrics - system-level metrics to be monitored are defined; }};\nb. Establishing {{ frequencies - frequencies at which to monitor control effectiveness are defined; }} for monitoring and {{ frequencies - frequencies at which to assess control effectiveness are defined; }} for assessment of control effectiveness;\nc. Ongoing control assessments in accordance with the continuous monitoring strategy;\nd. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy;\ne. Correlation and analysis of information generated by control assessments and monitoring;\nf. Response actions to address results of the analysis of control assessment and monitoring information; and\ng. Reporting the security and privacy status of the system to to include JAB/AO {{ organization-defined frequency }}.\nCA-7 Additional FedRAMP Requirements and Guidance Requirement: CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight. It does not apply to CSOs authorized via the JAB path because the JAB performs ConMon oversight.\ncontrols CA-7(4) Risk Monitoring\nEnsure risk monitoring is an integral part of the continuous monitoring strategy that includes the following:\n(a) Effectiveness monitoring;\n(b) Compliance monitoring; and\n(c) Change monitoring.", + "guidance": "Continuous monitoring at the system level facilitates ongoing awareness of the system security and privacy posture to support organizational risk management decisions. The terms \"continuous\" and \"ongoing\" imply that organizations assess and monitor their controls and risks at a frequency sufficient to support risk-based decisions. Different types of controls may require different monitoring frequencies. The results of continuous monitoring generate risk response actions by organizations. When monitoring the effectiveness of multiple controls that have been grouped into capabilities, a root-cause analysis may be needed to determine the specific control that has failed. Continuous monitoring programs allow organizations to maintain the authorizations of systems and common controls in highly dynamic environments of operation with changing mission and business needs, threats, vulnerabilities, and technologies. Having access to security and privacy information on a continuing basis through reports and dashboards gives organizational officials the ability to make effective and timely risk management decisions, including ongoing authorization decisions.\n\nAutomation supports more frequent updates to hardware, software, and firmware inventories, authorization packages, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of systems. Monitoring requirements, including the need for specific monitoring, may be referenced in other controls and control enhancements, such as [AC-2g], [AC-2(7)], [AC-2(12)(a)], [AC-2(7)(b)], [AC-2(7)(c)], [AC-17(1)], [AT-4a], [AU-13], [AU-13(1)], [AU-13(2)], [CM-3f], [CM-6d], [CM-11c], [IR-5], [MA-2b], [MA-3a], [MA-4a], [PE-3d], [PE-6], [PE-14b], [PE-16], [PE-20], [PM-6], [PM-23], [PM-31], [PS-7e], [SA-9c], [SR-4], [SC-5(3)(b)], [SC-7a], [SC-7(24)(b)], [SC-18b], [SC-43b] , and [SI-4]." + }, + { + "ref": "CA-8", + "title": "Penetration Testing", + "summary": "Penetration Testing\nConduct penetration testing at least annually on {{ system(s) or system components - systems or system components on which penetration testing is to be conducted are defined; }}.\nCA-8 Additional FedRAMP Requirements and Guidance ", + "guidance": "Penetration testing is a specialized type of assessment conducted on systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Penetration testing goes beyond automated vulnerability scanning and is conducted by agents and teams with demonstrable skills and experience that include technical expertise in network, operating system, and/or application level security. Penetration testing can be used to validate vulnerabilities or determine the degree of penetration resistance of systems to adversaries within specified constraints. Such constraints include time, resources, and skills. Penetration testing attempts to duplicate the actions of adversaries and provides a more in-depth analysis of security- and privacy-related weaknesses or deficiencies. Penetration testing is especially important when organizations are transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols).\n\nOrganizations can use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted internally or externally on the hardware, software, or firmware components of a system and can exercise both physical and technical controls. A standard method for penetration testing includes a pretest analysis based on full knowledge of the system, pretest identification of potential vulnerabilities based on the pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All parties agree to the rules of engagement before commencing penetration testing scenarios. Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries. Penetration testing may result in the exposure of information that is protected by laws or regulations, to individuals conducting the testing. Rules of engagement, contracts, or other appropriate mechanisms can be used to communicate expectations for how to protect this information. Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing." + }, + { + "ref": "CA-9", + "title": "Internal System Connections", + "summary": "Internal System Connections\na. Authorize internal connections of {{ system components - system components or classes of components requiring internal connections to the system are defined; }} to the system;\nb. Document, for each internal connection, the interface characteristics, security and privacy requirements, and the nature of the information communicated;\nc. Terminate internal system connections after {{ conditions - conditions requiring termination of internal connections are defined; }} ; and\nd. Review {{ frequency - frequency at which to review the continued need for each internal connection is defined; }} the continued need for each internal connection.", + "guidance": "Internal system connections are connections between organizational systems and separate constituent system components (i.e., connections between components that are part of the same system) including components used for system development. Intra-system connections include connections with mobile devices, notebook and desktop computers, tablets, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each internal system connection individually, organizations can authorize internal connections for a class of system components with common characteristics and/or configurations, including printers, scanners, and copiers with a specified processing, transmission, and storage capability or smart phones and tablets with a specific baseline configuration. The continued need for an internal system connection is reviewed from the perspective of whether it provides support for organizational missions or business functions." + } + ] + }, + { + "title": "Configuration Management", + "controls": [ + { + "ref": "CM-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} configuration management policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls;\nb. Designate an {{ official - an official to manage the configuration management policy and procedures is defined; }} to manage the development, documentation, and dissemination of the configuration management policy and procedures; and\nc. Review and update the current configuration management:\n1. Policy at least every 3 years and following {{ events - events that would require the current configuration management policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Configuration management policy and procedures address the controls in the CM family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of configuration management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to configuration management policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CM-2", + "title": "Baseline Configuration", + "summary": "Baseline Configuration\na. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and\nb. Review and update the baseline configuration of the system:\n1. at least annually and when a significant change occurs;\n2. When required due to to include when directed by the JAB ; and\n3. When system components are installed or upgraded.\nCM-2 Additional FedRAMP Requirements and Guidance ", + "guidance": "Baseline configurations for systems and system components include connectivity, operational, and communications aspects of systems. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, or changes to systems and include security and privacy control implementations, operational procedures, information about system components, network topology, and logical placement of components in the system architecture. Maintaining baseline configurations requires creating new baselines as organizational systems change over time. Baseline configurations of systems reflect the current enterprise architecture." + }, + { + "ref": "CM-4", + "title": "Impact Analyses", + "summary": "Impact Analyses\nAnalyze changes to the system to determine potential security and privacy impacts prior to change implementation.", + "guidance": "Organizational personnel with security or privacy responsibilities conduct impact analyses. Individuals conducting impact analyses possess the necessary skills and technical expertise to analyze the changes to systems as well as the security or privacy ramifications. Impact analyses include reviewing security and privacy plans, policies, and procedures to understand control requirements; reviewing system design documentation and operational procedures to understand control implementation and how specific system changes might affect the controls; reviewing the impact of changes on organizational supply chain partners with stakeholders; and determining how potential changes to a system create new risks to the privacy of individuals and the ability of implemented controls to mitigate those risks. Impact analyses also include risk assessments to understand the impact of the changes and determine if additional controls are required." + }, + { + "ref": "CM-5", + "title": "Access Restrictions for Change", + "summary": "Access Restrictions for Change\nDefine, document, approve, and enforce physical and logical access restrictions associated with changes to the system.", + "guidance": "Changes to the hardware, software, or firmware components of systems or the operational procedures related to the system can potentially have significant effects on the security of the systems or individuals\u2019 privacy. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes. Access restrictions include physical and logical access controls (see [AC-3] and [PE-3] ), software libraries, workflow automation, media libraries, abstract layers (i.e., changes implemented into external interfaces rather than directly into systems), and change windows (i.e., changes occur only during specified times)." + }, + { + "ref": "CM-6", + "title": "Configuration Settings", + "summary": "Configuration Settings\na. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using {{ common secure configurations - common secure configurations to establish and document configuration settings for components employed within the system are defined; }};\nb. Implement the configuration settings;\nc. Identify, document, and approve any deviations from established configuration settings for {{ system components - system components for which approval of deviations is needed are defined; }} based on {{ operational requirements - operational requirements necessitating approval of deviations are defined; }} ; and\nd. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.\nCM-6 Additional FedRAMP Requirements and Guidance (a) Requirement 1: The service provider shall use the DoD STIGs or Center for Internet Security guidelines to establish configuration settings;\n(a) Requirement 2: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).", + "guidance": "Configuration settings are the parameters that can be changed in the hardware, software, or firmware components of the system that affect the security and privacy posture or functionality of the system. Information technology products for which configuration settings can be defined include mainframe computers, servers, workstations, operating systems, mobile devices, input/output devices, protocols, and applications. Parameters that impact the security posture of systems include registry settings; account, file, or directory permission settings; and settings for functions, protocols, ports, services, and remote connections. Privacy parameters are parameters impacting the privacy posture of systems, including the parameters required to satisfy other privacy controls. Privacy parameters include settings for access controls, data processing preferences, and processing and retention permissions. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the configuration baseline for the system.\n\nCommon secure configurations (also known as security configuration checklists, lockdown and hardening guides, and security reference guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for information technology products and platforms as well as instructions for configuring those products or platforms to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, federal agencies, consortia, academia, industry, and other organizations in the public and private sectors.\n\nImplementation of a common secure configuration may be mandated at the organization level, mission and business process level, system level, or at a higher level, including by a regulatory agency. Common secure configurations include the United States Government Configuration Baseline [USGCB] and security technical implementation guides (STIGs), which affect the implementation of [CM-6] and other controls such as [AC-19] and [CM-7] . The Security Content Automation Protocol (SCAP) and the defined standards within the protocol provide an effective method to uniquely identify, track, and control configuration settings." + }, + { + "ref": "CM-7", + "title": "Least Functionality", + "summary": "Least Functionality\na. Configure the system to provide only {{ mission-essential capabilities - mission-essential capabilities for the system are defined; }} ; and\nb. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: {{ organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services }}.\nCM-7 Additional FedRAMP Requirements and Guidance (b) Requirement: The service provider shall use Security guidelines (See CM-6) to establish list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, protocols, and/or services if STIGs or CIS is not available.", + "guidance": "Systems provide a wide variety of functions and services. Some of the functions and services routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see [SA-8], [SC-2] , and [SC-3])." + }, + { + "ref": "CM-8", + "title": "System Component Inventory", + "summary": "System Component Inventory\na. Develop and document an inventory of system components that:\n1. Accurately reflects the system;\n2. Includes all components within the system;\n3. Does not include duplicate accounting of components or components assigned to any other system;\n4. Is at the level of granularity deemed necessary for tracking and reporting; and\n5. Includes the following information to achieve system component accountability: {{ information - information deemed necessary to achieve effective system component accountability is defined; }} ; and\nb. Review and update the system component inventory at least monthly.\nCM-8 Additional FedRAMP Requirements and Guidance Requirement: must be provided at least monthly or when there is a change.", + "guidance": "System components are discrete, identifiable information technology assets that include hardware, software, and firmware. Organizations may choose to implement centralized system component inventories that include components from all organizational systems. In such situations, organizations ensure that the inventories include system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information, and for networked components, the machine names and network addresses across all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location.\n\nPreventing duplicate accounting of system components addresses the lack of accountability that occurs when component ownership and system association is not known, especially in large or complex connected systems. Effective prevention of duplicate accounting of system components necessitates use of a unique identifier for each component. For software inventory, centrally managed software that is accessed via other systems is addressed as a component of the system on which it is installed and managed. Software installed on multiple organizational systems and managed at the system level is addressed for each individual system and may appear more than once in a centralized component inventory, necessitating a system association for each software instance in the centralized inventory to avoid duplicate accounting of components. Scanning systems implementing multiple network protocols (e.g., IPv4 and IPv6) can result in duplicate components being identified in different address spaces. The implementation of [CM-8(7)] can help to eliminate duplicate accounting of components." + }, + { + "ref": "CM-10", + "title": "Software Usage Restrictions", + "summary": "Software Usage Restrictions\na. Use software and associated documentation in accordance with contract agreements and copyright laws;\nb. Track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Control and document the use of 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.", + "guidance": "Software license tracking can be accomplished by manual or automated methods, depending on organizational needs. Examples of contract agreements include software license agreements and non-disclosure agreements." + }, + { + "ref": "CM-11", + "title": "User-installed Software", + "summary": "User-installed Software\na. Establish {{ policies - policies governing the installation of software by users are defined; }} governing the installation of software by users;\nb. Enforce software installation policies through the following methods: {{ methods - methods used to enforce software installation policies are defined; }} ; and\nc. Monitor policy compliance Continuously (via CM-7 (5)).", + "guidance": "If provided the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved \"app stores.\" Prohibited software installations include software with unknown or suspect pedigrees or software that organizations consider potentially malicious. Policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods." + } + ] + }, + { + "title": "Contingency Planning", + "controls": [ + { + "ref": "CP-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} contingency planning policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the contingency planning policy and the associated contingency planning controls;\nb. Designate an {{ official - an official to manage the contingency planning policy and procedures is defined; }} to manage the development, documentation, and dissemination of the contingency planning policy and procedures; and\nc. Review and update the current contingency planning:\n1. Policy at least every 3 years and following {{ events - events that would require the current contingency planning policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Contingency planning policy and procedures address the controls in the CP family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of contingency planning policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to contingency planning policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CP-2", + "title": "Contingency Plan", + "summary": "Contingency Plan\na. Develop a contingency plan for the system that:\n1. Identifies essential mission and business functions and associated contingency requirements;\n2. Provides recovery objectives, restoration priorities, and metrics;\n3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n4. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure;\n5. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented;\n6. Addresses the sharing of contingency information; and\n7. Is reviewed and approved by {{ organization-defined personnel or roles }};\nb. Distribute copies of the contingency plan to {{ organization-defined key contingency personnel (identified by name and/or by role) and organizational elements }};\nc. Coordinate contingency planning activities with incident handling activities;\nd. Review the contingency plan for the system at least annually;\ne. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\nf. Communicate contingency plan changes to {{ organization-defined key contingency personnel (identified by name and/or by role) and organizational elements }};\ng. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training; and\nh. Protect the contingency plan from unauthorized disclosure and modification.\nCP-2 Additional FedRAMP Requirements and Guidance Requirement: CSPs must use the FedRAMP Information System Contingency Plan (ISCP) Template (available on the fedramp.gov: https://www.fedramp.gov/assets/resources/templates/SSP-A06-FedRAMP-ISCP-Template.docx).", + "guidance": "Contingency planning for systems is part of an overall program for achieving continuity of operations for organizational mission and business functions. Contingency planning addresses system restoration and implementation of alternative mission or business processes when systems are compromised or breached. Contingency planning is considered throughout the system development life cycle and is a fundamental part of the system design. Systems can be designed for redundancy, to provide backup capabilities, and for resilience. Contingency plans reflect the degree of restoration required for organizational systems since not all systems need to fully recover to achieve the level of continuity of operations desired. System recovery objectives reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, organizational risk tolerance, and system impact level.\n\nActions addressed in contingency plans include orderly system degradation, system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By coordinating contingency planning with incident handling activities, organizations ensure that the necessary planning activities are in place and activated in the event of an incident. Organizations consider whether continuity of operations during an incident conflicts with the capability to automatically disable the system, as specified in [IR-4(5)] . Incident response planning is part of contingency planning for organizations and is addressed in the [IR] (Incident Response) family." + }, + { + "ref": "CP-3", + "title": "Contingency Training", + "summary": "Contingency Training\na. Provide contingency training to system users consistent with assigned roles and responsibilities:\n1. Within \\*See Additional Requirements of assuming a contingency role or responsibility;\n2. When required by system changes; and\n3. at least annually thereafter; and\nb. Review and update contingency training content at least annually and following {{ events - events necessitating review and update of contingency training are defined; }}.\nCP-3 Additional FedRAMP Requirements and Guidance (a) Requirement: Privileged admins and engineers must take the basic contingency training within 10 days. Consideration must be given for those privileged admins and engineers with critical contingency-related roles, to gain enough system context and situational awareness to understand the full impact of contingency training as it applies to their respective level. Newly hired critical contingency personnel must take this more in-depth training within 60 days of hire date when the training will have more impact.", + "guidance": "Contingency training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail is included in such training. For example, some individuals may only need to know when and where to report for duty during contingency operations and if normal duties are affected; system administrators may require additional training on how to establish systems at alternate processing and storage sites; and organizational officials may receive more specific training on how to conduct mission-essential functions in designated off-site locations and how to establish communications with other governmental entities for purposes of coordination on contingency-related activities. Training for contingency roles or responsibilities reflects the specific continuity requirements in the contingency plan. Events that may precipitate an update to contingency training content include, but are not limited to, contingency plan testing or an actual contingency (lessons learned), assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. At the discretion of the organization, participation in a contingency plan test or exercise, including lessons learned sessions subsequent to the test or exercise, may satisfy contingency plan training requirements." + }, + { + "ref": "CP-4", + "title": "Contingency Plan Testing", + "summary": "Contingency Plan Testing\na. Test the contingency plan for the system at least every 3 years using the following tests to determine the effectiveness of the plan and the readiness to execute the plan: classroom exercise/table top written tests.\nb. Review the contingency plan test results; and\nc. Initiate corrective actions, if needed.\nCP-4 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider develops test plans in accordance with NIST Special Publication 800-34 (as amended); plans are approved by the JAB/AO prior to initiating testing.\n(b) Requirement: The service provider must include the Contingency Plan test results with the security package within the Contingency Plan-designated appendix (Appendix G, Contingency Plan Test Report).", + "guidance": "Methods for testing contingency plans to determine the effectiveness of the plans and identify potential weaknesses include checklists, walk-through and tabletop exercises, simulations (parallel or full interrupt), and comprehensive exercises. Organizations conduct testing based on the requirements in contingency plans and include a determination of the effects on organizational operations, assets, and individuals due to contingency operations. Organizations have flexibility and discretion in the breadth, depth, and timelines of corrective actions." + }, + { + "ref": "CP-9", + "title": "System Backup", + "summary": "System Backup\na. Conduct backups of user-level information contained in {{ system components - system components for which to conduct backups of user-level information is defined; }} daily incremental; weekly full;\nb. Conduct backups of system-level information contained in the system daily incremental; weekly full;\nc. Conduct backups of system documentation, including security- and privacy-related documentation daily incremental; weekly full ; and\nd. Protect the confidentiality, integrity, and availability of backup information.\nCP-9 Additional FedRAMP Requirements and Guidance Requirement: The service provider shall determine what elements of the cloud environment require the Information System Backup control. The service provider shall determine how Information System Backup is going to be verified and appropriate periodicity of the check.\n(a) Requirement: The service provider maintains at least three backup copies of user-level information (at least one of which is available online) or provides an equivalent alternative.\n(b) Requirement: The service provider maintains at least three backup copies of system-level information (at least one of which is available online) or provides an equivalent alternative.\n(c) Requirement: The service provider maintains at least three backup copies of information system documentation including security information (at least one of which is available online) or provides an equivalent alternative.", + "guidance": "System-level information includes system state information, operating system software, middleware, application software, and licenses. User-level information includes information other than system-level information. Mechanisms employed to protect the integrity of system backups include digital signatures and cryptographic hashes. Protection of system backup information while in transit is addressed by [MP-5] and [SC-8] . System backups reflect the requirements in contingency plans as well as other organizational requirements for backing up information. Organizations may be subject to laws, executive orders, directives, regulations, or policies with requirements regarding specific categories of information (e.g., personal health information). Organizational personnel consult with the senior agency official for privacy and legal counsel regarding such requirements." + }, + { + "ref": "CP-10", + "title": "System Recovery and Reconstitution", + "summary": "System Recovery and Reconstitution\nProvide for the recovery and reconstitution of the system to a known state within {{ organization-defined time period consistent with recovery time and recovery point objectives }} after a disruption, compromise, or failure.", + "guidance": "Recovery is executing contingency plan activities to restore organizational mission and business functions. Reconstitution takes place following recovery and includes activities for returning systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities; recovery point, recovery time, and reconstitution objectives; and organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of interim system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored system capabilities, reestablishment of continuous monitoring activities, system reauthorization (if required), and activities to prepare the system and organization for future disruptions, breaches, compromises, or failures. Recovery and reconstitution capabilities can include automated mechanisms and manual procedures. Organizations establish recovery time and recovery point objectives as part of contingency planning." + } + ] + }, + { + "title": "Identification and Authentication", + "controls": [ + { + "ref": "IA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} identification and authentication policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the identification and authentication policy and the associated identification and authentication controls;\nb. Designate an {{ official - an official to manage the identification and authentication policy and procedures is defined; }} to manage the development, documentation, and dissemination of the identification and authentication policy and procedures; and\nc. Review and update the current identification and authentication:\n1. Policy at least every 3 years and following {{ events - events that would require the current identification and authentication policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Identification and authentication policy and procedures address the controls in the IA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of identification and authentication policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to identification and authentication policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "IA-2", + "title": "Identification and Authentication (Organizational Users)", + "summary": "Identification and Authentication (Organizational Users)\nUniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.\nIA-2 Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\ncontrols IA-2(1) Multi-factor Authentication to Privileged Accounts\nImplement multi-factor authentication for access to privileged accounts.\nIA-2 (1) Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\nIA-2(2) Multi-factor Authentication to Non-privileged Accounts\nImplement multi-factor authentication for access to non-privileged accounts.\nIA-2 (2) Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\nIA-2(8) Access to Accounts \u2014 Replay Resistant\nImplement replay-resistant authentication mechanisms for access to {{ one or more: privileged accounts, non-privileged accounts }}.\nIA-2(12) Acceptance of PIV Credentials\nAccept and electronically verify Personal Identity Verification-compliant credentials.\nIA-2 (12) Additional FedRAMP Requirements and Guidance ", + "guidance": "Organizations can satisfy the identification and authentication requirements by complying with the requirements in [HSPD 12] . Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in [AC-14] and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity.\n\nOrganizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks.\n\nThe use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in [IA-8]." + }, + { + "ref": "IA-4", + "title": "Identifier Management", + "summary": "Identifier Management\nManage system identifiers by:\na. Receiving authorization from at a minimum, the ISSO (or similar role within the organization) to assign an individual, group, role, service, or device identifier;\nb. Selecting an identifier that identifies an individual, group, role, service, or device;\nc. Assigning the identifier to the intended individual, group, role, service, or device; and\nd. Preventing reuse of identifiers for at least two (2) years.", + "guidance": "Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. The management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the usernames of the system accounts assigned to those individuals. In such instances, the account management activities of [AC-2] use account names provided by [IA-4] . Identifier management also addresses individual identifiers not necessarily associated with system accounts. Preventing the reuse of identifiers implies preventing the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices." + }, + { + "ref": "IA-5", + "title": "Authenticator Management", + "summary": "Authenticator Management\nManage system authenticators by:\na. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator;\nb. Establishing initial authenticator content for any authenticators issued by the organization;\nc. Ensuring that authenticators have sufficient strength of mechanism for their intended use;\nd. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators;\ne. Changing default authenticators prior to first use;\nf. Changing or refreshing authenticators {{ time period by authenticator type - a time period for changing or refreshing authenticators by authenticator type is defined; }} or when {{ events - events that trigger the change or refreshment of authenticators are defined; }} occur;\ng. Protecting authenticator content from unauthorized disclosure and modification;\nh. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and\ni. Changing authenticators for group or role accounts when membership to those accounts changes.\nIA-5 Additional FedRAMP Requirements and Guidance Requirement: Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 1. Link https://pages.nist.gov/800-63-3\ncontrols IA-5(1) Password-based Authentication\nFor password-based authentication:\n(a) Maintain a list of commonly-used, expected, or compromised passwords and update the list {{ frequency - the frequency at which to update the list of commonly used, expected, or compromised passwords is defined; }} and when organizational passwords are suspected to have been compromised directly or indirectly;\n(b) Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a);\n(c) Transmit passwords only over cryptographically-protected channels;\n(d) Store passwords using an approved salted key derivation function, preferably using a keyed hash;\n(e) Require immediate selection of a new password upon account recovery;\n(f) Allow user selection of long passwords and passphrases, including spaces and all printable characters;\n(g) Employ automated tools to assist the user in selecting strong password authenticators; and\n(h) Enforce the following composition and complexity rules: {{ composition and complexity rules - authenticator composition and complexity rules are defined; }}.\nIA-5 (1) Additional FedRAMP Requirements and Guidance Requirement: Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.\n(h) Requirement: For cases where technology doesn\u2019t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.\n\nFor emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.", + "guidance": "Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length). Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control [PL-4] or [PS-6] for authenticators in the possession of individuals and by controls [AC-3], [AC-6] , and [SC-28] for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges.\n\nSystems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics (e.g., minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication). Actions can be taken to safeguard individual authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed." + }, + { + "ref": "IA-6", + "title": "Authentication Feedback", + "summary": "Authentication Feedback\nObscure feedback of authentication information during the authentication process to protect the information from possible exploitation and use by unauthorized individuals.", + "guidance": "Authentication feedback from systems does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of systems, such as desktops or notebooks with relatively large monitors, the threat (referred to as shoulder surfing) may be significant. For other types of systems, such as mobile devices with small displays, the threat may be less significant and is balanced against the increased likelihood of typographic input errors due to small keyboards. Thus, the means for obscuring authentication feedback is selected accordingly. Obscuring authentication feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a very limited time before obscuring it." + }, + { + "ref": "IA-7", + "title": "Cryptographic Module Authentication", + "summary": "Cryptographic Module Authentication\nImplement mechanisms for authentication to a cryptographic module that meet the requirements of applicable laws, executive orders, directives, policies, regulations, standards, and guidelines for such authentication.", + "guidance": "Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role." + }, + { + "ref": "IA-8", + "title": "Identification and Authentication (Non-organizational Users)", + "summary": "Identification and Authentication (Non-organizational Users)\nUniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users.\ncontrols IA-8(1) Acceptance of PIV Credentials from Other Agencies\nAccept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.\nIA-8(2) Acceptance of External Authenticators\n(a) Accept only external authenticators that are NIST-compliant; and\n(b) Document and maintain a list of accepted external authenticators.\nIA-8(4) Use of Defined Profiles\nConform to the following profiles for identity management {{ identity management profiles - identity management profiles are defined; }}.", + "guidance": "Non-organizational users include system users other than organizational users explicitly covered by [IA-2] . Non-organizational users are uniquely identified and authenticated for accesses other than those explicitly identified and documented in [AC-14] . Identification and authentication of non-organizational users accessing federal systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations consider many factors\u2014including security, privacy, scalability, and practicality\u2014when balancing the need to ensure ease of use for access to federal information and systems with the need to protect and adequately mitigate risk." + }, + { + "ref": "IA-11", + "title": "Re-authentication", + "summary": "Re-authentication\nRequire users to re-authenticate when {{ circumstances or situations - circumstances or situations requiring re-authentication are defined; }}.\nIA-11 Additional FedRAMP Requirements and Guidance ", + "guidance": "In addition to the re-authentication requirements associated with device locks, organizations may require re-authentication of individuals in certain situations, including when roles, authenticators or credentials change, when security categories of systems change, when the execution of privileged functions occurs, after a fixed time period, or periodically." + } + ] + }, + { + "title": "Incident Response", + "controls": [ + { + "ref": "IR-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} incident response policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the incident response policy and the associated incident response controls;\nb. Designate an {{ official - an official to manage the incident response policy and procedures is defined; }} to manage the development, documentation, and dissemination of the incident response policy and procedures; and\nc. Review and update the current incident response:\n1. Policy at least every 3 years and following {{ events - events that would require the current incident response policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Incident response policy and procedures address the controls in the IR family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of incident response policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to incident response policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "IR-2", + "title": "Incident Response Training", + "summary": "Incident Response Training\na. Provide incident response training to system users consistent with assigned roles and responsibilities:\n1. Within ten (10) days for privileged users, thirty (30) days for Incident Response roles of assuming an incident response role or responsibility or acquiring system access;\n2. When required by system changes; and\n3. at least annually thereafter; and\nb. Review and update incident response training content at least annually and following {{ events - events that initiate a review of the incident response training content are defined; }}.", + "guidance": "Incident response training is associated with the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail are included in such training. For example, users may only need to know who to call or how to recognize an incident; system administrators may require additional training on how to handle incidents; and incident responders may receive more specific training on forensics, data collection techniques, reporting, system recovery, and system restoration. Incident response training includes user training in identifying and reporting suspicious activities from external and internal sources. Incident response training for users may be provided as part of [AT-2] or [AT-3] . Events that may precipitate an update to incident response training content include, but are not limited to, incident response plan testing or response to an actual incident (lessons learned), assessment or audit findings, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "IR-4", + "title": "Incident Handling", + "summary": "Incident Handling\na. Implement an incident handling capability for incidents that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery;\nb. Coordinate incident handling activities with contingency planning activities;\nc. Incorporate lessons learned from ongoing incident handling activities into incident response procedures, training, and testing, and implement the resulting changes accordingly; and\nd. Ensure the rigor, intensity, scope, and results of incident handling activities are comparable and predictable across the organization.\nIR-4 Additional FedRAMP Requirements and Guidance Requirement: The service provider ensures that individuals conducting incident handling meet personnel security requirements commensurate with the criticality/sensitivity of the information being processed, stored, and transmitted by the information system.", + "guidance": "Organizations recognize that incident response capabilities are dependent on the capabilities of organizational systems and the mission and business processes being supported by those systems. Organizations consider incident response as part of the definition, design, and development of mission and business processes and systems. Incident-related information can be obtained from a variety of sources, including audit monitoring, physical access monitoring, and network monitoring; user or administrator reports; and reported supply chain events. An effective incident handling capability includes coordination among many organizational entities (e.g., mission or business owners, system owners, authorizing officials, human resources offices, physical security offices, personnel security offices, legal departments, risk executive [function], operations personnel, procurement offices). Suspected security incidents include the receipt of suspicious email communications that can contain malicious code. Suspected supply chain incidents include the insertion of counterfeit hardware or malicious code into organizational systems or system components. For federal agencies, an incident that involves personally identifiable information is considered a breach. A breach results in unauthorized disclosure, the loss of control, unauthorized acquisition, compromise, or a similar occurrence where a person other than an authorized user accesses or potentially accesses personally identifiable information or an authorized user accesses or potentially accesses such information for other than authorized purposes." + }, + { + "ref": "IR-5", + "title": "Incident Monitoring", + "summary": "Incident Monitoring\nTrack and document incidents.", + "guidance": "Documenting incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics as well as evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources, including network monitoring, incident reports, incident response teams, user complaints, supply chain partners, audit monitoring, physical access monitoring, and user and administrator reports. [IR-4] provides information on the types of incidents that are appropriate for monitoring." + }, + { + "ref": "IR-6", + "title": "Incident Reporting", + "summary": "Incident Reporting\na. Require personnel to report suspected incidents to the organizational incident response capability within US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended) ; and\nb. Report incident information to {{ authorities - authorities to whom incident information is to be reported are defined; }}.\nIR-6 Additional FedRAMP Requirements and Guidance Requirement: Reports security incident information according to FedRAMP Incident Communications Procedure.", + "guidance": "The types of incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Incident information can inform risk assessments, control effectiveness assessments, security requirements for acquisitions, and selection criteria for technology products." + }, + { + "ref": "IR-7", + "title": "Incident Response Assistance", + "summary": "Incident Response Assistance\nProvide an incident response support resource, integral to the organizational incident response capability, that offers advice and assistance to users of the system for the handling and reporting of incidents.", + "guidance": "Incident response support resources provided by organizations include help desks, assistance groups, automated ticketing systems to open and track incident response tickets, and access to forensics services or consumer redress services, when required." + }, + { + "ref": "IR-8", + "title": "Incident Response Plan", + "summary": "Incident Response Plan\na. Develop an incident response plan that:\n1. Provides the organization with a roadmap for implementing its incident response capability;\n2. Describes the structure and organization of the incident response capability;\n3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n5. Defines reportable incidents;\n6. Provides metrics for measuring the incident response capability within the organization;\n7. Defines the resources and management support needed to effectively maintain and mature an incident response capability;\n8. Addresses the sharing of incident information;\n9. Is reviewed and approved by {{ personnel or roles - personnel or roles that review and approve the incident response plan is/are identified; }} at least annually ; and\n10. Explicitly designates responsibility for incident response to {{ entities, personnel, or roles - entities, personnel, or roles with designated responsibility for incident response are defined; }}.\nb. Distribute copies of the incident response plan to see additional FedRAMP Requirements and Guidance;\nc. Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing;\nd. Communicate incident response plan changes to see additional FedRAMP Requirements and Guidance ; and\ne. Protect the incident response plan from unauthorized disclosure and modification.\nIR-8 Additional FedRAMP Requirements and Guidance (b) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.\n(d) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.", + "guidance": "It is important that organizations develop and implement a coordinated approach to incident response. Organizational mission and business functions determine the structure of incident response capabilities. As part of the incident response capabilities, organizations consider the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain. For incidents involving personally identifiable information (i.e., breaches), include a process to determine whether notice to oversight organizations or affected individuals is appropriate and provide that notice accordingly." + } + ] + }, + { + "title": "Maintenance", + "controls": [ + { + "ref": "MA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} maintenance policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the maintenance policy and the associated maintenance controls;\nb. Designate an {{ official - an official to manage the maintenance policy and procedures is defined; }} to manage the development, documentation, and dissemination of the maintenance policy and procedures; and\nc. Review and update the current maintenance:\n1. Policy at least every 3 years and following {{ events - events that would require the current maintenance policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Maintenance policy and procedures address the controls in the MA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of maintenance policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to maintenance policy and procedures assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "MA-2", + "title": "Controlled Maintenance", + "summary": "Controlled Maintenance\na. Schedule, document, and review records of maintenance, repair, and replacement on system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\nb. Approve and monitor all maintenance activities, whether performed on site or remotely and whether the system or system components are serviced on site or removed to another location;\nc. Require that {{ personnel or roles - personnel or roles required to explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance or repairs is/are defined; }} explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance, repair, or replacement;\nd. Sanitize equipment to remove the following information from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement: {{ information - information to be removed from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement is defined; }};\ne. Check all potentially impacted controls to verify that the controls are still functioning properly following maintenance, repair, or replacement actions; and\nf. Include the following information in organizational maintenance records: {{ information - information to be included in organizational maintenance records is defined; }}.", + "guidance": "Controlling system maintenance addresses the information security aspects of the system maintenance program and applies to all types of maintenance to system components conducted by local or nonlocal entities. Maintenance includes peripherals such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes the date and time of maintenance, a description of the maintenance performed, names of the individuals or group performing the maintenance, name of the escort, and system components or equipment that are removed or replaced. Organizations consider supply chain-related risks associated with replacement components for systems." + }, + { + "ref": "MA-4", + "title": "Nonlocal Maintenance", + "summary": "Nonlocal Maintenance\na. Approve and monitor nonlocal maintenance and diagnostic activities;\nb. Allow the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the system;\nc. Employ strong authentication in the establishment of nonlocal maintenance and diagnostic sessions;\nd. Maintain records for nonlocal maintenance and diagnostic activities; and\ne. Terminate session and network connections when nonlocal maintenance is completed.", + "guidance": "Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network. Local maintenance and diagnostic activities are carried out by individuals who are physically present at the system location and not communicating across a network connection. Authentication techniques used to establish nonlocal maintenance and diagnostic sessions reflect the network access requirements in [IA-2] . Strong authentication requires authenticators that are resistant to replay attacks and employ multi-factor authentication. Strong authenticators include PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing requirements in [MA-4] is accomplished, in part, by other controls. [SP 800-63B] provides additional guidance on strong authentication and authenticators." + }, + { + "ref": "MA-5", + "title": "Maintenance Personnel", + "summary": "Maintenance Personnel\na. Establish a process for maintenance personnel authorization and maintain a list of authorized maintenance organizations or personnel;\nb. Verify that non-escorted personnel performing maintenance on the system possess the required access authorizations; and\nc. Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.", + "guidance": "Maintenance personnel refers to individuals who perform hardware or software maintenance on organizational systems, while [PE-2] addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems. Technical competence of supervising individuals relates to the maintenance performed on the systems, while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized maintenance personnel\u2014such as information technology manufacturers, vendors, systems integrators, and consultants\u2014may require privileged access to organizational systems, such as when they are required to conduct maintenance activities with little or no notice. Based on organizational assessments of risk, organizations may issue temporary credentials to these individuals. Temporary credentials may be for one-time use or for very limited time periods." + } + ] + }, + { + "title": "Media Protection", + "controls": [ + { + "ref": "MP-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} media protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the media protection policy and the associated media protection controls;\nb. Designate an {{ official - an official to manage the media protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the media protection policy and procedures; and\nc. Review and update the current media protection:\n1. Policy at least every 3 years and following {{ events - events that would require the current media protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Media protection policy and procedures address the controls in the MP family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of media protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to media protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "MP-2", + "title": "Media Access", + "summary": "Media Access\nRestrict access to {{ organization-defined types of digital and/or non-digital media }} to {{ organization-defined personnel or roles }}.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers is an example of restricting access to non-digital media. Limiting access to the design specifications stored on compact discs in the media library to individuals on the system development team is an example of restricting access to digital media." + }, + { + "ref": "MP-6", + "title": "Media Sanitization", + "summary": "Media Sanitization\na. Sanitize techniques and procedures IAW NIST SP 800-88 Section 4: Reuse and Disposal of Storage Media and Hardware prior to disposal, release out of organizational control, or release for reuse using {{ organization-defined sanitization techniques and procedures }} ; and\nb. Employ sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information.", + "guidance": "Media sanitization applies to all digital and non-digital system media subject to disposal or reuse, whether or not the media is considered removable. Examples include digital media in scanners, copiers, printers, notebook computers, workstations, network components, mobile devices, and non-digital media (e.g., paper and microfilm). The sanitization process removes information from system media such that the information cannot be retrieved or reconstructed. Sanitization techniques\u2014including clearing, purging, cryptographic erase, de-identification of personally identifiable information, and destruction\u2014prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal. Organizations determine the appropriate sanitization methods, recognizing that destruction is sometimes necessary when other methods cannot be applied to media requiring sanitization. Organizations use discretion on the employment of approved sanitization techniques and procedures for media that contains information deemed to be in the public domain or publicly releasable or information deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes destruction, removing a classified appendix from an otherwise unclassified document, or redacting selected sections or words from a document by obscuring the redacted sections or words in a manner equivalent in effectiveness to removing them from the document. NSA standards and policies control the sanitization process for media that contains classified information. NARA policies control the sanitization process for controlled unclassified information." + }, + { + "ref": "MP-7", + "title": "Media Use", + "summary": "Media Use\na. {{ restrict OR prohibit }} the use of {{ types of system media - types of system media to be restricted or prohibited from use on systems or system components are defined; }} on {{ systems or system components - systems or system components on which the use of specific types of system media to be restricted or prohibited are defined; }} using {{ controls - controls to restrict or prohibit the use of specific types of system media on systems or system components are defined; }} ; and\nb. Prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", + "guidance": "System media includes both digital and non-digital media. Digital media includes diskettes, magnetic tapes, flash drives, compact discs, digital versatile discs, and removable hard disk drives. Non-digital media includes paper and microfilm. Media use protections also apply to mobile devices with information storage capabilities. In contrast to [MP-2] , which restricts user access to media, MP-7 restricts the use of certain types of media on systems, for example, restricting or prohibiting the use of flash drives or external hard disk drives. Organizations use technical and nontechnical controls to restrict the use of system media. Organizations may restrict the use of portable storage devices, for example, by using physical cages on workstations to prohibit access to certain external ports or disabling or removing the ability to insert, read, or write to such devices. Organizations may also limit the use of portable storage devices to only approved devices, including devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Finally, organizations may restrict the use of portable storage devices based on the type of device, such as by prohibiting the use of writeable, portable storage devices and implementing this restriction by disabling or removing the capability to write to such devices. Requiring identifiable owners for storage devices reduces the risk of using such devices by allowing organizations to assign responsibility for addressing known vulnerabilities in the devices." + } + ] + }, + { + "title": "Physical and Environmental Protection", + "controls": [ + { + "ref": "PE-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} physical and environmental protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the physical and environmental protection policy and the associated physical and environmental protection controls;\nb. Designate an {{ official - an official to manage the physical and environmental protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the physical and environmental protection policy and procedures; and\nc. Review and update the current physical and environmental protection:\n1. Policy at least every 3 years and following {{ events - events that would require the current physical and environmental protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Physical and environmental protection policy and procedures address the controls in the PE family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of physical and environmental protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to physical and environmental protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PE-2", + "title": "Physical Access Authorizations", + "summary": "Physical Access Authorizations\na. Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides;\nb. Issue authorization credentials for facility access;\nc. Review the access list detailing authorized facility access by individuals at least annually ; and\nd. Remove individuals from the facility access list when access is no longer required.", + "guidance": "Physical access authorizations apply to employees and visitors. Individuals with permanent physical access authorization credentials are not considered visitors. Authorization credentials include ID badges, identification cards, and smart cards. Organizations determine the strength of authorization credentials needed consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Physical access authorizations may not be necessary to access certain areas within facilities that are designated as publicly accessible." + }, + { + "ref": "PE-3", + "title": "Physical Access Control", + "summary": "Physical Access Control\na. Enforce physical access authorizations at {{ entry and exit points - entry and exit points to the facility in which the system resides are defined; }} by:\n1. Verifying individual access authorizations before granting access to the facility; and\n2. Controlling ingress and egress to the facility using CSP defined physical access control systems/devices AND guards;\nb. Maintain physical access audit logs for {{ entry or exit points - entry or exit points for which physical access logs are maintained are defined; }};\nc. Control access to areas within the facility designated as publicly accessible by implementing the following controls: {{ physical access controls - physical access controls to control access to areas within the facility designated as publicly accessible are defined; }};\nd. Escort visitors and control visitor activity in all circumstances within restricted access area where the information system resides;\ne. Secure keys, combinations, and other physical access devices;\nf. Inventory at least annually every {{ frequency - frequency at which to inventory physical access devices is defined; }} ; and\ng. Change combinations and keys at least annually and/or when keys are lost, combinations are compromised, or when individuals possessing the keys or combinations are transferred or terminated.", + "guidance": "Physical access control applies to employees and visitors. Individuals with permanent physical access authorizations are not considered visitors. Physical access controls for publicly accessible areas may include physical access control logs/records, guards, or physical access devices and barriers to prevent movement from publicly accessible areas to non-public areas. Organizations determine the types of guards needed, including professional security staff, system users, or administrative staff. Physical access devices include keys, locks, combinations, biometric readers, and card readers. Physical access control systems comply with applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural, automated, or some combination thereof. Physical access points can include facility access points, interior access points to systems that require supplemental access controls, or both. Components of systems may be in areas designated as publicly accessible with organizations controlling access to the components." + }, + { + "ref": "PE-6", + "title": "Monitoring Physical Access", + "summary": "Monitoring Physical Access\na. Monitor physical access to the facility where the system resides to detect and respond to physical security incidents;\nb. Review physical access logs at least monthly and upon occurrence of {{ events - events or potential indication of events requiring physical access logs to be reviewed are defined; }} ; and\nc. Coordinate results of reviews and investigations with the organizational incident response capability.", + "guidance": "Physical access monitoring includes publicly accessible areas within organizational facilities. Examples of physical access monitoring include the employment of guards, video surveillance equipment (i.e., cameras), and sensor devices. Reviewing physical access logs can help identify suspicious activity, anomalous events, or potential threats. The reviews can be supported by audit logging controls, such as [AU-2] , if the access logs are part of an automated system. Organizational incident response capabilities include investigations of physical security incidents and responses to the incidents. Incidents include security violations or suspicious physical access activities. Suspicious physical access activities include accesses outside of normal work hours, repeated accesses to areas not normally accessed, accesses for unusual lengths of time, and out-of-sequence accesses." + }, + { + "ref": "PE-8", + "title": "Visitor Access Records", + "summary": "Visitor Access Records\na. Maintain visitor access records to the facility where the system resides for for a minimum of one (1) year;\nb. Review visitor access records at least monthly ; and\nc. Report anomalies in visitor access records to {{ personnel - personnel to whom visitor access records anomalies are reported to is/are defined; }}.", + "guidance": "Visitor access records include the names and organizations of individuals visiting, visitor signatures, forms of identification, dates of access, entry and departure times, purpose of visits, and the names and organizations of individuals visited. Access record reviews determine if access authorizations are current and are still required to support organizational mission and business functions. Access records are not required for publicly accessible areas." + }, + { + "ref": "PE-12", + "title": "Emergency Lighting", + "summary": "Emergency Lighting\nEmploy and maintain automatic emergency lighting for the system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "guidance": "The provision of emergency lighting applies primarily to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Emergency lighting provisions for the system are described in the contingency plan for the organization. If emergency lighting for the system fails or cannot be provided, organizations consider alternate processing sites for power-related contingencies." + }, + { + "ref": "PE-13", + "title": "Fire Protection", + "summary": "Fire Protection\nEmploy and maintain fire detection and suppression systems that are supported by an independent energy source.", + "guidance": "The provision of fire detection and suppression systems applies primarily to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Fire detection and suppression systems that may require an independent energy source include sprinkler systems and smoke detectors. An independent energy source is an energy source, such as a microgrid, that is separate, or can be separated, from the energy sources providing power for the other parts of the facility." + }, + { + "ref": "PE-14", + "title": "Environmental Controls", + "summary": "Environmental Controls\na. Maintain consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments levels within the facility where the system resides at {{ acceptable levels - acceptable levels for environmental controls are defined; }} ; and\nb. Monitor environmental control levels continuously.\nPE-14 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider measures temperature at server inlets and humidity levels by dew point.", + "guidance": "The provision of environmental controls applies primarily to organizational facilities that contain concentrations of system resources (e.g., data centers, mainframe computer rooms, and server rooms). Insufficient environmental controls, especially in very harsh environments, can have a significant adverse impact on the availability of systems and system components that are needed to support organizational mission and business functions." + }, + { + "ref": "PE-15", + "title": "Water Damage Protection", + "summary": "Water Damage Protection\nProtect the system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel.", + "guidance": "The provision of water damage protection primarily applies to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Isolation valves can be employed in addition to or in lieu of master shutoff valves to shut off water supplies in specific areas of concern without affecting entire organizations." + }, + { + "ref": "PE-16", + "title": "Delivery and Removal", + "summary": "Delivery and Removal\na. Authorize and control all information system components entering and exiting the facility; and\nb. Maintain records of the system components.", + "guidance": "Enforcing authorizations for entry and exit of system components may require restricting access to delivery areas and isolating the areas from the system and media libraries." + } + ] + }, + { + "title": "Planning", + "controls": [ + { + "ref": "PL-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} planning policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the planning policy and the associated planning controls;\nb. Designate an {{ official - an official to manage the planning policy and procedures is defined; }} to manage the development, documentation, and dissemination of the planning policy and procedures; and\nc. Review and update the current planning:\n1. Policy at least every 3 years and following {{ events - events that would require the current planning policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Planning policy and procedures for the controls in the PL family implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to planning policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PL-2", + "title": "System Security and Privacy Plans", + "summary": "System Security and Privacy Plans\na. Develop security and privacy plans for the system that:\n1. Are consistent with the organization\u2019s enterprise architecture;\n2. Explicitly define the constituent system components;\n3. Describe the operational context of the system in terms of mission and business processes;\n4. Identify the individuals that fulfill system roles and responsibilities;\n5. Identify the information types processed, stored, and transmitted by the system;\n6. Provide the security categorization of the system, including supporting rationale;\n7. Describe any specific threats to the system that are of concern to the organization;\n8. Provide the results of a privacy risk assessment for systems processing personally identifiable information;\n9. Describe the operational environment for the system and any dependencies on or connections to other systems or system components;\n10. Provide an overview of the security and privacy requirements for the system;\n11. Identify any relevant control baselines or overlays, if applicable;\n12. Describe the controls in place or planned for meeting the security and privacy requirements, including a rationale for any tailoring decisions;\n13. Include risk determinations for security and privacy architecture and design decisions;\n14. Include security- and privacy-related activities affecting the system that require planning and coordination with {{ individuals or groups - individuals or groups with whom security and privacy-related activities affecting the system that require planning and coordination is/are assigned; }} ; and\n15. Are reviewed and approved by the authorizing official or designated representative prior to plan implementation.\nb. Distribute copies of the plans and communicate subsequent changes to the plans to {{ personnel or roles - personnel or roles to receive distributed copies of the system security and privacy plans is/are assigned; }};\nc. Review the plans at least annually;\nd. Update the plans to address changes to the system and environment of operation or problems identified during plan implementation or control assessments; and\ne. Protect the plans from unauthorized disclosure and modification.", + "guidance": "System security and privacy plans are scoped to the system and system components within the defined authorization boundary and contain an overview of the security and privacy requirements for the system and the controls selected to satisfy the requirements. The plans describe the intended application of each selected control in the context of the system with a sufficient level of detail to correctly implement the control and to subsequently assess the effectiveness of the control. The control documentation describes how system-specific and hybrid controls are implemented and the plans and expectations regarding the functionality of the system. System security and privacy plans can also be used in the design and development of systems in support of life cycle-based security and privacy engineering processes. System security and privacy plans are living documents that are updated and adapted throughout the system development life cycle (e.g., during capability determination, analysis of alternatives, requests for proposal, and design reviews). [Section 2.1] describes the different types of requirements that are relevant to organizations during the system development life cycle and the relationship between requirements and controls.\n\nOrganizations may develop a single, integrated security and privacy plan or maintain separate plans. Security and privacy plans relate security and privacy requirements to a set of controls and control enhancements. The plans describe how the controls and control enhancements meet the security and privacy requirements but do not provide detailed, technical descriptions of the design or implementation of the controls and control enhancements. Security and privacy plans contain sufficient information (including specifications of control parameter values for selection and assignment operations explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented.\n\nSecurity and privacy plans need not be single documents. The plans can be a collection of various documents, including documents that already exist. Effective security and privacy plans make extensive use of references to policies, procedures, and additional documents, including design and implementation specifications where more detailed information can be obtained. The use of references helps reduce the documentation associated with security and privacy programs and maintains the security- and privacy-related information in other established management and operational areas, including enterprise architecture, system development life cycle, systems engineering, and acquisition. Security and privacy plans need not contain detailed contingency plan or incident response plan information but can instead provide\u2014explicitly or by reference\u2014sufficient information to define what needs to be accomplished by those plans.\n\nSecurity- and privacy-related activities that may require coordination and planning with other individuals or groups within the organization include assessments, audits, inspections, hardware and software maintenance, acquisition and supply chain risk management, patch management, and contingency plan testing. Planning and coordination include emergency and nonemergency (i.e., planned or non-urgent unplanned) situations. The process defined by organizations to plan and coordinate security- and privacy-related activities can also be included in other documents, as appropriate." + }, + { + "ref": "PL-4", + "title": "Rules of Behavior", + "summary": "Rules of Behavior\na. Establish and provide to individuals requiring access to the system, the rules that describe their responsibilities and expected behavior for information and system usage, security, and privacy;\nb. Receive a documented acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the system;\nc. Review and update the rules of behavior at least every 3 years ; and\nd. Require individuals who have acknowledged a previous version of the rules of behavior to read and re-acknowledge at least annually and when the rules are revised or changed.\ncontrols PL-4(1) Social Media and External Site/Application Usage Restrictions\nInclude in the rules of behavior, restrictions on:\n(a) Use of social media, social networking sites, and external sites/applications;\n(b) Posting organizational information on public websites; and\n(c) Use of organization-provided identifiers (e.g., email addresses) and authentication secrets (e.g., passwords) for creating accounts on external sites/applications.", + "guidance": "Rules of behavior represent a type of access agreement for organizational users. Other types of access agreements include nondisclosure agreements, conflict-of-interest agreements, and acceptable use agreements (see [PS-6] ). Organizations consider rules of behavior based on individual user roles and responsibilities and differentiate between rules that apply to privileged users and rules that apply to general users. Establishing rules of behavior for some types of non-organizational users, including individuals who receive information from federal systems, is often not feasible given the large number of such users and the limited nature of their interactions with the systems. Rules of behavior for organizational and non-organizational users can also be established in [AC-8] . The related controls section provides a list of controls that are relevant to organizational rules of behavior. [PL-4b] , the documented acknowledgment portion of the control, may be satisfied by the literacy training and awareness and role-based training programs conducted by organizations if such training includes rules of behavior. Documented acknowledgements for rules of behavior include electronic or physical signatures and electronic agreement check boxes or radio buttons." + }, + { + "ref": "PL-8", + "title": "Security and Privacy Architectures", + "summary": "Security and Privacy Architectures\na. Develop security and privacy architectures for the system that:\n1. Describe the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information;\n2. Describe the requirements and approach to be taken for processing personally identifiable information to minimize privacy risk to individuals;\n3. Describe how the architectures are integrated into and support the enterprise architecture; and\n4. Describe any assumptions about, and dependencies on, external systems and services;\nb. Review and update the architectures at least annually and when a significant change occurs to reflect changes in the enterprise architecture; and\nc. Reflect planned architecture changes in security and privacy plans, Concept of Operations (CONOPS), criticality analysis, organizational procedures, and procurements and acquisitions.\nPL-8 Additional FedRAMP Requirements and Guidance ", + "guidance": "The security and privacy architectures at the system level are consistent with the organization-wide security and privacy architectures described in [PM-7] , which are integral to and developed as part of the enterprise architecture. The architectures include an architectural description, the allocation of security and privacy functionality (including controls), security- and privacy-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. The architectures can also include other information, such as user roles and the access privileges assigned to each role; security and privacy requirements; types of information processed, stored, and transmitted by the system; supply chain risk management requirements; restoration priorities of information and system services; and other protection needs.\n\n [SP 800-160-1] provides guidance on the use of security architectures as part of the system development life cycle process. [OMB M-19-03] requires the use of the systems security engineering concepts described in [SP 800-160-1] for high value assets. Security and privacy architectures are reviewed and updated throughout the system development life cycle, from analysis of alternatives through review of the proposed architecture in the RFP responses to the design reviews before and during implementation (e.g., during preliminary design reviews and critical design reviews).\n\nIn today\u2019s modern computing architectures, it is becoming less common for organizations to control all information resources. There may be key dependencies on external information services and service providers. Describing such dependencies in the security and privacy architectures is necessary for developing a comprehensive mission and business protection strategy. Establishing, developing, documenting, and maintaining under configuration control a baseline configuration for organizational systems is critical to implementing and maintaining effective architectures. The development of the architectures is coordinated with the senior agency information security officer and the senior agency official for privacy to ensure that the controls needed to support security and privacy requirements are identified and effectively implemented. In many circumstances, there may be no distinction between the security and privacy architecture for a system. In other circumstances, security objectives may be adequately satisfied, but privacy objectives may only be partially satisfied by the security requirements. In these cases, consideration of the privacy requirements needed to achieve satisfaction will result in a distinct privacy architecture. The documentation, however, may simply reflect the combined architectures.\n\n [PL-8] is primarily directed at organizations to ensure that architectures are developed for the system and, moreover, that the architectures are integrated with or tightly coupled to the enterprise architecture. In contrast, [SA-17] is primarily directed at the external information technology product and system developers and integrators. [SA-17] , which is complementary to [PL-8] , is selected when organizations outsource the development of systems or components to external entities and when there is a need to demonstrate consistency with the organization\u2019s enterprise architecture and security and privacy architectures." + }, + { + "ref": "PL-10", + "title": "Baseline Selection", + "summary": "Baseline Selection\nSelect a control baseline for the system.\nPL-10 Additional FedRAMP Requirements and Guidance Requirement: Select the appropriate FedRAMP Baseline", + "guidance": "Control baselines are predefined sets of controls specifically assembled to address the protection needs of a group, organization, or community of interest. Controls are chosen for baselines to either satisfy mandates imposed by laws, executive orders, directives, regulations, policies, standards, and guidelines or address threats common to all users of the baseline under the assumptions specific to the baseline. Baselines represent a starting point for the protection of individuals\u2019 privacy, information, and information systems with subsequent tailoring actions to manage risk in accordance with mission, business, or other constraints (see [PL-11] ). Federal control baselines are provided in [SP 800-53B] . The selection of a control baseline is determined by the needs of stakeholders. Stakeholder needs consider mission and business requirements as well as mandates imposed by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. For example, the control baselines in [SP 800-53B] are based on the requirements from [FISMA] and [PRIVACT] . The requirements, along with the NIST standards and guidelines implementing the legislation, direct organizations to select one of the control baselines after the reviewing the information types and the information that is processed, stored, and transmitted on the system; analyzing the potential adverse impact of the loss or compromise of the information or system on the organization\u2019s operations and assets, individuals, other organizations, or the Nation; and considering the results from system and organizational risk assessments. [CNSSI 1253] provides guidance on control baselines for national security systems." + }, + { + "ref": "PL-11", + "title": "Baseline Tailoring", + "summary": "Baseline Tailoring\nTailor the selected control baseline by applying specified tailoring actions.", + "guidance": "The concept of tailoring allows organizations to specialize or customize a set of baseline controls by applying a defined set of tailoring actions. Tailoring actions facilitate such specialization and customization by allowing organizations to develop security and privacy plans that reflect their specific mission and business functions, the environments where their systems operate, the threats and vulnerabilities that can affect their systems, and any other conditions or situations that can impact their mission or business success. Tailoring guidance is provided in [SP 800-53B] . Tailoring a control baseline is accomplished by identifying and designating common controls, applying scoping considerations, selecting compensating controls, assigning values to control parameters, supplementing the control baseline with additional controls as needed, and providing information for control implementation. The general tailoring actions in [SP 800-53B] can be supplemented with additional actions based on the needs of organizations. Tailoring actions can be applied to the baselines in [SP 800-53B] in accordance with the security and privacy requirements from [FISMA], [PRIVACT] , and [OMB A-130] . Alternatively, other communities of interest adopting different control baselines can apply the tailoring actions in [SP 800-53B] to specialize or customize the controls that represent the specific needs and concerns of those entities." + } + ] + }, + { + "title": "Personnel Security", + "controls": [ + { + "ref": "PS-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} personnel security policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the personnel security policy and the associated personnel security controls;\nb. Designate an {{ official - an official to manage the personnel security policy and procedures is defined; }} to manage the development, documentation, and dissemination of the personnel security policy and procedures; and\nc. Review and update the current personnel security:\n1. Policy at least every 3 years and following {{ events - events that would require the current personnel security policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Personnel security policy and procedures for the controls in the PS family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to personnel security policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PS-2", + "title": "Position Risk Designation", + "summary": "Position Risk Designation\na. Assign a risk designation to all organizational positions;\nb. Establish screening criteria for individuals filling those positions; and\nc. Review and update position risk designations at least every three years.", + "guidance": "Position risk designations reflect Office of Personnel Management (OPM) policy and guidance. Proper position designation is the foundation of an effective and consistent suitability and personnel security program. The Position Designation System (PDS) assesses the duties and responsibilities of a position to determine the degree of potential damage to the efficiency or integrity of the service due to misconduct of an incumbent of a position and establishes the risk level of that position. The PDS assessment also determines if the duties and responsibilities of the position present the potential for position incumbents to bring about a material adverse effect on national security and the degree of that potential effect, which establishes the sensitivity level of a position. The results of the assessment determine what level of investigation is conducted for a position. Risk designations can guide and inform the types of authorizations that individuals receive when accessing organizational information and information systems. Position screening criteria include explicit information security role appointment requirements. Parts 1400 and 731 of Title 5, Code of Federal Regulations, establish the requirements for organizations to evaluate relevant covered positions for a position sensitivity and position risk designation commensurate with the duties and responsibilities of those positions." + }, + { + "ref": "PS-3", + "title": "Personnel Screening", + "summary": "Personnel Screening\na. Screen individuals prior to authorizing access to the system; and\nb. Rescreen individuals in accordance with for national security clearances; a reinvestigation is required during the fifth (5th) year for top secret security clearance, the tenth (10th) year for secret security clearance, and fifteenth (15th) year for confidential security clearance.\n\nFor moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the fifth (5th) year. There is no reinvestigation for other moderate risk positions or any low risk positions.", + "guidance": "Personnel screening and rescreening activities reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, and specific criteria established for the risk designations of assigned positions. Examples of personnel screening include background investigations and agency checks. Organizations may define different rescreening conditions and frequencies for personnel accessing systems based on types of information processed, stored, or transmitted by the systems." + }, + { + "ref": "PS-4", + "title": "Personnel Termination", + "summary": "Personnel Termination\nUpon termination of individual employment:\na. Disable system access within four (4) hours;\nb. Terminate or revoke any authenticators and credentials associated with the individual;\nc. Conduct exit interviews that include a discussion of {{ information security topics - information security topics to be discussed when conducting exit interviews are defined; }};\nd. Retrieve all security-related organizational system-related property; and\ne. Retain access to organizational information and systems formerly controlled by terminated individual.", + "guidance": "System property includes hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that proper accountability is achieved for system-related property. Security topics at exit interviews include reminding individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not always be possible for some individuals, including in cases related to the unavailability of supervisors, illnesses, or job abandonment. Exit interviews are important for individuals with security clearances. The timely execution of termination actions is essential for individuals who have been terminated for cause. In certain situations, organizations consider disabling the system accounts of individuals who are being terminated prior to the individuals being notified." + }, + { + "ref": "PS-5", + "title": "Personnel Transfer", + "summary": "Personnel Transfer\na. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization;\nb. Initiate {{ transfer or reassignment actions - transfer or reassignment actions to be initiated following transfer or reassignment are defined; }} within twenty-four (24) hours ;\nc. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and\nd. Notify {{ personnel or roles - personnel or roles to be notified when individuals are reassigned or transferred to other positions within the organization is/are defined; }} within twenty-four (24) hours.", + "guidance": "Personnel transfer applies when reassignments or transfers of individuals are permanent or of such extended duration as to make the actions warranted. Organizations define actions appropriate for the types of reassignments or transfers, whether permanent or extended. Actions that may be required for personnel transfers or reassignments to other positions within organizations include returning old and issuing new keys, identification cards, and building passes; closing system accounts and establishing new accounts; changing system access authorizations (i.e., privileges); and providing for access to official records to which individuals had access at previous work locations and in previous system accounts." + }, + { + "ref": "PS-6", + "title": "Access Agreements", + "summary": "Access Agreements\na. Develop and document access agreements for organizational systems;\nb. Review and update the access agreements at least annually ; and\nc. Verify that individuals requiring access to organizational information and systems:\n1. Sign appropriate access agreements prior to being granted access; and\n2. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated or at least annually and any time there is a change to the user's level of access.", + "guidance": "Access agreements include nondisclosure agreements, acceptable use agreements, rules of behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with organizational systems to which access is authorized. Organizations can use electronic signatures to acknowledge access agreements unless specifically prohibited by organizational policy." + }, + { + "ref": "PS-7", + "title": "External Personnel Security", + "summary": "External Personnel Security\na. Establish personnel security requirements, including security roles and responsibilities for external providers;\nb. Require external providers to comply with personnel security policies and procedures established by the organization;\nc. Document personnel security requirements;\nd. Require external providers to notify including access control personnel responsible for the system and/or facilities, as appropriate of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within within twenty-four (24) hours ; and\ne. Monitor provider compliance with personnel security requirements.", + "guidance": "External provider refers to organizations other than the organization operating or acquiring the system. External providers include service bureaus, contractors, and other organizations that provide system development, information technology services, testing or assessment services, outsourced applications, and network/security management. Organizations explicitly include personnel security requirements in acquisition-related documents. External providers may have personnel working at organizational facilities with credentials, badges, or system privileges issued by organizations. Notifications of external personnel changes ensure the appropriate termination of privileges and credentials. Organizations define the transfers and terminations deemed reportable by security-related characteristics that include functions, roles, and the nature of credentials or privileges associated with transferred or terminated individuals." + }, + { + "ref": "PS-8", + "title": "Personnel Sanctions", + "summary": "Personnel Sanctions\na. Employ a formal sanctions process for individuals failing to comply with established information security and privacy policies and procedures; and\nb. Notify at a minimum, the ISSO and/or similar role within the organization within {{ time period - the time period within which organization-defined personnel or roles must be notified when a formal employee sanctions process is initiated is defined; }} when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction.", + "guidance": "Organizational sanctions reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Sanctions processes are described in access agreements and can be included as part of general personnel policies for organizations and/or specified in security and privacy policies. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions." + }, + { + "ref": "PS-9", + "title": "Position Descriptions", + "summary": "Position Descriptions\nIncorporate security and privacy roles and responsibilities into organizational position descriptions.", + "guidance": "Specification of security and privacy roles in individual organizational position descriptions facilitates clarity in understanding the security or privacy responsibilities associated with the roles and the role-based security and privacy training requirements for the roles." + } + ] + }, + { + "title": "Risk Assessment", + "controls": [ + { + "ref": "RA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} risk assessment policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the risk assessment policy and the associated risk assessment controls;\nb. Designate an {{ official - an official to manage the risk assessment policy and procedures is defined; }} to manage the development, documentation, and dissemination of the risk assessment policy and procedures; and\nc. Review and update the current risk assessment:\n1. Policy at least every 3 years and following {{ events - events that would require the current risk assessment policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Risk assessment policy and procedures address the controls in the RA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of risk assessment policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to risk assessment policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "RA-2", + "title": "Security Categorization", + "summary": "Security Categorization\na. Categorize the system and information it processes, stores, and transmits;\nb. Document the security categorization results, including supporting rationale, in the security plan for the system; and\nc. Verify that the authorizing official or authorizing official designated representative reviews and approves the security categorization decision.", + "guidance": "Security categories describe the potential adverse impacts or negative consequences to organizational operations, organizational assets, and individuals if organizational information and systems are compromised through a loss of confidentiality, integrity, or availability. Security categorization is also a type of asset loss characterization in systems security engineering processes that is carried out throughout the system development life cycle. Organizations can use privacy risk assessments or privacy impact assessments to better understand the potential adverse effects on individuals. [CNSSI 1253] provides additional guidance on categorization for national security systems.\n\nOrganizations conduct the security categorization process as an organization-wide activity with the direct involvement of chief information officers, senior agency information security officers, senior agency officials for privacy, system owners, mission and business owners, and information owners or stewards. Organizations consider the potential adverse impacts to other organizations and, in accordance with [USA PATRIOT] and Homeland Security Presidential Directives, potential national-level adverse impacts.\n\nSecurity categorization processes facilitate the development of inventories of information assets and, along with [CM-8] , mappings to specific system components where information is processed, stored, or transmitted. The security categorization process is revisited throughout the system development life cycle to ensure that the security categories remain accurate and relevant." + }, + { + "ref": "RA-3", + "title": "Risk Assessment", + "summary": "Risk Assessment\na. Conduct a risk assessment, including:\n1. Identifying threats to and vulnerabilities in the system;\n2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and\n3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;\nb. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments;\nc. Document risk assessment results in security assessment report;\nd. Review risk assessment results at least every three (3) years and when a significant change occurs;\ne. Disseminate risk assessment results to {{ personnel or roles - personnel or roles to whom risk assessment results are to be disseminated is/are defined; }} ; and\nf. Update the risk assessment at least every three (3) years or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.\nRA-3 Additional FedRAMP Requirements and Guidance (e) Requirement: Include all Authorizing Officials; for JAB authorizations to include FedRAMP.\ncontrols RA-3(1) Supply Chain Risk Assessment\n(a) Assess supply chain risks associated with {{ systems, system components, and system services - systems, system components, and system services to assess supply chain risks are defined; }} ; and\n(b) Update the supply chain risk assessment {{ frequency - the frequency at which to update the supply chain risk assessment is defined; }} , when there are significant changes to the relevant supply chain, or when changes to the system, environments of operation, or other conditions may necessitate a change in the supply chain.", + "guidance": "Risk assessments consider threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation. Risk assessments also consider risk from external parties, including contractors who operate systems on behalf of the organization, individuals who access organizational systems, service providers, and outsourcing entities.\n\nOrganizations can conduct risk assessments at all three levels in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any stage in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including preparation, categorization, control selection, control implementation, control assessment, authorization, and control monitoring. Risk assessment is an ongoing activity carried out throughout the system development life cycle.\n\nRisk assessments can also address information related to the system, including system design, the intended use of the system, testing results, and supply chain-related information or artifacts. Risk assessments can play an important role in control selection processes, particularly during the application of tailoring guidance and in the earliest phases of capability determination." + }, + { + "ref": "RA-5", + "title": "Vulnerability Monitoring and Scanning", + "summary": "Vulnerability Monitoring and Scanning\na. Monitor and scan for vulnerabilities in the system and hosted applications monthly operating system/infrastructure; monthly web applications (including APIs) and databases and when new vulnerabilities potentially affecting the system are identified and reported;\nb. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n1. Enumerating platforms, software flaws, and improper configurations;\n2. Formatting checklists and test procedures; and\n3. Measuring vulnerability impact;\nc. Analyze vulnerability scan reports and results from vulnerability monitoring;\nd. Remediate legitimate vulnerabilities high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery in accordance with an organizational assessment of risk;\ne. Share information obtained from the vulnerability monitoring process and control assessments with {{ personnel or roles - personnel or roles with whom information obtained from the vulnerability scanning process and control assessments is to be shared; }} to help eliminate similar vulnerabilities in other systems; and\nf. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.\nRA-5 Additional FedRAMP Requirements and Guidance (a) Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.\n(d) Requirement: If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.\n(e) Requirement: to include all Authorizing Officials; for JAB authorizations to include FedRAMP\ncontrols RA-5(2) Update Vulnerabilities to Be Scanned\nUpdate the system vulnerabilities to be scanned prior to a new scan.\nRA-5(11) Public Disclosure Program\nEstablish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components.", + "guidance": "Security categorization of information and systems guides the frequency and comprehensiveness of vulnerability monitoring (including scans). Organizations determine the required vulnerability monitoring for system components, ensuring that the potential sources of vulnerabilities\u2014such as infrastructure components (e.g., switches, routers, guards, sensors), networked printers, scanners, and copiers\u2014are not overlooked. The capability to readily update vulnerability monitoring tools as new vulnerabilities are discovered and announced and as new scanning methods are developed helps to ensure that new vulnerabilities are not missed by employed vulnerability monitoring tools. The vulnerability monitoring tool update process helps to ensure that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability monitoring and analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can use these analysis approaches in source code reviews and in a variety of tools, including web-based application scanners, static analysis tools, and binary analyzers.\n\nVulnerability monitoring includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for flow control mechanisms that are improperly configured or operating incorrectly. Vulnerability monitoring may also include continuous vulnerability monitoring tools that use instrumentation to continuously analyze components. Instrumentation-based tools may improve accuracy and may be run throughout an organization without scanning. Vulnerability monitoring tools that facilitate interoperability include tools that are Security Content Automated Protocol (SCAP)-validated. Thus, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Control assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan. Organizations also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS).\n\nVulnerability monitoring includes a channel and process for receiving reports of security vulnerabilities from the public at-large. Vulnerability disclosure programs can be as simple as publishing a monitored email address or web form that can receive reports, including notification authorizing good-faith research and disclosure of security vulnerabilities. Organizations generally expect that such research is happening with or without their authorization and can use public vulnerability disclosure channels to increase the likelihood that discovered vulnerabilities are reported directly to the organization for remediation.\n\nOrganizations may also employ the use of financial incentives (also known as \"bug bounties\" ) to further encourage external security researchers to report discovered vulnerabilities. Bug bounty programs can be tailored to the organization\u2019s needs. Bounties can be operated indefinitely or over a defined period of time and can be offered to the general public or to a curated group. Organizations may run public and private bounties simultaneously and could choose to offer partially credentialed access to certain participants in order to evaluate security vulnerabilities from privileged vantage points." + }, + { + "ref": "RA-7", + "title": "Risk Response", + "summary": "Risk Response\nRespond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance.", + "guidance": "Organizations have many options for responding to risk including mitigating risk by implementing new controls or strengthening existing controls, accepting risk with appropriate justification or rationale, sharing or transferring risk, or avoiding risk. The risk tolerance of the organization influences risk response decisions and actions. Risk response addresses the need to determine an appropriate response to risk before generating a plan of action and milestones entry. For example, the response may be to accept risk or reject risk, or it may be possible to mitigate the risk immediately so that a plan of action and milestones entry is not needed. However, if the risk response is to mitigate the risk, and the mitigation cannot be completed immediately, a plan of action and milestones entry is generated." + } + ] + }, + { + "title": "System and Services Acquisition", + "controls": [ + { + "ref": "SA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} system and services acquisition policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;\nb. Designate an {{ official - an official to manage the system and services acquisition policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and\nc. Review and update the current system and services acquisition:\n1. Policy at least every 3 years and following {{ events - events that would require the current system and services acquisition policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SA-2", + "title": "Allocation of Resources", + "summary": "Allocation of Resources\na. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;\nb. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and\nc. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.", + "guidance": "Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle." + }, + { + "ref": "SA-3", + "title": "System Development Life Cycle", + "summary": "System Development Life Cycle\na. Acquire, develop, and manage the system using {{ system-development life cycle - system development life cycle is defined; }} that incorporates information security and privacy considerations;\nb. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;\nc. Identify individuals having information security and privacy roles and responsibilities; and\nd. Integrate the organizational information security and privacy risk management process into system development life cycle activities.", + "guidance": "A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in [SA-8] help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.\n\nThe effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle." + }, + { + "ref": "SA-4", + "title": "Acquisition Process", + "summary": "Acquisition Process\nInclude the following requirements, descriptions, and criteria, explicitly or by reference, using {{ one or more: standardized contract language, {{ contract language - contract language is defined (if selected); }} }} in the acquisition contract for the system, system component, or system service:\na. Security and privacy functional requirements;\nb. Strength of mechanism requirements;\nc. Security and privacy assurance requirements;\nd. Controls needed to satisfy the security and privacy requirements.\ne. Security and privacy documentation requirements;\nf. Requirements for protecting security and privacy documentation;\ng. Description of the system development environment and environment in which the system is intended to operate;\nh. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and\ni. Acceptance criteria.\nSA-4 Additional FedRAMP Requirements and Guidance Requirement: The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).\ncontrols SA-4(10) Use of Approved PIV Products\nEmploy only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.", + "guidance": "Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in [SA-2] . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1] describes the process of requirements engineering as part of the system development life cycle.\n\nControls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle.\n\nSecurity and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement." + }, + { + "ref": "SA-5", + "title": "System Documentation", + "summary": "System Documentation\na. Obtain or develop administrator documentation for the system, system component, or system service that describes:\n1. Secure configuration, installation, and operation of the system, component, or service;\n2. Effective use and maintenance of security and privacy functions and mechanisms; and\n3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;\nb. Obtain or develop user documentation for the system, system component, or system service that describes:\n1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;\n2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and\n3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;\nc. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take {{ actions - actions to take when system, system component, or system service documentation is either unavailable or nonexistent are defined; }} in response; and\nd. Distribute documentation to at a minimum, the ISSO (or similar role within the organization).", + "guidance": "System documentation helps personnel understand the implementation and operation of controls. Organizations consider establishing specific measures to determine the quality and completeness of the content provided. System documentation may be used to support the management of supply chain risk, incident response, and other functions. Personnel or roles that require documentation include system owners, system security officers, and system administrators. Attempts to obtain documentation include contacting manufacturers or suppliers and conducting web-based searches. The inability to obtain documentation may occur due to the age of the system or component or the lack of support from developers and contractors. When documentation cannot be obtained, organizations may need to recreate the documentation if it is essential to the implementation or operation of the controls. The protection provided for the documentation is commensurate with the security category or classification of the system. Documentation that addresses system vulnerabilities may require an increased level of protection. Secure operation of the system includes initially starting the system and resuming secure system operation after a lapse in system operation." + }, + { + "ref": "SA-8", + "title": "Security and Privacy Engineering Principles", + "summary": "Security and Privacy Engineering Principles\nApply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: {{ organization-defined systems security and privacy engineering principles }}.", + "guidance": "Systems security and privacy engineering principles are closely related to and implemented throughout the system development life cycle (see [SA-3] ). Organizations can apply systems security and privacy engineering principles to new systems under development or to systems undergoing upgrades. For existing systems, organizations apply systems security and privacy engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems.\n\nThe application of systems security and privacy engineering principles helps organizations develop trustworthy, secure, and resilient systems and reduces the susceptibility to disruptions, hazards, threats, and the creation of privacy problems for individuals. Examples of system security engineering principles include: developing layered protections; establishing security and privacy policies, architecture, and controls as the foundation for design and development; incorporating security and privacy requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; tailoring controls to meet organizational needs; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk.\n\nOrganizations that apply systems security and privacy engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk management decisions. System security engineering principles can also be used to protect against certain supply chain risks, including incorporating tamper-resistant hardware into a design." + }, + { + "ref": "SA-9", + "title": "External System Services", + "summary": "External System Services\na. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: Appropriate FedRAMP Security Controls Baseline (s) if Federal information is processed or stored within the external system;\nb. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and\nc. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored.", + "guidance": "External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust vary based on relationships between organizations and the external providers. Organizations document the basis for the trust relationships so that the relationships can be monitored. External system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define the expectations of performance for implemented controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance." + }, + { + "ref": "SA-22", + "title": "Unsupported System Components", + "summary": "Unsupported System Components\na. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or\nb. Provide the following options for alternative sources for continued support for unsupported components {{ one or more: in-house support, {{ support from external providers - support from external providers is defined (if selected); }} }}.", + "guidance": "Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option.\n\nAlternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation." + } + ] + }, + { + "title": "System and Communications Protection", + "controls": [ + { + "ref": "SC-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business-process-level, system-level }} system and communications protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls;\nb. Designate an {{ official - an official to manage the system and communications protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and\nc. Review and update the current system and communications protection:\n1. Policy at least every 3 years and following {{ events - events that would require the current system and communications protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and communications protection policy and procedures address the controls in the SC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and communications protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and communications protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SC-5", + "title": "Denial-of-service Protection", + "summary": "Denial-of-service Protection\na. Protect against the effects of the following types of denial-of-service events: at a minimum: ICMP (ping) flood, SYN flood, slowloris, buffer overflow attack, and volume attack ; and\nb. Employ the following controls to achieve the denial-of-service objective: {{ controls by type of denial-of-service event - controls to achieve the denial-of-service objective by type of denial-of-service event are defined; }}.", + "guidance": "Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events." + }, + { + "ref": "SC-7", + "title": "Boundary Protection", + "summary": "Boundary Protection\na. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;\nb. Implement subnetworks for publicly accessible system components that are {{ physically OR logically }} separated from internal organizational networks; and\nc. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.\nSC-7 Additional FedRAMP Requirements and Guidance ", + "guidance": "Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. [SP 800-189] provides additional information on source address validation techniques to prevent ingress and egress of traffic with spoofed addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary)." + }, + { + "ref": "SC-8", + "title": "Transmission Confidentiality and Integrity", + "summary": "Transmission Confidentiality and Integrity\nProtect the {{ one or more: confidentiality, integrity }} of transmitted information.\nSC-8 Additional FedRAMP Requirements and Guidance \ncontrols SC-8(1) Cryptographic Protection\nImplement cryptographic mechanisms to {{ one or more: prevent unauthorized disclosure of information, detect changes to information }} during transmission.\nSC-8 (1) Additional FedRAMP Requirements and Guidance Requirement: Please ensure SSP Section 10.3 Cryptographic Modules Implemented for Data At Rest (DAR) and Data In Transit (DIT) is fully populated for reference in this control.", + "guidance": "Protecting the confidentiality and integrity of transmitted information applies to internal and external networks as well as any system components that can transmit information, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of information can be accomplished by physical or logical means. Physical protection can be achieved by using protected distribution systems. A protected distribution system is a wireline or fiber-optics telecommunications system that includes terminals and adequate electromagnetic, acoustical, electrical, and physical controls to permit its use for the unencrypted transmission of classified information. Logical protection can be achieved by employing encryption techniques.\n\nOrganizations that rely on commercial providers who offer transmission services as commodity services rather than as fully dedicated services may find it difficult to obtain the necessary assurances regarding the implementation of needed controls for transmission confidentiality and integrity. In such situations, organizations determine what types of confidentiality or integrity services are available in standard, commercial telecommunications service packages. If it is not feasible to obtain the necessary controls and assurances of control effectiveness through appropriate contracting vehicles, organizations can implement appropriate compensating controls." + }, + { + "ref": "SC-12", + "title": "Cryptographic Key Establishment and Management", + "summary": "Cryptographic Key Establishment and Management\nEstablish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: In accordance with Federal requirements.\nSC-12 Additional FedRAMP Requirements and Guidance ", + "guidance": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment." + }, + { + "ref": "SC-13", + "title": "Cryptographic Protection", + "summary": "Cryptographic Protection\na. Determine the {{ cryptographic uses - cryptographic uses are defined; }} ; and\nb. Implement the following types of cryptography required for each specified cryptographic use: FIPS-validated or NSA-approved cryptography.\nSC-13 Additional FedRAMP Requirements and Guidance ", + "guidance": "Cryptography can be employed to support a variety of security solutions, including the protection of classified information and controlled unclassified information, the provision and implementation of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances but lack the necessary formal access approvals. Cryptography can also be used to support random number and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. For example, organizations that need to protect classified information may specify the use of NSA-approved cryptography. Organizations that need to provision and implement digital signatures may specify the use of FIPS-validated cryptography. Cryptography is implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "SC-15", + "title": "Collaborative Computing Devices and Applications", + "summary": "Collaborative Computing Devices and Applications\na. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: no exceptions for computing devices ; and\nb. Provide an explicit indication of use to users physically present at the devices.\nSC-15 Additional FedRAMP Requirements and Guidance Requirement: The information system provides disablement (instead of physical disconnect) of collaborative computing devices in a manner that supports ease of use.", + "guidance": "Collaborative computing devices and applications include remote meeting devices and applications, networked white boards, cameras, and microphones. The explicit indication of use includes signals to users when collaborative computing devices and applications are activated." + }, + { + "ref": "SC-20", + "title": "Secure Name/Address Resolution Service (Authoritative Source)", + "summary": "Secure Name/Address Resolution Service (Authoritative Source)\na. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and\nb. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.\nSC-20 Additional FedRAMP Requirements and Guidance Requirement: Control Description should include how DNSSEC is implemented on authoritative DNS servers to supply valid responses to external DNSSEC requests.", + "guidance": "Providing authoritative source information enables external clients, including remote Internet clients, to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Systems that provide name and address resolution services include domain name system (DNS) servers. Additional artifacts include DNS Security Extensions (DNSSEC) digital signatures and cryptographic keys. Authoritative data includes DNS resource records. The means for indicating the security status of child zones include the use of delegation signer resource records in the DNS. Systems that use technologies other than the DNS to map between host and service names and network addresses provide other means to assure the authenticity and integrity of response data." + }, + { + "ref": "SC-21", + "title": "Secure Name/Address Resolution Service (Recursive or Caching Resolver)", + "summary": "Secure Name/Address Resolution Service (Recursive or Caching Resolver)\nRequest and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.\nSC-21 Additional FedRAMP Requirements and Guidance Requirement: Internal recursive DNS servers must be located inside an authorized environment. It is typically within the boundary, or leveraged from an underlying IaaS/PaaS.", + "guidance": "Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Systems that provide name and address resolution services for local clients include recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Systems that use technologies other than the DNS to map between host and service names and network addresses provide some other means to enable clients to verify the authenticity and integrity of response data." + }, + { + "ref": "SC-22", + "title": "Architecture and Provisioning for Name/Address Resolution Service", + "summary": "Architecture and Provisioning for Name/Address Resolution Service\nEnsure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.", + "guidance": "Systems that provide name and address resolution services include domain name system (DNS) servers. To eliminate single points of failure in systems and enhance redundancy, organizations employ at least two authoritative domain name system servers\u2014one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks, including the Internet). Organizations specify clients that can access authoritative DNS servers in certain roles (e.g., by address ranges and explicit lists)." + }, + { + "ref": "SC-28", + "title": "Protection of Information at Rest", + "summary": "Protection of Information at Rest\nProtect the {{ one or more: confidentiality, integrity }} of the following information at rest: {{ information at rest - information at rest requiring protection is defined; }}.\nSC-28 Additional FedRAMP Requirements and Guidance \ncontrols SC-28(1) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on all information system components storing Federal data or system data that must be protected at the High or Moderate impact levels: {{ information - information requiring cryptographic protection is defined; }}.\nSC-28 (1) Additional FedRAMP Requirements and Guidance ", + "guidance": "Information at rest refers to the state of information when it is not in process or in transit and is located on system components. Such components include internal or external hard disk drives, storage area network devices, or databases. However, the focus of protecting information at rest is not on the type of storage device or frequency of access but rather on the state of the information. Information at rest addresses the confidentiality and integrity of information and covers user information and system information. System-related information that requires protection includes configurations or rule sets for firewalls, intrusion detection and prevention systems, filtering routers, and authentication information. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing write-once-read-many (WORM) technologies. When adequate protection of information at rest cannot otherwise be achieved, organizations may employ other controls, including frequent scanning to identify malicious code at rest and secure offline storage in lieu of online storage." + }, + { + "ref": "SC-39", + "title": "Process Isolation", + "summary": "Process Isolation\nMaintain a separate execution domain for each executing system process.", + "guidance": "Systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. Process isolation technologies, including sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. Process isolation helps limit the access of potentially untrusted software to other system resources. The capability to maintain separate execution domains is available in commercial operating systems that employ multi-state processor technologies." + } + ] + }, + { + "title": "System and Information Integrity", + "controls": [ + { + "ref": "SI-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} system and information integrity policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and information integrity policy and the associated system and information integrity controls;\nb. Designate an {{ official - an official to manage the system and information integrity policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and information integrity policy and procedures; and\nc. Review and update the current system and information integrity:\n1. Policy at least every 3 years and following {{ events - events that would require the current system and information integrity policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and information integrity policy and procedures address the controls in the SI family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and information integrity policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and information integrity policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SI-2", + "title": "Flaw Remediation", + "summary": "Flaw Remediation\na. Identify, report, and correct system flaws;\nb. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;\nc. Install security-relevant software and firmware updates within within thirty (30) days of release of updates of the release of the updates; and\nd. Incorporate flaw remediation into the organizational configuration management process.", + "guidance": "The need to remediate system flaws applies to all types of software and firmware. Organizations identify systems affected by software flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security and privacy responsibilities. Security-relevant updates include patches, service packs, and malicious code signatures. Organizations also address flaws discovered during assessments, continuous monitoring, incident response activities, and system error handling. By incorporating flaw remediation into configuration management processes, required remediation actions can be tracked and verified.\n\nOrganization-defined time periods for updating security-relevant software and firmware may vary based on a variety of risk factors, including the security category of the system, the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw), the organizational risk tolerance, the mission supported by the system, or the threat environment. Some types of flaw remediation may require more testing than other types. Organizations determine the type of testing needed for the specific type of flaw remediation activity under consideration and the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software or firmware updates is not necessary or practical, such as when implementing simple malicious code signature updates. In testing decisions, organizations consider whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures." + }, + { + "ref": "SI-3", + "title": "Malicious Code Protection", + "summary": "Malicious Code Protection\na. Implement signature based and non-signature based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code;\nb. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures;\nc. Configure malicious code protection mechanisms to:\n1. Perform periodic scans of the system at least weekly and real-time scans of files from external sources at to include endpoints and network entry and exit points as the files are downloaded, opened, or executed in accordance with organizational policy; and\n2. to include blocking and quarantining malicious code ; and send alert to {{ personnel or roles - personnel or roles to be alerted when malicious code is detected is/are defined; }} in response to malicious code detection; and\nd. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system.", + "guidance": "System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world-wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code.\n\nMalicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions.\n\nIn situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files." + }, + { + "ref": "SI-4", + "title": "System Monitoring", + "summary": "System Monitoring\na. Monitor the system to detect:\n1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: {{ monitoring objectives - monitoring objectives to detect attacks and indicators of potential attacks on the system are defined; }} ; and\n2. Unauthorized local, network, and remote connections;\nb. Identify unauthorized use of the system through the following techniques and methods: {{ techniques and methods - techniques and methods used to identify unauthorized use of the system are defined; }};\nc. Invoke internal monitoring capabilities or deploy monitoring devices:\n1. Strategically within the system to collect organization-determined essential information; and\n2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;\nd. Analyze detected events and anomalies;\ne. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation;\nf. Obtain legal opinion regarding system monitoring activities; and\ng. Provide {{ system monitoring information - system monitoring information to be provided to personnel or roles is defined; }} to {{ personnel or roles - personnel or roles to whom system monitoring information is to be provided is/are defined; }} {{ one or more: as needed, {{ frequency - a frequency for providing system monitoring to personnel or roles is defined (if selected); }} }}.\nSI-4 Additional FedRAMP Requirements and Guidance ", + "guidance": "System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at external interfaces to the system. Internal monitoring includes the observation of events occurring within the system. Organizations monitor systems by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives guide and inform the determination of the events. System monitoring capabilities are achieved through a variety of tools and techniques, including intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software.\n\nDepending on the security architecture, the distribution and configuration of monitoring devices may impact throughput at key internal and external boundaries as well as at other locations across a network due to the introduction of network throughput latency. If throughput management is needed, such devices are strategically located and deployed as part of an established organization-wide security architecture. Strategic locations for monitoring devices include selected perimeter locations and near key servers and server farms that support critical applications. Monitoring devices are typically employed at the managed interfaces associated with controls [SC-7] and [AC-17] . The information collected is a function of the organizational monitoring objectives and the capability of systems to support such objectives. Specific types of transactions of interest include Hypertext Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring is an integral part of organizational continuous monitoring and incident response programs, and output from system monitoring serves as input to those programs. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other controls (e.g., [AC-2g], [AC-2(7)], [AC-2(12)(a)], [AC-17(1)], [AU-13], [AU-13(1)], [AU-13(2)], [CM-3f], [CM-6d], [MA-3a], [MA-4a], [SC-5(3)(b)], [SC-7a], [SC-7(24)(b)], [SC-18b], [SC-43b] ). Adjustments to levels of system monitoring are based on law enforcement information, intelligence information, or other sources of information. The legality of system monitoring activities is based on applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "SI-5", + "title": "Security Alerts, Advisories, and Directives", + "summary": "Security Alerts, Advisories, and Directives\na. Receive system security alerts, advisories, and directives from to include US-CERT and Cybersecurity and Infrastructure Security Agency (CISA) Directives on an ongoing basis;\nb. Generate internal security alerts, advisories, and directives as deemed necessary;\nc. Disseminate security alerts, advisories, and directives to: to include system security personnel and administrators with configuration/patch-management responsibilities ; and\nd. Implement security directives in accordance with established time frames, or notify the issuing organization of the degree of noncompliance.\nRequirement: Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.", + "guidance": "The Cybersecurity and Infrastructure Security Agency (CISA) generates security alerts and advisories to maintain situational awareness throughout the Federal Government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance with security directives is essential due to the critical nature of many of these directives and the potential (immediate) adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include supply chain partners, external mission or business partners, external service providers, and other peer or supporting organizations." + }, + { + "ref": "SI-12", + "title": "Information Management and Retention", + "summary": "Information Management and Retention\nManage and retain information within the system and information output from the system in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements.", + "guidance": "Information management and retention requirements cover the full life cycle of information, in some cases extending beyond system disposal. Information to be retained may also include policies, procedures, plans, reports, data output from control implementation, and other types of administrative information. The National Archives and Records Administration (NARA) provides federal policy and guidance on records retention and schedules. If organizations have a records management office, consider coordinating with records management personnel. Records produced from the output of implemented controls that may require management and retention include, but are not limited to: All XX-1, [AC-6(9)], [AT-4], [AU-12], [CA-2], [CA-3], [CA-5], [CA-6], [CA-7], [CA-8], [CA-9], [CM-2], [CM-3], [CM-4], [CM-6], [CM-8], [CM-9], [CM-12], [CM-13], [CP-2], [IR-6], [IR-8], [MA-2], [MA-4], [PE-2], [PE-8], [PE-16], [PE-17], [PL-2], [PL-4], [PL-7], [PL-8], [PM-5], [PM-8], [PM-9], [PM-18], [PM-21], [PM-27], [PM-28], [PM-30], [PM-31], [PS-2], [PS-6], [PS-7], [PT-2], [PT-3], [PT-7], [RA-2], [RA-3], [RA-5], [RA-8], [SA-4], [SA-5], [SA-8], [SA-10], [SI-4], [SR-2], [SR-4], [SR-8]." + } + ] + }, + { + "title": "Supply Chain Risk Management", + "controls": [ + { + "ref": "SR-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} supply chain risk management policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the supply chain risk management policy and the associated supply chain risk management controls;\nb. Designate an {{ official - an official to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures is defined; }} to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures; and\nc. Review and update the current supply chain risk management:\n1. Policy at least every 3 years and following {{ events - events that require the current supply chain risk management policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Supply chain risk management policy and procedures address the controls in the SR family as well as supply chain-related controls in other families that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of supply chain risk management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to supply chain risk management policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SR-2", + "title": "Supply Chain Risk Management Plan", + "summary": "Supply Chain Risk Management Plan\na. Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of the following systems, system components or system services: {{ systems, system components, or system services - systems, system components, or system services for which a supply chain risk management plan is developed are defined; }};\nb. Review and update the supply chain risk management plan at least annually or as required, to address threat, organizational or environmental changes; and\nc. Protect the supply chain risk management plan from unauthorized disclosure and modification.\ncontrols SR-2(1) Establish SCRM Team\nEstablish a supply chain risk management team consisting of {{ personnel, roles and responsibilities - the personnel, roles, and responsibilities of the supply chain risk management team are defined; }} to lead and support the following SCRM activities: {{ supply chain risk management activities - supply chain risk management activities are defined; }}.", + "guidance": "The dependence on products, systems, and services from external providers, as well as the nature of the relationships with those providers, present an increasing level of risk to an organization. Threat actions that may increase security or privacy risks include unauthorized production, the insertion or use of counterfeits, tampering, theft, insertion of malicious software and hardware, and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system element or component, a system, an organization, a sector, or the Nation. Managing supply chain risk is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders. Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against plans. The SCRM plan (at the system-level) is implementation specific, providing policy implementation, requirements, constraints and implications. It can either be stand-alone, or incorporated into system security and privacy plans. The SCRM plan addresses managing, implementation, and monitoring of SCRM controls and the development/sustainment of systems across the SDLC to support mission and business functions.\n\nBecause supply chains can differ significantly across and within organizations, SCRM plans are tailored to the individual program, organizational, and operational contexts. Tailored SCRM plans provide the basis for determining whether a technology, service, system component, or system is fit for purpose, and as such, the controls need to be tailored accordingly. Tailored SCRM plans help organizations focus their resources on the most critical mission and business functions based on mission and business requirements and their risk environment. Supply chain risk management plans include an expression of the supply chain risk tolerance for the organization, acceptable supply chain risk mitigation strategies or controls, a process for consistently evaluating and monitoring supply chain risk, approaches for implementing and communicating the plan, a description of and justification for supply chain risk mitigation measures taken, and associated roles and responsibilities. Finally, supply chain risk management plans address requirements for developing trustworthy, secure, privacy-protective, and resilient system components and systems, including the application of the security design principles implemented as part of life cycle-based systems security engineering processes (see [SA-8])." + }, + { + "ref": "SR-3", + "title": "Supply Chain Controls and Processes", + "summary": "Supply Chain Controls and Processes\na. Establish a process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes of {{ system or system component - the system or system component requiring a process or processes to identify and address weaknesses or deficiencies is defined; }} in coordination with {{ supply chain personnel - supply chain personnel with whom to coordinate the process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes is/are defined; }};\nb. Employ the following controls to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events: {{ supply chain controls - supply chain controls employed to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events are defined; }} ; and\nc. Document the selected and implemented supply chain processes and controls in {{ one or more: security and privacy plans, supply chain risk management plan, {{ document - the document identifying the selected and implemented supply chain processes and controls is defined (if selected); }} }}.\nSR-3 Additional FedRAMP Requirements and Guidance Requirement: CSO must document and maintain the supply chain custody, including replacement devices, to ensure the integrity of the devices before being introduced to the boundary.", + "guidance": "Supply chain elements include organizations, entities, or tools employed for the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, and firmware development processes; shipping and handling procedures; personnel security and physical security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components. Supply chain elements and processes may be provided by organizations, system integrators, or external providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to cause harm to the organization and affect its ability to carry out its core missions or business functions. Supply chain personnel are individuals with roles and responsibilities in the supply chain." + }, + { + "ref": "SR-5", + "title": "Acquisition Strategies, Tools, and Methods", + "summary": "Acquisition Strategies, Tools, and Methods\nEmploy the following acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks: {{ strategies, tools, and methods - acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks are defined; }}.", + "guidance": "The use of the acquisition process provides an important vehicle to protect the supply chain. There are many useful tools and techniques available, including obscuring the end use of a system or system component, using blind or filtered buys, requiring tamper-evident packaging, or using trusted or controlled distribution. The results from a supply chain risk assessment can guide and inform the strategies, tools, and methods that are most applicable to the situation. Tools and techniques may provide protections against unauthorized production, theft, tampering, insertion of counterfeits, insertion of malicious software or backdoors, and poor development practices throughout the system development life cycle. Organizations also consider providing incentives for suppliers who implement controls, promote transparency into their processes and security and privacy practices, provide contract language that addresses the prohibition of tainted or counterfeit components, and restrict purchases from untrustworthy suppliers. Organizations consider providing training, education, and awareness programs for personnel regarding supply chain risk, available mitigation strategies, and when the programs should be employed. Methods for reviewing and protecting development plans, documentation, and evidence are commensurate with the security and privacy requirements of the organization. Contracts may specify documentation protection requirements." + }, + { + "ref": "SR-8", + "title": "Notification Agreements", + "summary": "Notification Agreements\nEstablish agreements and procedures with entities involved in the supply chain for the system, system component, or system service for the notification of supply chain compromises and results of assessment or audits.\nSR-8 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure and document how they receive notifications from their supply chain vendor of newly discovered vulnerabilities including zero-day vulnerabilities.", + "guidance": "The establishment of agreements and procedures facilitates communications among supply chain entities. Early notification of compromises and potential compromises in the supply chain that can potentially adversely affect or have adversely affected organizational systems or system components is essential for organizations to effectively respond to such incidents. The results of assessments or audits may include open-source information that contributed to a decision or result and could be used to help the supply chain entity resolve a concern or improve its processes." + }, + { + "ref": "SR-10", + "title": "Inspection of Systems or Components", + "summary": "Inspection of Systems or Components\nInspect the following systems or system components {{ one or more: at random, at {{ frequency - frequency at which to inspect systems or system components is defined (if selected); }} , upon {{ indications of need for inspection - indications of the need for an inspection of systems or system components are defined (if selected); }} }} to detect tampering: {{ systems or system components - systems or system components that require inspection are defined; }}.", + "guidance": "The inspection of systems or systems components for tamper resistance and detection addresses physical and logical tampering and is applied to systems and system components removed from organization-controlled areas. Indications of a need for inspection include changes in packaging, specifications, factory location, or entity in which the part is purchased, and when individuals return from travel to high-risk locations." + }, + { + "ref": "SR-11", + "title": "Component Authenticity", + "summary": "Component Authenticity\na. Develop and implement anti-counterfeit policy and procedures that include the means to detect and prevent counterfeit components from entering the system; and\nb. Report counterfeit system components to {{ one or more: source of counterfeit component, {{ external reporting organizations - external reporting organizations to whom counterfeit system components are to be reported is/are defined (if selected); }} , {{ personnel or roles - personnel or roles to whom counterfeit system components are to be reported is/are defined (if selected); }} }}.\nSR-11 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure that their supply chain vendors provide authenticity of software and patches and the vendor must have a plan to protect the development pipeline.\ncontrols SR-11(1) Anti-counterfeit Training\nTrain {{ personnel or roles - personnel or roles requiring training to detect counterfeit system components (including hardware, software, and firmware) is/are defined; }} to detect counterfeit system components (including hardware, software, and firmware).\nSR-11(2) Configuration Control for Component Service and Repair\nMaintain configuration control over the following system components awaiting service or repair and serviced or repaired components awaiting return to service: all.", + "guidance": "Sources of counterfeit components include manufacturers, developers, vendors, and contractors. Anti-counterfeiting policies and procedures support tamper resistance and provide a level of protection against the introduction of malicious code. External reporting organizations include CISA." + }, + { + "ref": "SR-12", + "title": "Component Disposal", + "summary": "Component Disposal\nDispose of {{ data, documentation, tools, or system components - data, documentation, tools, or system components to be disposed of are defined; }} using the following techniques and methods: {{ techniques and methods - techniques and methods for disposing of data, documentation, tools, or system components are defined; }}.", + "guidance": "Data, documentation, tools, or system components can be disposed of at any time during the system development life cycle (not only in the disposal or retirement phase of the life cycle). For example, disposal can occur during research and development, design, prototyping, or operations/maintenance and include methods such as disk cleaning, removal of cryptographic keys, partial reuse of components. Opportunities for compromise during disposal affect physical and logical data, including system documentation in paper-based or digital files; shipping and delivery documentation; memory sticks with software code; or complete routers or servers that include permanent media, which contain sensitive or proprietary information. Additionally, proper disposal of system components helps to prevent such components from entering the gray market." + } + ] } - ] - } - ] + ] } \ No newline at end of file diff --git a/templates/standards/fedramp/v5/fedramp-moderate.json b/templates/standards/fedramp/v5/fedramp-moderate.json index 063d897..e3ea1de 100644 --- a/templates/standards/fedramp/v5/fedramp-moderate.json +++ b/templates/standards/fedramp/v5/fedramp-moderate.json @@ -1,1718 +1,1184 @@ { - "standard": "FedRAMP Moderate", - "version": "NIST 800-53r4", - "basedOn": "NIST 800-53r4", - "webLink": "https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx", - "domains": [ - { - "title": "ACCESS CONTROL", - "controls": [ - { - "ref": "AC-1", - "title": "Access Control Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the access control policy and associated access controls; and\n b. Reviews and updates the current:\n 1. Access control policy **at least every 3 years**; and\n 2. Access control procedures **at least annually**." - }, - { - "ref": "AC-2", - "title": "Account Management", - "summary": "The organization:\n a. Identifies and selects the following types of information system accounts to support organizational missions/business functions: [Assignment: organization-defined information system account types];\n b. Assigns account managers for information system accounts;\n c. Establishes conditions for group and role membership;\n d. Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;\n e. Requires approvals by [Assignment: organization-defined personnel or roles] for requests to create information system accounts;\n f. Creates, enables, modifies, disables, and removes information system accounts in accordance with [Assignment: organization-defined procedures or conditions];\n g. Monitors the use of, information system accounts;\n h. Notifies account managers:\n 1. When accounts are no longer required;\n 2. When users are terminated or transferred; and\n 3. When individual information system usage or need-to-know changes;\n i. Authorizes access to the information system based on:\n 1. A valid access authorization;\n 2. Intended system usage; and\n 3. Other attributes as required by the organization or associated missions/business functions;\n j. Reviews accounts for compliance with account management requirements **at least annually**; and\n k. Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group." - }, - { - "ref": "AC-2 (1)", - "title": "Account Management | Automated System Account Management", - "summary": "The organization employs automated mechanisms to support the management of information system accounts." - }, - { - "ref": "AC-2 (2)", - "title": "Account Management | Removal of Temporary / Emergency Accounts", - "summary": "The information system automatically [Selection: removes; disables] temporary and emergency accounts after **no more than 30 days for temporary and emergency account types**." - }, - { - "ref": "AC-2 (3)", - "title": "Account Management | Disable Inactive Accounts", - "summary": "The information system automatically disables inactive accounts after **90 days for user accounts**." - }, - { - "ref": "AC-2 (4)", - "title": "Account Management | Automated Audit Actions", - "summary": "The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "AC-2 (5)", - "title": "Account Management | Inactivity Logout", - "summary": "The organization requires that users log out when [Assignment: organization-defined time-period of expected inactivity or description of when to log out]." - }, - { - "ref": "AC-2 (7)", - "title": "Account Management | Role-Based Schemes", - "summary": "The organization:\n(a) Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;\n(b) Monitors privileged role assignments; and\n(c) Takes [Assignment: organization-defined actions] when privileged role assignments are no longer appropriate." - }, - { - "ref": "AC-2 (9)", - "title": "Account Management | Restrictions on Use of Shared Groups / Accounts", - "summary": "The organization only permits the use of shared/group accounts that meet [Assignment: organization-defined conditions for establishing shared/group accounts]." - }, - { - "ref": "AC-2 (10)", - "title": "Account Management | Shared / Group Account Credential Termination", - "summary": "The information system terminates shared/group account credentials when members leave the group." - }, - { - "ref": "AC-2 (12)", - "title": "Account Management | Account Monitoring / Atypical Usage", - "summary": "The organization:\n (a) Monitors information system accounts for [Assignment: organization-defined atypical use]; and\n (b) Reports atypical usage of information system accounts to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "AC-3", - "title": "Access Enforcement", - "summary": "The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies." - }, - { - "ref": "AC-4", - "title": "Information Flow Enforcement", - "summary": "The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems based on [Assignment: organization-defined information flow control policies]." - }, - { - "ref": "AC-4 (21)", - "title": "Information Flow Enforcement | Physical / Logical Separation of Information Flows", - "summary": "The information system separates information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques] to accomplish [Assignment: organization- defined required separations by types of information]." - }, - { - "ref": "AC-5", - "title": "Separation of Duties", - "summary": "The organization:\n a. Separates [Assignment: organization-defined duties of individuals];\n b. Documents separation of duties of individuals; and\n c. Defines information system access authorizations to support separation of duties." - }, - { - "ref": "AC-6", - "title": "Least Privilege", - "summary": "The organization employs the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions." - }, - { - "ref": "AC-6 (1)", - "title": "Least Privilege | Authorize Access To Security Functions", - "summary": "The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information]." - }, - { - "ref": "AC-6 (2)", - "title": "Least Privilege | Non-Privileged Access for Nonsecurity Functions", - "summary": "The organization requires that users of information system accounts, or roles, with access to **all security functions**, use non- privileged accounts or roles, when accessing nonsecurity functions." - }, - { - "ref": "AC-6 (5)", - "title": "Least Privilege | Privileged Accounts", - "summary": "The organization restricts privileged accounts on the information system to [Assignment:\norganization-defined personnel or roles]." - }, - { - "ref": "AC-6 (9)", - "title": "Least Privilege | Auditing Use of Privileged Functions", - "summary": "The information system audits the execution of privileged functions." - }, - { - "ref": "AC-6 (10)", - "title": "Least Privilege | Prohibit Non-Privileged Users From Executing Privileged Functions", - "summary": "The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures." - }, - { - "ref": "AC-7", - "title": "Unsuccessful Logon Attempts", - "summary": "The information system:\n a. Enforces a limit of **not more than three (3)** consecutive invalid logon attempts by a user during a **fifteen (15) minutes**; and\n b. Automatically [Selection: locks the account/node for an **locks the account/node for thirty minutes**; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded." - }, - { - "ref": "AC-8", - "title": "System Use Notification", - "summary": "The information system:\n a. Displays to users **see additional Requirements and Guidance** before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that:\n 1. Users are accessing a U.S. Government information system;\n 2. Information system usage may be monitored, recorded, and subject to audit;\n 3. Unauthorized use of the information system is prohibited and subject to criminal and civil penalties; and\n 4. Use of the information system indicates consent to monitoring and recording;\n b. Retains the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the information system; and \n c. For publicly accessible systems:\n 1. Displays system use information [Assignment: organization-defined conditions], before granting further access;\n 2. Displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and\n 3. Includes a description of the authorized uses of the system." - }, - { - "ref": "AC-10", - "title": "Concurrent Session Control", - "summary": "The information system limits the number of concurrent sessions for each **three (3) sessions for privileged access and two (2) sessions for non-privileged access** to [Assignment: organization-defined number]." - }, - { - "ref": "AC-11", - "title": "Session Lock", - "summary": "The information system:\n a. Prevents further access to the system by initiating a session lock after **fifteen (15) minutes** of inactivity or upon receiving a request from a user; and\n b. Retains the session lock until the user reestablishes access using established identification and authentication procedures." - }, - { - "ref": "AC-11 (1)", - "title": "Session Lock | Pattern-Hiding Displays", - "summary": "The information system conceals, via the session lock, information previously visible on the display with a publicly viewable image." - }, - { - "ref": "AC-12", - "title": "Session Termination", - "summary": "The information system automatically terminates a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect]." - }, - { - "ref": "AC-14", - "title": "Permitted Actions Without Identification or Authentication", - "summary": "The organization:\n a. Identifies [Assignment: organization-defined user actions] that can be performed on the information system without identification or authentication consistent with organizational missions/business functions; and\n b. Documents and provides supporting rationale in the security plan for the information system, user actions not requiring identification or authentication." - }, - { - "ref": "AC-17", - "title": "Remote Access", - "summary": "The organization:\n a. Establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\n b. Authorizes remote access to the information system prior to allowing such connections." - }, - { - "ref": "AC-17 (1)", - "title": "Remote Access | Automated Monitoring / Control", - "summary": "The information system monitors and controls remote access methods." - }, - { - "ref": "AC-17 (2)", - "title": "Remote Access | Protection of Confidentiality / Integrity Using Encryption", - "summary": "The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions." - }, - { - "ref": "AC-17 (3)", - "title": "Remote Access | Managed Access Control Points", - "summary": "The information system routes all remote accesses through [Assignment: organization-defined number] managed network access control points." - }, - { - "ref": "AC-17 (4)", - "title": "Remote Access | Privileged Commands / Access", - "summary": "The organization:\n (a) Authorizes the execution of privileged commands and access to security-relevant information via remote access only for [Assignment: organization-defined needs]; and\n (b) Documents the rationale for such access in the security plan for the information system." - }, - { - "ref": "AC-17 (9)", - "title": "Remote Access | Disconnect / Disable Access", - "summary": "The organization provides the capability to expeditiously disconnect or disable remote access to the information system within **fifteen (15) minutes**." - }, - { - "ref": "AC-18", - "title": "Wireless Access", - "summary": "The organization:\n a. Establishes usage restrictions, configuration/connection requirements, and implementation guidance for wireless access; and\n b. Authorizes wireless access to the information system prior to allowing such connections." - }, - { - "ref": "AC-18 (1)", - "title": "Wireless Access | Authentication and Encryption", - "summary": "The information system protects wireless access to the system using authentication of [Selection\n(one or more): users; devices] and encryption." - }, - { - "ref": "AC-19", - "title": "Access Control for Mobile Devices", - "summary": "The organization:\n a. Establishes usage restrictions, configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices; and\n b. Authorizes the connection of mobile devices to organizational information systems." - }, - { - "ref": "AC-19 (5)", - "title": "Access Control for Mobile Devices | Full Device / Container-Based Encryption", - "summary": "The organization employs [Selection: full-device encryption; container encryption] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices]." - }, - { - "ref": "AC-20", - "title": "Use of External Information Systems", - "summary": "The organization establishes terms and conditions, consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems, allowing authorized individuals to:\n a. Access the information system from external information systems; and\n b. Process, store, or transmit organization-controlled information using external information systems." - }, - { - "ref": "AC-20 (1)", - "title": "Use of External Information Systems | Limits on Authorized Use", - "summary": "The organization permits authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization:\n (a) Verifies the implementation of required security controls on the external system as specified in the organization’s information security policy and security plan; or\n (b) Retains approved information system connection or processing agreements with the organizational entity hosting the external information system." - }, - { - "ref": "AC-20 (2)", - "title": "Use of External Information Systems | Portable Storage Devices", - "summary": "The organization [Selection: restricts; prohibits] the use of organization-controlled portable storage devices by authorized individuals on external information systems." - }, - { - "ref": "AC-21", - "title": "Information Sharing", - "summary": "The organization:\na. Facilitates information sharing by enabling authorized users to determine whether access authorizations assigned to the sharing partner match the access restrictions on the information for [Assignment: organization-defined information sharing circumstances where user discretion is required]; and\nb. Employs [Assignment: organization-defined automated mechanisms or manual processes] to assist users in making information sharing/collaboration decisions.\n \nSupplemental Guidance: This control applies to information that may be restricted in some manner (e.g., privileged medical information, contract-sensitive information, proprietary information, personally identifiable information, classified information related to special access programs or compartments) based on some formal or administrative determination. Depending on the particular information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment." - }, - { - "ref": "AC-22", - "title": "Publicly Accessible Content", - "summary": "The organization:\n a. Designates individuals authorized to post information onto a publicly accessible information system;\n b. Trains authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\n c. Reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that nonpublic information is not included; and\n d. Reviews the content on the publicly accessible information system for nonpublic information **at least quarterly** and removes such information, if discovered." - } - ] - }, - { - "title": "AWARENESS AND TRAINING", - "controls": [ - { - "ref": "AT-1", - "title": "Security Awareness and Training Policy Andprocedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security awareness and training policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security awareness and training policy and associated security awareness and training controls; and\n b. Reviews and updates the current:\n 1. Security awareness and training policy **at least every 3 years**; and\n 2. Security awareness and training procedures **at least annually**." - }, - { - "ref": "AT-2", - "title": "Security Awareness Training", - "summary": "The organization provides basic security awareness training to information system users (including managers, senior executives, and contractors):\n a. As part of initial training for new users;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "AT-2 (2)", - "title": "Security Awareness | Insider Threat", - "summary": "The organization includes security awareness training on recognizing and reporting potential indicators of insider threat." - }, - { - "ref": "AT-3", - "title": "Role-Based Security Training", - "summary": "The organization provides role-based security training to personnel with assigned security roles and responsibilities:\na. Before authorizing access to the information system or performing assigned duties;\nb. When required by information system changes; and\nc. **at least annually** thereafter." - }, - { - "ref": "AT-4", - "title": "Security Training Records", - "summary": "The organization:\n a. Documents and monitors individual information system security training activities including basic security awareness training and specific information system security training; and\n b. Retains individual training records for **At least one year**." - } - ] - }, - { - "title": "AUDIT AND ACCOUNTABILITY", - "controls": [ - { - "ref": "AU-1", - "title": "Audit and Accountability Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An audit and accountability policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls; and\n b. Reviews and updates the current:\n 1. Audit and accountability policy **at least every 3 years**; and\n 2. Audit and accountability procedures **at least annually**." - }, - { - "ref": "AU-2", - "title": "Audit Events", - "summary": "The organization:\n a. Determines that the information system is capable of auditing the following events: **successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes**;\n b. Coordinates the security audit function with other organizational entities requiring audit- related information to enhance mutual support and to help guide the selection of auditable events;\n c. Provides a rationale for why the auditable events are deemed to be adequate to support after- the-fact investigations of security incidents; and\n d. Determines that the following events are to be audited within the information system: **organization-defined subset of the auditable events defined in AU-2 a to be audited continually for each identified event**." - }, - { - "ref": "AU-2 (3)", - "title": "Audit Events | Reviews and Updates", - "summary": "The organization reviews and updates the audited events **annually or whenever there is a change in the threat environment**." - }, - { - "ref": "AU-3", - "title": "Content of Audit Records", - "summary": "The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event." - }, - { - "ref": "AU-3 (1)", - "title": "Content of Audit Records | Additional Audit Information", - "summary": "The information system generates audit records containing the following additional information: **session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon**." - }, - { - "ref": "AU-4", - "title": "Audit Storage Capacity", - "summary": "The organization allocates audit record storage capacity in accordance with [Assignment:\norganization-defined audit record storage requirements]." - }, - { - "ref": "AU-5", - "title": "Response To Audit Processing Failures", - "summary": "The information system:\n a. Alerts [Assignment: organization-defined personnel or roles] in the event of an audit processing failure; and\n b. Takes the following additional actions: [Assignment: organization-defined actions to be taken (e.g., shut down information system, overwrite oldest audit records, stop generating audit records)]." - }, - { - "ref": "AU-6", - "title": "Audit Review, Analysis, and Reporting", - "summary": "The organization:\n a. Reviews and analyzes information system audit records **at least weekly** for indications of [Assignment: organization-defined inappropriate or unusual activity]; and\n b. Reports findings to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "AU-6 (1)", - "title": "Audit Review, Analysis, and Reporting | Process Integration", - "summary": "The organization employs automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities." - }, - { - "ref": "AU-6 (3)", - "title": "Audit Review, Analysis, and Reporting | Correlate Audit Repositories", - "summary": "The organization analyzes and correlates audit records across different repositories to gain organization-wide situational awareness." - }, - { - "ref": "AU-7", - "title": "Audit Reduction and Report Generation", - "summary": "The information system provides an audit reduction and report generation capability that:\n a. Supports on-demand audit review, analysis, and reporting requirements and after-the-fact investigations of security incidents; and\n b. Does not alter the original content or time ordering of audit records." - }, - { - "ref": "AU-7 (1)", - "title": "Audit Reduction and Report Generation | Automatic Processing", - "summary": "The information system provides the capability to process audit records for events of interest based on [Assignment: organization-defined audit fields within audit records]." - }, - { - "ref": "AU-8", - "title": "Time Stamps", - "summary": "The information system:\n a. Uses internal system clocks to generate time stamps for audit records; and\n b. Records time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) and meets [Assignment: organization-defined granularity of time measurement]." - }, - { - "ref": "AU-8 (1)", - "title": "Time Stamps | Synchronization With Authoritative Time Source", - "summary": "The information system:\n (a) Compares the internal information system clocks **At least hourly** with [Assignment: organization-defined authoritative time source]; and\n (b) Synchronizes the internal system clocks to the authoritative time source when the time difference is greater than **At least hourly**." - }, - { - "ref": "AU-9", - "title": "Protection of Audit Information", - "summary": "The information system protects audit information and audit tools from unauthorized access, modification, and deletion." - }, - { - "ref": "AU-9 (2)", - "title": "Protection of Audit Information | Audit Backup on Separate Physical Systems / Components", - "summary": "The information system backs up audit records **at least weekly** onto a physically different system or system component than the system or component being audited." - }, - { - "ref": "AU-9 (4)", - "title": "Protection of Audit Information | Access By Subset of Privileged Users", - "summary": "The organization authorizes access to management of audit functionality to only [Assignment: organization-defined subset of privileged users]." - }, - { - "ref": "AU-11", - "title": "Audit Record Retention", - "summary": "The organization retains audit records for **at least ninety days** to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements." - }, - { - "ref": "AU-12", - "title": "Audit Generation", - "summary": "The information system:\n a. Provides audit record generation capability for the auditable events defined in AU-2 a. at **all information system and network components where audit capability is deployed/available**;\n b. Allows [Assignment: organization-defined personnel or roles] to select which auditable events are to be audited by specific components of the information system; and\n c. Generates audit records for the events defined in AU-2 d. with the content defined in AU-3." - } - ] - }, - { - "title": "SECURITY ASSESSMENT AND AUTHORIZATION", - "controls": [ - { - "ref": "CA-1", - "title": "Security Assessment and Authorization Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security assessment and authorization policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security assessment and authorization policy and associated security assessment and authorization controls; and\n b. Reviews and updates the current:\n 1. Security assessment and authorization policy **at least every 3 years**; and\n 2. Security assessment and authorization procedures **at least annually**." - }, - { - "ref": "CA-2", - "title": "Security Assessments", - "summary": "The organization:\n a. Develops a security assessment plan that describes the scope of the assessment including:\n 1. Security controls and control enhancements under assessment;\n 2. Assessment procedures to be used to determine security control effectiveness; and\n 3. Assessment environment, assessment team, and assessment roles and responsibilities;\n b. Assesses the security controls in the information system and its environment of operation **at least annually** to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements;\n c. Produces a security assessment report that documents the results of the assessment; and\n d. Provides the results of the security control assessment to **individuals or roles to include FedRAMP PMO**." - }, - { - "ref": "CA-2 (1)", - "title": "Security Assessments | Independent Assessors", - "summary": "The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to conduct security control assessments." - }, - { - "ref": "CA-2 (2)", - "title": "Security Assessments | Specialized Assessments", - "summary": "The organization includes as part of security control assessments, **at least annually**, [Selection: announced; unannounced], [Selection (one or more): in-depth monitoring; vulnerability scanning; malicious user testing; insider threat assessment; performance/load testing; [Assignment: organization-defined other forms of security assessment]]." - }, - { - "ref": "CA-2 (3)", - "title": "Security Assessments | External Organizations", - "summary": "The organization accepts the results of an assessment of **any FedRAMP Accredited 3PAO** performed by **any FedRAMP Accredited 3PAO** when the assessment meets **the conditions of the JAB/AO in the FedRAMP Repository**." - }, - { - "ref": "CA-3", - "title": "System Interconnections", - "summary": "The organization:\n a. Authorizes connections from the information system to other information systems through the use of Interconnection Security Agreements;\n b. Documents, for each interconnection, the interface characteristics, security requirements, and the nature of the information communicated; and\n c. Reviews and updates Interconnection Security Agreements **at least annually and on input from FedRAMP**." - }, - { - "ref": "CA-3 (3)", - "title": "System Interconnections | Unclassified Non-National Security System Connections", - "summary": "The organization prohibits the direct connection of an **Boundary Protections which meet the Trusted Internet Connection (TIC) requirements** to an external network without the use of [Assignment; organization-defined boundary protection device]." - }, - { - "ref": "CA-3 (5)", - "title": "System Interconnections | Restrictions on External System Connections", - "summary": "The organization employs [Selection: allow-all, deny-by-exception; deny-all, permit-by-exception] policy for allowing [Assignment: organization-defined information systems] to connect to external information systems." - }, - { - "ref": "CA-5", - "title": "Plan of Action and Milestones", - "summary": "The organization:\n a. Develops a plan of action and milestones for the information system to document the organization’s planned remedial actions to correct weaknesses or deficiencies noted during\nthe assessment of the security controls and to reduce or eliminate known vulnerabilities in the system; and\n b. Updates existing plan of action and milestones **at least monthly** based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities." - }, - { - "ref": "CA-6", - "title": "Security Authorization", - "summary": "The organization:\n a. Assigns a senior-level executive or manager as the authorizing official for the information system;\n b. Ensures that the authorizing official authorizes the information system for processing before commencing operations; and\n c. Updates the security authorization **at least every three (3) years or when a significant change occurs**." - }, - { - "ref": "CA-7", - "title": "Continuous Monitoring", - "summary": "The organization develops a continuous monitoring strategy and implements a continuous monitoring program that includes:\n a. Establishment of [Assignment: organization-defined metrics] to be monitored;\n b. Establishment of [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessments supporting such monitoring;\n c. Ongoing security control assessments in accordance with the organizational continuous monitoring strategy;\n d. Ongoing security status monitoring of organization-defined metrics in accordance with the organizational continuous monitoring strategy;\n e. Correlation and analysis of security-related information generated by assessments and monitoring;\n f. Response actions to address results of the analysis of security-related information; and\n g. Reporting the security status of organization and the information system to **to meet Federal and FedRAMP requirements** [Assignment: organization-defined frequency]." - }, - { - "ref": "CA-7 (1)", - "title": "Continuous Monitoring | Independent Assessment", - "summary": "The organization employs assessors or assessment teams with [Assignment: organization-defined level of independence] to monitor the security controls in the information system on an ongoing basis." - }, - { - "ref": "CA-8", - "title": "Penetration Testing", - "summary": "The organization conducts penetration testing **at least annually** on [Assignment: organization-defined information systems or system components]." - }, - { - "ref": "CA-8 (1)", - "title": "Penetration Testing | Independent Penetration Agent or Team", - "summary": "The organization employs an independent penetration agent or penetration team to perform penetration testing on the information system or system components." - }, - { - "ref": "CA-9", - "title": "Internal System Connections", - "summary": "The organization:\n a. Authorizes internal connections of [Assignment: organization-defined information system components or classes of components] to the information system; and\n b. Documents, for each internal connection, the interface characteristics, security requirements, and the nature of the information communicated." - } - ] - }, - { - "title": "CONFIGURATION MANAGEMENT", - "controls": [ - { - "ref": "CM-1", - "title": "Configuration Management Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A configuration management policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the configuration management policy and associated configuration management controls; and\n b. Reviews and updates the current:\n 1. Configuration management policy **at least every 3 years**; and\n 2. Configuration management procedures **at least annually**." - }, - { - "ref": "CM-2", - "title": "Baseline Configuration", - "summary": "The organization develops, documents, and maintains under configuration control, a current baseline configuration of the information system." - }, - { - "ref": "CM-2 (1)", - "title": "Baseline Configuration | Reviews and Updates", - "summary": "The organization reviews and updates the baseline configuration of the information system: \n (a) [Assignment: organization-defined frequency];\n (b) When required due to [Assignment organization-defined circumstances]; and\n (c) As an integral part of information system component installations and upgrades." - }, - { - "ref": "CM-2 (2)", - "title": "Baseline Configuration | Automation Support for Accuracy / Currency", - "summary": "The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system." - }, - { - "ref": "CM-2 (3)", - "title": "Baseline Configuration | Retention of Previous Configurations", - "summary": "The organization retains [Assignment: organization-defined previous versions of baseline configurations of the information system] to support rollback." - }, - { - "ref": "CM-2 (7)", - "title": "Baseline Configuration | Configure Systems, Components, or Devices for High-Risk Areas", - "summary": "The organization:\n (a) Issues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and\n (b) Applies [Assignment: organization-defined security safeguards] to the devices when the individuals return." - }, - { - "ref": "CM-3", - "title": "Configuration Change Control", - "summary": "The organization:\n a. Determines the types of changes to the information system that are configuration-controlled;\n b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses;\n c. Documents configuration change decisions associated with the information system;\n d. Implements approved configuration-controlled changes to the information system;\n e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\n f. Audits and reviews activities associated with configuration-controlled changes to the information system; and\n g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]]." - }, - { - "ref": "CM-4", - "title": "Security Impact Analysis", - "summary": "The organization analyzes changes to the information system to determine potential security impacts prior to change implementation." - }, - { - "ref": "CM-5", - "title": "Access Restrictions for Change", - "summary": "The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system." - }, - { - "ref": "CM-5 (1)", - "title": "Access Restrictions for Change | Automated Access Enforcement / Auditing", - "summary": "The information system enforces access restrictions and supports auditing of the enforcement actions." - }, - { - "ref": "CM-5 (3)", - "title": "Access Restrictions for Change | Signed Components", - "summary": "The information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization." - }, - { - "ref": "CM-5 (5)", - "title": "Access Restrictions for Change | Limit Production / Operational Privileges", - "summary": "The organization:\n (a) Limits privileges to change information system components and system-related information within a production or operational environment; and\n (b) Reviews and reevaluates privileges [Assignment: organization-defined frequency]." - }, - { - "ref": "CM-6", - "title": "Configuration Settings", - "summary": "The organization:\n a. Establishes and documents configuration settings for information technology products employed within the information system using **United States Government Configuration Baseline (USGCB)** that reflect the most restrictive mode consistent with operational requirements;\n b. Implements the configuration settings;\n c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and\n d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures." - }, - { - "ref": "CM-6 (1)", - "title": "Configuration Settings | Automated Central Management / Application / Verification", - "summary": "The organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components]." - }, - { - "ref": "CM-7", - "title": "Least Functionality", - "summary": "The organization:\n a. Configures the information system to provide only essential capabilities; and\n b. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: **United States Government Configuration Baseline (USGCB)**." - }, - { - "ref": "CM-7 (1)", - "title": "Least Functionality | Periodic Review", - "summary": "The organization:\n (a) Reviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or nonsecure functions, ports, protocols, and services; and\n (b) Disables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or nonsecure]." - }, - { - "ref": "CM-7 (2)", - "title": "Least Functionality | Prevent Program Execution", - "summary": "The information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage]." - }, - { - "ref": "CM-7 (5)", - "title": "Least Functionality | Authorized Software / Whitelisting", - "summary": "The organization:\n (a) Identifies [Assignment: organization-defined software programs authorized to execute on the information system];\n (b) Employs a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system; and\n (c) Reviews and updates the list of authorized software programs [Assignment: organization- defined frequency]." - }, - { - "ref": "CM-8", - "title": "Information System Component Inventory", - "summary": "The organization:\n a. Develops and documents an inventory of information system components that:\n 1. Accurately reflects the current information system;\n 2. Includes all components within the authorization boundary of the information system;\n 3. Is at the level of granularity deemed necessary for tracking and reporting; and\n 4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\n b. Reviews and updates the information system component inventory **at least monthly**." - }, - { - "ref": "CM-8 (1)", - "title": "Information System Component Inventory | Updates During Installations / Removals", - "summary": "The organization updates the inventory of information system components as an integral part of component installations, removals, and information system updates." - }, - { - "ref": "CM-8 (3)", - "title": "Information System Component Inventory | Automated Unauthorized Component Detection", - "summary": "The organization:\n (a) Employs automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\n (b) Takes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]]." - }, - { - "ref": "CM-8 (5)", - "title": "Information System Component Inventory | No Duplicate Accounting of Components", - "summary": "The organization verifies that all components within the authorization boundary of the information system are not duplicated in other information system inventories." - }, - { - "ref": "CM-9", - "title": "Configuration Management Plan", - "summary": "The organization develops, documents, and implements a configuration management plan for the information system that:\n a. Addresses roles, responsibilities, and configuration management processes and procedures;\n b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;\n c. Defines the configuration items for the information system and places the configuration items under configuration management; and\n d. Protects the configuration management plan from unauthorized disclosure and modification." - }, - { - "ref": "CM-10", - "title": "Software Usage Restrictions", - "summary": "The organization:\na. Uses software and associated documentation in accordance with contract agreements and copyright laws;\nb. Tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Controls and documents the use of 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." - }, - { - "ref": "CM-10 (1)", - "title": "Software Usage Restrictions | Open Source Software", - "summary": "The organization establishes the following restrictions on the use of open source software: [Assignment: organization-defined restrictions]." - }, - { - "ref": "CM-11", - "title": "User-Installed Software", - "summary": "The organization:\n a. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\n b. Enforces software installation policies through [Assignment: organization-defined methods]; and\n c. Monitors policy compliance at **Continuously (via CM-7 (5))**." - } - ] - }, - { - "title": "CONTINGENCY PLANNING", - "controls": [ - { - "ref": "CP-1", - "title": "Contingency Planning Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A contingency planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls; and\n b. Reviews and updates the current:\n 1. Contingency planning policy **at least every 3 years**; and\n 2. Contingency planning procedures **at least annually**." - }, - { - "ref": "CP-2", - "title": "Contingency Plan", - "summary": "The organization:\n a. Develops a contingency plan for the information system that:\n 1. Identifies essential missions and business functions and associated contingency requirements;\n 2. Provides recovery objectives, restoration priorities, and metrics;\n 3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n 4. Addresses maintaining essential missions and business functions despite an information system disruption, compromise, or failure;\n 5. Addresses eventual, full information system restoration without deterioration of the security safeguards originally planned and implemented; and\n 6. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the contingency plan to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements];\n c. Coordinates contingency planning activities with incident handling activities;\n d. Reviews the contingency plan for the information system **at least annually**;\n e. Updates the contingency plan to address changes to the organization, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\n f. Communicates contingency plan changes to [Assignment: organization-defined key contingency personnel (identified by name and/or by role) and organizational elements]; and\n g. Protects the contingency plan from unauthorized disclosure and modification." - }, - { - "ref": "CP-2 (1)", - "title": "Contingency Plan | Coordinate With Related Plans", - "summary": "The organization coordinates contingency plan development with organizational elements responsible for related plans." - }, - { - "ref": "CP-2 (2)", - "title": "Contingency Plan | Capacity Planning", - "summary": "The organization conducts capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during contingency operations." - }, - { - "ref": "CP-2 (3)", - "title": "Contingency Plan | Resume Essential Missions / Business Functions", - "summary": "The organization plans for the resumption of essential missions and business functions within\n[Assignment: organization-defined time period] of contingency plan activation." - }, - { - "ref": "CP-2 (8)", - "title": "Contingency Plan | Identify Critical Assets", - "summary": "The organization identifies critical information system assets supporting essential missions and business functions." - }, - { - "ref": "CP-3", - "title": "Contingency Training", - "summary": "The organization provides contingency training to information system users consistent with assigned roles and responsibilities:\n a. Within **ten (10) days** of assuming a contingency role or responsibility;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "CP-4", - "title": "Contingency Plan Testing", - "summary": "The organization:\n a. Tests the contingency plan for the information system **at least annually for moderate impact systems; at least every three years for low impact systems** using **functional exercises for moderate impact systems; classroom exercises/table top written tests for low impact systems** to determine the effectiveness of the plan and the organizational readiness to execute the plan;\n b. Reviews the contingency plan test results; and\n c. Initiates corrective actions, if needed." - }, - { - "ref": "CP-4 (1)", - "title": "Contingency Plan Testing | Coordinate With Related Plans", - "summary": "The organization coordinates contingency plan testing with organizational elements responsible for related plans." - }, - { - "ref": "CP-6", - "title": "Alternate Storage Site", - "summary": "The organization:\n a. Establishes an alternate storage site including necessary agreements to permit the storage and retrieval of information system backup information; and\n b. Ensures that the alternate storage site provides information security safeguards equivalent to that of the primary site." - }, - { - "ref": "CP-6 (1)", - "title": "Alternate Storage Site | Separation From Primary Site", - "summary": "The organization identifies an alternate storage site that is separated from the primary storage site to reduce susceptibility to the same threats." - }, - { - "ref": "CP-6 (3)", - "title": "Alternate Storage Site | Accessibility", - "summary": "The organization identifies potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions." - }, - { - "ref": "CP-7", - "title": "Alternate Processing Site", - "summary": "The organization:\n a. Establishes an alternate processing site including necessary agreements to permit the transfer and resumption of [Assignment: organization-defined information system operations] for essential missions/business functions within [Assignment: organization-defined time period consistent with recovery time and recovery point objectives] when the primary processing capabilities are unavailable;\n b. Ensures that equipment and supplies required to transfer and resume operations are available at the alternate processing site or contracts are in place to support delivery to the site within the organization-defined time period for transfer/resumption; and \n c. Ensures that the alternate processing site provides information security safeguards equivalent to that of the primary site." - }, - { - "ref": "CP-7 (1)", - "title": "Alternate Processing Site | Separation From Primary Site", - "summary": "The organization identifies an alternate processing site that is separated from the primary processing site to reduce susceptibility to the same threats." - }, - { - "ref": "CP-7 (2)", - "title": "Alternate Processing Site | Accessibility", - "summary": "The organization identifies potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions." - }, - { - "ref": "CP-7 (3)", - "title": "Alternate Processing Site | Priority of Service", - "summary": "The organization develops alternate processing site agreements that contain priority-of-service provisions in accordance with organizational availability requirements (including recovery time objectives)." - }, - { - "ref": "CP-8", - "title": "Telecommunications Services", - "summary": "The organization establishes alternate telecommunications services including necessary agreements to permit the resumption of [Assignment: organization-defined information system operations] for essential missions and business functions within [Assignment: organization- defined time period] when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites." - }, - { - "ref": "CP-8 (1)", - "title": "Telecommunications Services | Priority of Service Provisions", - "summary": "The organization:\n (a) Develops primary and alternate telecommunications service agreements that contain priority- of-service provisions in accordance with organizational availability requirements (including recovery time objectives); and\n (b) Requests Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness in the event that the primary and/or alternate telecommunications services are provided by a common carrier." - }, - { - "ref": "CP-8 (2)", - "title": "Telecommunications Services | Single Points of Failure", - "summary": "The organization obtains alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services." - }, - { - "ref": "CP-9", - "title": "Information System Backup", - "summary": "The organization:\na. Conducts backups of user-level information contained in the information system **daily incremental; weekly full**;\nb. Conducts backups of system-level information contained in the information system **daily incremental; weekly full**;\nc. Conducts backups of information system documentation including security-related documentation **daily incremental; weekly full**; and\nd. Protects the confidentiality, integrity, and availability of backup information at storage locations." - }, - { - "ref": "CP-9 (1)", - "title": "Information System Backup | Testing for Reliability / Integrity", - "summary": "The organization tests backup information **at least annually** to verify media reliability and information integrity." - }, - { - "ref": "CP-9 (3)", - "title": "Information System Backup | Separate Storage for Critical Information", - "summary": "The organization stores backup copies of [Assignment: organization-defined critical information system software and other security-related information] in a separate facility or in a fire-rated container that is not collocated with the operational system." - }, - { - "ref": "CP-10", - "title": "Information System Recovery and Reconstitution", - "summary": "The organization provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure." - }, - { - "ref": "CP-10 (2)", - "title": "Information System Recovery and Reconstitution | Transaction Recovery", - "summary": "The information system implements transaction recovery for systems that are transaction-based." - } - ] - }, - { - "title": "IDENTIFICATION AND AUTHENTICATION", - "controls": [ - { - "ref": "IA-1", - "title": "Identification and Authentication Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An identification and authentication policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the identification and authentication policy and associated identification and authentication controls; and\n b. Reviews and updates the current:\n 1. Identification and authentication policy **at least every 3 years**; and\n 2. Identification and authentication procedures **at least annually**." - }, - { - "ref": "IA-2", - "title": "Identification and Authentication (Organizational Users)", - "summary": "The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users)." - }, - { - "ref": "IA-2 (1)", - "title": "Identification and Authentication | Network Access To Privileged Accounts", - "summary": "The information system implements multifactor authentication for network access to privileged accounts." - }, - { - "ref": "IA-2 (2)", - "title": "Identification and Authentication | Network Access To Non-Privileged Accounts", - "summary": "The information system implements multifactor authentication for network access to non- privileged accounts." - }, - { - "ref": "IA-2 (3)", - "title": "Identification and Authentication | Local Access To Privileged Accounts", - "summary": "The information system implements multifactor authentication for local access to privileged accounts." - }, - { - "ref": "IA-2 (5)", - "title": "Identification and Authentication (Organizational Users) | Group Authentication", - "summary": "The organization requires individuals to be authenticated with an individual authenticator when a group authenticator is employed." - }, - { - "ref": "IA-2 (8)", - "title": "Identification and Authentication | Network Access To Privileged Accounts - Replay Resistant", - "summary": "The information system implements replay-resistant authentication mechanisms for network access to privileged accounts." - }, - { - "ref": "IA-2 (11)", - "title": "Identification and Authentication | Remote Access - Separate Device", - "summary": "The information system implements multifactor authentication for remote access to privileged and non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets **FIPS 140-2, NIAP Certification, or NSA approval**." - }, - { - "ref": "IA-2 (12)", - "title": "Identification and Authentication | Acceptance of Piv Credentials", - "summary": "The information system accepts and electronically verifies Personal Identity Verification (PIV)\ncredentials." - }, - { - "ref": "IA-3", - "title": "Device Identification and Authentication", - "summary": "The information system uniquely identifies and authenticates [Assignment: organization- defined specific and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection." - }, - { - "ref": "IA-4", - "title": "Identifier Management", - "summary": "The organization manages information system identifiers by:\n a. Receiving authorization from [Assignment: organization-defined personnel or roles] to assign an individual, group, role, or device identifier;\n b. Selecting an identifier that identifies an individual, group, role, or device;\n c. Assigning the identifier to the intended individual, group, role, or device;\n d. Preventing reuse of identifiers for **at least two years**; and\n e. Disabling the identifier after **ninety days for user identifiers**." - }, - { - "ref": "IA-4 (4)", - "title": "Identifier Management | Identify User Status", - "summary": "The organization manages individual identifiers by uniquely identifying each individual as\n**contractors; foreign nationals**." - }, - { - "ref": "IA-5", - "title": "Authenticator Management", - "summary": "The organization manages information system authenticators by:\n a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator;\n b. Establishing initial authenticator content for authenticators defined by the organization;\n c. Ensuring that authenticators have sufficient strength of mechanism for their intended use;\n d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators;\n e. Changing default content of authenticators prior to information system installation;\n f. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators;\n g. Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type];\n h. Protecting authenticator content from unauthorized disclosure and modification;\n i. Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and\n j. Changing authenticators for group/role accounts when membership to those accounts changes." - }, - { - "ref": "IA-5 (1)", - "title": "Authenticator Management | Password-Based Authentication", - "summary": "The information system, for password-based authentication:\n (a) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type];\n (b) Enforces at least the following number of changed characters when new passwords are created: [Assignment: organization-defined number];\n (c) Stores and transmits only encrypted representations of passwords;\n (d) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization- defined numbers for lifetime minimum, lifetime maximum];\n (e) Prohibits password reuse for [Assignment: organization-defined number] generations; and\n (f) Allows the use of a temporary password for system logons with an immediate change to a permanent password." - }, - { - "ref": "IA-5 (2)", - "title": "Authenticator Management | Pki-Based Authentication", - "summary": "The information system, for PKI-based authentication:\n (a) Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information;\n (b) Enforces authorized access to the corresponding private key;\n (c) Maps the authenticated identity to the account of the individual or group; and\n (d) Implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network." - }, - { - "ref": "IA-5 (3)", - "title": "Authenticator Management | In-Person or Trusted Third-Party Registration", - "summary": "The organization requires that the registration process to receive **All hardware/biometric (multifactor authenticators** be conducted [Selection: in person; by a trusted third party] before **in person** with authorization by [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "IA-5 (4)", - "title": "Authenticator Management | Automated Support for Password Strength Determination", - "summary": "The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy [Assignment: organization-defined requirements]." - }, - { - "ref": "IA-5 (6)", - "title": "Authenticator Management | Protection of Authenticators", - "summary": "The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access." - }, - { - "ref": "IA-5 (7)", - "title": "Authenticator Management | No Embedded Unencrypted Static Authenticators", - "summary": "The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys." - }, - { - "ref": "IA-5 (11)", - "title": "Authenticator Management | Hardware Token-Based Authentication", - "summary": "The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]." - }, - { - "ref": "IA-6", - "title": "Authenticator Feedback", - "summary": "The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals." - }, - { - "ref": "IA-7", - "title": "Cryptographic Module Authentication", - "summary": "The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication." - }, - { - "ref": "IA-8", - "title": "Identification and Authentication (Non- Organizational Users)", - "summary": "The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users)." - }, - { - "ref": "IA-8 (1)", - "title": "Identification and Authentication | Acceptance of Piv Credentials From Other Agencies", - "summary": "The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies." - }, - { - "ref": "IA-8 (2)", - "title": "Identification and Authentication | Acceptance of Third-Party Credentials", - "summary": "The information system accepts only FICAM-approved third-party credentials." - }, - { - "ref": "IA-8 (3)", - "title": "Identification and Authentication | Use of Ficam-Approved Products", - "summary": "The organization employs only FICAM-approved information system components in [Assignment:\norganization-defined information systems] to accept third-party credentials." - }, - { - "ref": "IA-8 (4)", - "title": "Identification and Authentication | Use of Ficam-Issued Profiles", - "summary": "The information system conforms to FICAM-issued profiles." - } - ] - }, - { - "title": "INCIDENT RESPONSE", - "controls": [ - { - "ref": "IR-1", - "title": "Incident Response Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. An incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the incident response policy and associated incident response controls; and\n b. Reviews and updates the current:\n 1. Incident response policy **at least every 3 years**; and\n 2. Incident response procedures **at least annually**." - }, - { - "ref": "IR-2", - "title": "Incident Response Training", - "summary": "The organization provides incident response training to information system users consistent with assigned roles and responsibilities:\n a. Within [Assignment: organization-defined time period] of assuming an incident response role or responsibility;\n b. When required by information system changes; and\n c. **at least annually** thereafter." - }, - { - "ref": "IR-3", - "title": "Incident Response Testing", - "summary": "The organization tests the incident response capability for the information system **at least annually** using **see additional FedRAMP Requirements and Guidance** to determine the incident response effectiveness and documents the results." - }, - { - "ref": "IR-3 (2)", - "title": "Incident Response Testing | Coordination With Related Plans", - "summary": "The organization coordinates incident response testing with organizational elements responsible for related plans." - }, - { - "ref": "IR-4", - "title": "Incident Handling", - "summary": "The organization:\na. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;\nb. Coordinates incident handling activities with contingency planning activities; and\nc. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly." - }, - { - "ref": "IR-4 (1)", - "title": "Incident Handling | Automated Incident Handling Processes", - "summary": "The organization employs automated mechanisms to support the incident handling process." - }, - { - "ref": "IR-5", - "title": "Incident Monitoring", - "summary": "The organization tracks and documents information system security incidents." - }, - { - "ref": "IR-6", - "title": "Incident Reporting", - "summary": "The organization:\n a. Requires personnel to report suspected security incidents to the organizational incident response capability within **US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended)**; and\n b. Reports security incident information to [Assignment: organization-defined authorities]." - }, - { - "ref": "IR-6 (1)", - "title": "Incident Reporting | Automated Reporting", - "summary": "The organization employs automated mechanisms to assist in the reporting of security incidents." - }, - { - "ref": "IR-7", - "title": "Incident Response Assistance", - "summary": "The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents." - }, - { - "ref": "IR-7 (1)", - "title": "Incident Response Assistance | Automation Support for Availability of Information / Support", - "summary": "The organization employs automated mechanisms to increase the availability of incident response- related information and support." - }, - { - "ref": "IR-7 (2)", - "title": "Incident Response Assistance | Coordination With External Providers", - "summary": "The organization:\n (a) Establishes a direct, cooperative relationship between its incident response capability and external providers of information system protection capability; and\n (b) Identifies organizational incident response team members to the external providers." - }, - { - "ref": "IR-8", - "title": "Incident Response Plan", - "summary": "The organization:\n a. Develops an incident response plan that:\n 1. Provides the organization with a roadmap for implementing its incident response capability;\n 2. Describes the structure and organization of the incident response capability;\n 3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n 4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n 5. Defines reportable incidents;\n 6. Provides metrics for measuring the incident response capability within the organization;\n 7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and\n 8. Is reviewed and approved by [Assignment: organization-defined personnel or roles];\n b. Distributes copies of the incident response plan to **see additional FedRAMP Requirements and Guidance**;\n c. Reviews the incident response plan **at least annually**;\n d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;\n e. Communicates incident response plan changes to **see additional FedRAMP Requirements and Guidance**; and\nf. Protects the incident response plan from unauthorized disclosure and modification." - }, - { - "ref": "IR-9", - "title": "Information Spillage Response", - "summary": "The organization responds to information spills by:\n a. Identifying the specific information involved in the information system contamination;\n b. Alerting [Assignment: organization-defined personnel or roles] of the information spill using a method of communication not associated with the spill;\n c. Isolating the contaminated information system or system component;\n d. Eradicating the information from the contaminated information system or component;\n e. Identifying other information systems or system components that may have been subsequently contaminated; and\n f. Performing other [Assignment: organization-defined actions]." - }, - { - "ref": "IR-9 (1)", - "title": "Information Spillage Response | Responsible Personnel", - "summary": "The organization assigns [Assignment: organization-defined personnel or roles] with responsibility for responding to information spills." - }, - { - "ref": "IR-9 (2)", - "title": "Information Spillage Response | Training", - "summary": "The organization provides information spillage response training [Assignment: organization- defined frequency]." - }, - { - "ref": "IR-9 (3)", - "title": "Information Spillage Response | Post-Spill Operations", - "summary": "The organization implements [Assignment: organization-defined procedures] to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions." - }, - { - "ref": "IR-9 (4)", - "title": "Information Spillage Response | Exposure To Unauthorized Personnel", - "summary": "The organization employs [Assignment: organization-defined security safeguards] for personnel exposed to information not within assigned access authorizations." - } - ] - }, - { - "title": "MAINTENANCE", - "controls": [ - { - "ref": "MA-1", - "title": "System Maintenance Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system maintenance policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system maintenance policy and associated system maintenance controls; and\n b. Reviews and updates the current:\n 1. System maintenance policy **at least every 3 years**; and\n 2. System maintenance procedures **at least annually**." - }, - { - "ref": "MA-2", - "title": "Controlled Maintenance", - "summary": "The organization:\n a. Schedules, performs, documents, and reviews records of maintenance and repairs on information system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\n b. Approves and monitors all maintenance activities, whether performed on site or remotely and whether the equipment is serviced on site or removed to another location;\n c. Requires that [Assignment: organization-defined personnel or roles] explicitly approve the removal of the information system or system components from organizational facilities for off-site maintenance or repairs;\n d. Sanitizes equipment to remove all information from associated media prior to removal from organizational facilities for off-site maintenance or repairs;\n e. Checks all potentially impacted security controls to verify that the controls are still functioning properly following maintenance or repair actions; and\n f. Includes [Assignment: organization-defined maintenance-related information] in organizational maintenance records." - }, - { - "ref": "MA-3", - "title": "Maintenance Tools", - "summary": "The organization approves, controls, and monitors information system maintenance tools." - }, - { - "ref": "MA-3 (1)", - "title": "Maintenance Tools | Inspect Tools", - "summary": "The organization inspects the maintenance tools carried into a facility by maintenance personnel for improper or unauthorized modifications." - }, - { - "ref": "MA-3 (2)", - "title": "Maintenance Tools | Inspect Media", - "summary": "The organization checks media containing diagnostic and test programs for malicious code before the media are used in the information system." - }, - { - "ref": "MA-3 (3)", - "title": "Maintenance Tools | Prevent Unauthorized Removal", - "summary": "The organization prevents the unauthorized removal of maintenance equipment containing organizational information by:\n (a) Verifying that there is no organizational information contained on the equipment; \n (b) Sanitizing or destroying the equipment;\n (c) Retaining the equipment within the facility; or\n (d) Obtaining an exemption from [Assignment: organization-defined personnel or roles] explicitly authorizing removal of the equipment from the facility." - }, - { - "ref": "MA-4", - "title": "Nonlocal Maintenance", - "summary": "The organization:\n a. Approves and monitors nonlocal maintenance and diagnostic activities;\n b. Allows the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system;\n c. Employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions;\n d. Maintains records for nonlocal maintenance and diagnostic activities; and\n e. Terminates session and network connections when nonlocal maintenance is completed." - }, - { - "ref": "MA-4 (2)", - "title": "Nonlocal Maintenance | Document Nonlocal Maintenance", - "summary": "The organization documents in the security plan for the information system, the policies and procedures for the establishment and use of nonlocal maintenance and diagnostic connections." - }, - { - "ref": "MA-5", - "title": "Maintenance Personnel", - "summary": "The organization:\n a. Establishes a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel;\n b. Ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and\n c. Designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations." - }, - { - "ref": "MA-5 (1)", - "title": "Maintenance Personnel | Individuals Without Appropriate Access", - "summary": "The organization:\n (a) Implements procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements:\n (1) Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the information system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified;\n (2) Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the information system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and\n (b) Develops and implements alternate security safeguards in the event an information system component cannot be sanitized, removed, or disconnected from the system." - }, - { - "ref": "MA-6", - "title": "Timely Maintenance", - "summary": "The organization obtains maintenance support and/or spare parts for [Assignment: organization-defined information system components] within [Assignment: organization-defined time period] of failure." - } - ] - }, - { - "title": "MEDIA PROTECTION", - "controls": [ - { - "ref": "MP-1", - "title": "Media Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A media protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the media protection policy and associated media protection controls; and\n b. Reviews and updates the current:\n 1. Media protection policy **at least every 3 years**; and\n 2. Media protection procedures **at least annually**." - }, - { - "ref": "MP-2", - "title": "Media Access", - "summary": "The organization restricts access to [Assignment: organization-defined types of digital and/or non-digital media] to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "MP-3", - "title": "Media Marking", - "summary": "The organization:\n a. Marks information system media indicating the distribution limitations, handling caveats, and applicable security markings (if any) of the information; and\n b. Exempts **no removable media types** from marking as long as the media remain within [Assignment: organization-defined controlled areas]." - }, - { - "ref": "MP-4", - "title": "Media Storage", - "summary": "The organization:\n a. Physically controls and securely stores **all types of digital and non-digital media with sensitive information** within **see additional FedRAMP requirements and guidance**; and\n b. Protects information system media until the media are destroyed or sanitized using approved equipment, techniques, and procedures." - }, - { - "ref": "MP-5", - "title": "Media Transport", - "summary": "The organization:\n a. Protects and controls [Assignment: organization-defined types of information system media] during transport outside of controlled areas using [Assignment: organization-defined security safeguards];\n b. Maintains accountability for information system media during transport outside of controlled areas;\n c. Documents activities associated with the transport of information system media; and\n d. Restricts the activities associated with the transport of information system media to authorized personnel." - }, - { - "ref": "MP-5 (4)", - "title": "Media Transport | Cryptographic Protection", - "summary": "The information system implements cryptographic mechanisms to protect the confidentiality and integrity of information stored on digital media during transport outside of controlled areas." - }, - { - "ref": "MP-6", - "title": "Media Sanitization", - "summary": "The organization:\n a. Sanitizes [Assignment: organization-defined information system media] prior to disposal, release out of organizational control, or release for reuse using [Assignment: organization- defined sanitization techniques and procedures] in accordance with applicable federal and organizational standards and policies; and\n b. Employs sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information." - }, - { - "ref": "MP-6 (2)", - "title": "Media Sanitization | Equipment Testing", - "summary": "The organization tests sanitization equipment and procedures **At least annually** to verify that the intended sanitization is being achieved." - }, - { - "ref": "MP-7", - "title": "Media Use", - "summary": "The organization [Selection: restricts; prohibits] the use of [Assignment: organization- defined types of information system media] on [Assignment: organization-defined information systems or system components] using [Assignment: organization-defined security safeguards]." - }, - { - "ref": "MP-7 (1)", - "title": "Media Use | Prohibit Use Without Owner", - "summary": "The organization prohibits the use of portable storage devices in organizational information systems when such devices have no identifiable owner." - } - ] - }, - { - "title": "PHYSICAL AND ENVIRONMENTAL PROTECTION", - "controls": [ - { - "ref": "PE-1", - "title": "Physical and Environmental Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A physical and environmental protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the physical and environmental protection policy and associated physical and environmental protection controls; and\n b. Reviews and updates the current:\n 1. Physical and environmental protection policy **at least every 3 years**; and\n 2. Physical and environmental protection procedures **at least annually**." - }, - { - "ref": "PE-2", - "title": "Physical Access Authorizations", - "summary": "The organization:\n a. Develops, approves, and maintains a list of individuals with authorized access to the facility where the information system resides;\n b. Issues authorization credentials for facility access;\n c. Reviews the access list detailing authorized facility access by individuals **at least annually**; and\n d. Removes individuals from the facility access list when access is no longer required." - }, - { - "ref": "PE-3", - "title": "Physical Access Control", - "summary": "The organization:\n a. Enforces physical access authorizations at [Assignment: organization-defined entry/exit points to the facility where the information system resides] by;\n 1. Verifying individual access authorizations before granting access to the facility; and\n 2. Controlling ingress/egress to the facility using [Selection (one or more): **CSP defined physical access control systems/devices AND guards**; guards];\n b. Maintains physical access audit logs for [Assignment: organization-defined entry/exit points];\n c. Provides [Assignment: organization-defined security safeguards] to control access to areas within the facility officially designated as publicly accessible;\n d. Escorts visitors and monitors visitor activity **in all circumstances within restricted access area where the information system resides**;\n e. Secures keys, combinations, and other physical access devices;\n f. Inventories **at least annually** every [Assignment: organization-defined frequency]; and\n g. Changes combinations and keys **at least annually** and/or when keys are lost, combinations are compromised, or individuals are transferred or terminated." - }, - { - "ref": "PE-4", - "title": "Access Control for Transmission Medium", - "summary": "The organization controls physical access to [Assignment: organization-defined information system distribution and transmission lines] within organizational facilities using [Assignment: organization-defined security safeguards]." - }, - { - "ref": "PE-5", - "title": "Access Control for Output Devices", - "summary": "The organization controls physical access to information system output devices to prevent unauthorized individuals from obtaining the output." - }, - { - "ref": "PE-6", - "title": "Monitoring Physical Access", - "summary": "The organization:\n a. Monitors physical access to the facility where the information system resides to detect and respond to physical security incidents;\n b. Reviews physical access logs **at least monthly** and upon occurrence of [Assignment: organization-defined events or potential indications of events]; and\n c. Coordinates results of reviews and investigations with the organizational incident response capability." - }, - { - "ref": "PE-6 (1)", - "title": "Monitoring Physical Access | Intrusion Alarms / Surveillance Equipment", - "summary": "The organization monitors physical intrusion alarms and surveillance equipment." - }, - { - "ref": "PE-8", - "title": "Visitor Access Records", - "summary": "The organization:\n a. Maintains visitor access records to the facility where the information system resides for **for a minimum of one (1) year**; and\n b. Reviews visitor access records **at least monthly**." - }, - { - "ref": "PE-9", - "title": "Power Equipment and Cabling", - "summary": "The organization protects power equipment and power cabling for the information system from damage and destruction." - }, - { - "ref": "PE-10", - "title": "Emergency Shutoff", - "summary": "The organization:\n a. Provides the capability of shutting off power to the information system or individual system components in emergency situations;\n b. Places emergency shutoff switches or devices in [Assignment: organization-defined location by information system or system component] to facilitate safe and easy access for personnel; and\n c. Protects emergency power shutoff capability from unauthorized activation." - }, - { - "ref": "PE-11", - "title": "Emergency Power", - "summary": "The organization provides a short-term uninterruptible power supply to facilitate [Selection (one or more): an orderly shutdown of the information system; transition of the information system to long-term alternate power] in the event of a primary power source loss." - }, - { - "ref": "PE-12", - "title": "Emergency Lighting", - "summary": "The organization employs and maintains automatic emergency lighting for the information system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility." - }, - { - "ref": "PE-13", - "title": "Fire Protection", - "summary": "The organization employs and maintains fire suppression and detection devices/systems for the information system that are supported by an independent energy source." - }, - { - "ref": "PE-13 (2)", - "title": "Fire Protection | Suppression Devices / Systems", - "summary": "The organization employs fire suppression devices/systems for the information system that provide automatic notification of any activation to Assignment: organization-defined personnel or roles] and [Assignment: organization-defined emergency responders]." - }, - { - "ref": "PE-13 (3)", - "title": "Fire Protection | Automatic Fire Suppression", - "summary": "The organization employs an automatic fire suppression capability for the information system when the facility is not staffed on a continuous basis." - }, - { - "ref": "PE-14", - "title": "Temperature and Humidity Controls", - "summary": "The organization:\n a. Maintains temperature and humidity levels within the facility where the information system resides at **consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments**; and\n b. Monitors temperature and humidity levels **continuously**." - }, - { - "ref": "PE-14 (2)", - "title": "Temperature and Humidity Controls | Monitoring With Alarms / Notifications", - "summary": "The organization employs temperature and humidity monitoring that provides an alarm or notification of changes potentially harmful to personnel or equipment." - }, - { - "ref": "PE-15", - "title": "Water Damage Protection", - "summary": "The organization protects the information system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel." - }, - { - "ref": "PE-16", - "title": "Delivery and Removal", - "summary": "The organization authorizes, monitors, and controls **all information system components** entering and exiting the facility and maintains records of those items." - }, - { - "ref": "PE-17", - "title": "Alternate Work Site", - "summary": "The organization:\n a. Employs [Assignment: organization-defined security controls] at alternate work sites;\n b. Assesses as feasible, the effectiveness of security controls at alternate work sites; and\n c. Provides a means for employees to communicate with information security personnel in case of security incidents or problems." - } - ] - }, - { - "title": "PLANNING", - "controls": [ - { - "ref": "PL-1", - "title": "Security Planning Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and\n b. Reviews and updates the current:\n 1. Security planning policy **at least every 3 years**; and\n 2. Security planning procedures **at least annually**." - }, - { - "ref": "PL-2", - "title": "System Security Plan", - "summary": "The organization:\n a. Develops a security plan for the information system that:\n 1. Is consistent with the organization’s enterprise architecture;\n 2. Explicitly defines the authorization boundary for the system;\n 3. Describes the operational context of the information system in terms of missions and business processes;\n 4. Provides the security categorization of the information system including supporting rationale;\n 5. Describes the operational environment for the information system and relationships with or connections to other information systems;\n 6. Provides an overview of the security requirements for the system;\n 7. Identifies any relevant overlays, if applicable;\n 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and\n 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation;\n b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles];\n c. Reviews the security plan for the information system **at least annually**;\n d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and\n e. Protects the security plan from unauthorized disclosure and modification." - }, - { - "ref": "PL-2 (3)", - "title": "System Security Plan | Plan / Coordinate With Other Organizational Entities", - "summary": "The organization plans and coordinates security-related activities affecting the information system with [Assignment: organization-defined individuals or groups] before conducting such activities in order to reduce the impact on other organizational entities." - }, - { - "ref": "PL-4", - "title": "Rules of Behavior", - "summary": "The organization:\n a. Establishes and makes readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage;\n b. Receives a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system;\n c. Reviews and updates the rules of behavior **At least every 3 years**; and d. Requires individuals who have signed a previous version of the rules of behavior to read and\nresign when the rules of behavior are revised/updated." - }, - { - "ref": "PL-4 (1)", - "title": "Rules of Behavior | Social Media and Networking Restrictions", - "summary": "The organization includes in the rules of behavior, explicit restrictions on the use of social media/networking sites and posting organizational information on public websites." - }, - { - "ref": "PL-8", - "title": "Information Security Architecture", - "summary": "The organization:\n a. Develops an information security architecture for the information system that:\n 1. Describes the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information;\n 2. Describes how the information security architecture is integrated into and supports the enterprise architecture; and\n 3. Describes any information security assumptions about, and dependencies on, external services;\n b. Reviews and updates the information security architecture **at least annually or when a significant change occurs** to reflect updates in the enterprise architecture; and\n c. Ensures that planned information security architecture changes are reflected in the security plan, the security Concept of Operations (CONOPS), and organizational procurements/acquisitions." - } - ] - }, - { - "title": "PERSONNEL SECURITY", - "controls": [ - { - "ref": "PS-1", - "title": "Personnel Security Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A personnel security policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the personnel security policy and associated personnel security controls; and\n b. Reviews and updates the current:\n 1. Personnel security policy **at least every 3 years**; and\n 2. Personnel security procedures **at least annually**." - }, - { - "ref": "PS-2", - "title": "Position Risk Designation", - "summary": "The organization:\n a. Assigns a risk designation to all organizational positions;\n b. Establishes screening criteria for individuals filling those positions; and\n c. Reviews and updates position risk designations **at least every three years**." - }, - { - "ref": "PS-3", - "title": "Personnel Screening", - "summary": "The organization:\n a. Screens individuals prior to authorizing access to the information system; and\n b. Rescreens individuals according to [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of such rescreening]." - }, - { - "ref": "PS-3 (3)", - "title": "Personnel Screening | Information With Special Protection Measures", - "summary": "The organization ensures that individuals accessing an information system processing, storing, or transmitting information requiring special protection:\n (a) Have valid access authorizations that are demonstrated by assigned official government duties; and\n (b) Satisfy [Assignment: organization-defined additional personnel screening criteria]." - }, - { - "ref": "PS-4", - "title": "Personnel Termination", - "summary": "The organization, upon termination of individual employment:\n a. Disables information system access within **same day**;\n b. Terminates/revokes any authenticators/credentials associated with the individual;\n c. Conducts exit interviews that include a discussion of [Assignment: organization-defined information security topics];\n d. Retrieves all security-related organizational information system-related property;\n e. Retains access to organizational information and information systems formerly controlled by terminated individual; and\n f. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period]." - }, - { - "ref": "PS-5", - "title": "Personnel Transfer", - "summary": "The organization:\n a. Reviews and confirms ongoing operational need for current logical and physical access authorizations to information systems/facilities when individuals are reassigned or transferred to other positions within the organization;\n b. Initiates [Assignment: organization-defined transfer or reassignment actions] within [Assignment: organization-defined time period following the formal transfer action];\n c. Modifies access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and\n d. Notifies **five days of the time period following the formal transfer action (DoD 24 hours)** within [Assignment: organization-defined time period]." - }, - { - "ref": "PS-6", - "title": "Access Agreements", - "summary": "The organization:\n a. Develops and documents access agreements for organizational information systems;\n b. Reviews and updates the access agreements **at least annually**; and\n c. Ensures that individuals requiring access to organizational information and information systems:\n 1. Sign appropriate access agreements prior to being granted access; and\n 2. Re-sign access agreements to maintain access to organizational information systems when access agreements have been updated or **at least annually**." - }, - { - "ref": "PS-7", - "title": "Third-Party Personnel Security", - "summary": "The organization:\n a. Establishes personnel security requirements including security roles and responsibilities for third-party providers;\n b. Requires third-party providers to comply with personnel security policies and procedures established by the organization;\n c. Documents personnel security requirements;\n d. Requires third-party providers to notify **organization-defined time period – same day** of any personnel transfers or terminations of third-party personnel who possess organizational credentials and/or badges, or who have information system privileges within [Assignment: organization-defined time period]; and\n e. Monitors provider compliance." - }, - { - "ref": "PS-8", - "title": "Personnel Sanctions", - "summary": "The organization:\n a. Employs a formal sanctions process for individuals failing to comply with established information security policies and procedures; and\n b. Notifies [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period] when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction." - } - ] - }, - { - "title": "RISK ASSESSMENT", - "controls": [ - { - "ref": "RA-1", - "title": "Risk Assessment Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A risk assessment policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the risk assessment policy and associated risk assessment controls; and\n b. Reviews and updates the current:\n 1. Risk assessment policy **at least every 3 years**; and\n 2. Risk assessment procedures **at least annually**." - }, - { - "ref": "RA-2", - "title": "Security Categorization", - "summary": "The organization:\n a. Categorizes information and the information system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Documents the security categorization results (including supporting rationale) in the security plan for the information system; and\n c. Ensures that the security categorization decision is reviewed and approved by the authorizing official or authorizing official designated representative." - }, - { - "ref": "RA-3", - "title": "Risk Assessment", - "summary": "The organization:\n a. Conducts an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits;\n b. Documents risk assessment results in [Selection: security plan; risk assessment report; **security assessment report**];\n c. Reviews risk assessment results **at least every three (3) years or when a significant change occurs**;\n d. Disseminates risk assessment results to [Assignment: organization-defined personnel or roles]; and\n e. Updates the risk assessment **at least every three (3) years or when a significant change occurs** or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system." - }, - { - "ref": "RA-5", - "title": "Vulnerability Scanning", - "summary": "The organization:\n a. Scans for vulnerabilities in the information system and hosted applications **monthly operating system/infrastructure; monthly web applications and databases** and when new vulnerabilities potentially affecting the system/applications are identified and reported;\n b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n 1. Enumerating platforms, software flaws, and improper configurations;\n 2. Formatting checklists and test procedures; and\n 3. Measuring vulnerability impact;\n c. Analyzes vulnerability scan reports and results from security control assessments;\n d. Remediates legitimate vulnerabilities **high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery**, in accordance with an organizational assessment of risk; and\n e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies)." - }, - { - "ref": "RA-5 (1)", - "title": "Vulnerability Scanning | Update Tool Capability", - "summary": "The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned." - }, - { - "ref": "RA-5 (2)", - "title": "Vulnerability Scanning | Update By Frequency / Prior To New Scan / When Identified", - "summary": "The organization updates the information system vulnerabilities scanned [Selection (one or more): **prior to a new scan**; prior to a new scan; when new vulnerabilities are identified and reported]." - }, - { - "ref": "RA-5 (3)", - "title": "Vulnerability Scanning | Breadth / Depth of Coverage", - "summary": "The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked)." - }, - { - "ref": "RA-5 (5)", - "title": "Vulnerability Scanning | Privileged Access", - "summary": "The information system implements privileged access authorization to **operating systems / web applications / databases** for selected **all scans**." - }, - { - "ref": "RA-5 (6)", - "title": "Vulnerability Scanning | Automated Trend Analyses", - "summary": "The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities." - }, - { - "ref": "RA-5 (8)", - "title": "Vulnerability Scanning | Review Historic Audit Logs", - "summary": "The organization reviews historic audit logs to determine if a vulnerability identified in the information system has been previously exploited." - } - ] - }, - { - "title": "SYSTEM AND SERVICES ACQUISITION", - "controls": [ - { - "ref": "SA-1", - "title": "System and Services Acquisition Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and services acquisition policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and services acquisition policy and associated system and services acquisition controls; and\n b. Reviews and updates the current:\n 1. System and services acquisition policy **at least every 3 years**; and\n 2. System and services acquisition procedures **at least annually**." - }, - { - "ref": "SA-2", - "title": "Allocation of Resources", - "summary": "The organization:\n a. Determines information security requirements for the information system or information system service in mission/business process planning;\n b. Determines, documents, and allocates the resources required to protect the information system or information system service as part of its capital planning and investment control process; and\n c. Establishes a discrete line item for information security in organizational programming and budgeting documentation." - }, - { - "ref": "SA-3", - "title": "System Development Life Cycle", - "summary": "The organization:\n a. Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;\n b. Defines and documents information security roles and responsibilities throughout the system development life cycle;\n c. Identifies individuals having information security roles and responsibilities; and\n d. Integrates the organizational information security risk management process into system development life cycle activities." - }, - { - "ref": "SA-4", - "title": "Acquisition Process", - "summary": "The organization includes the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition contract for the information system, system component, or information system service in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, guidelines, and organizational mission/business needs:\n a. Security functional requirements;\n b. Security strength requirements;\n c. Security assurance requirements;\n d. Security-related documentation requirements;\n e. Requirements for protecting security-related documentation;\n f. Description of the information system development environment and environment in which the system is intended to operate; and\n g. Acceptance criteria." - }, - { - "ref": "SA-4 (1)", - "title": "Acquisition Process | Functional Properties of Security Controls", - "summary": "The organization requires the developer of the information system, system component, or information system service to provide a description of the functional properties of the security controls to be employed." - }, - { - "ref": "SA-4 (2)", - "title": "Acquisition Process | Design / Implementation Information for Security Controls", - "summary": "The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information, **to include security-relevant external system interfaces and high-level design**]] at [Assignment: organization-defined level of detail]." - }, - { - "ref": "SA-4 (8)", - "title": "Acquisition Process | Continuous Monitoring Plan", - "summary": "The organization requires the developer of the information system, system component, or information system service to produce a plan for the continuous monitoring of security control effectiveness that contains **at least the minimum requirement as defined in control CA-7**." - }, - { - "ref": "SA-4 (9)", - "title": "Acquisition Process | Functions / Ports / Protocols / Services in Use", - "summary": "The organization requires the developer of the information system, system component, or information system service to identify early in the system development life cycle, the functions, ports, protocols, and services intended for organizational use." - }, - { - "ref": "SA-4 (10)", - "title": "Acquisition Process | Use of Approved Piv Products", - "summary": "The organization employs only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational information systems." - }, - { - "ref": "SA-5", - "title": "Information System Documentation", - "summary": "The organization:\n a. Obtains administrator documentation for the information system, system component, or information system service that describes:\n 1. Secure configuration, installation, and operation of the system, component, or service;\n 2. Effective use and maintenance of security functions/mechanisms; and\n 3. Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions;\n b. Obtains user documentation for the information system, system component, or information system service that describes:\n 1. User-accessible security functions/mechanisms and how to effectively use those security functions/mechanisms;\n 2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner; and\n 3. User responsibilities in maintaining the security of the system, component, or service;\n c. Documents attempts to obtain information system, system component, or information system service documentation when such documentation is either unavailable or nonexistent and [Assignment: organization-defined actions] in response;\n d. Protects documentation as required, in accordance with the risk management strategy; and e. Distributes documentation to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SA-8", - "title": "Security Engineering Principles", - "summary": "The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system." - }, - { - "ref": "SA-9", - "title": "External Information System Services", - "summary": "The organization:\n a. Requires that providers of external information system services comply with organizational information security requirements and employ **FedRAMP Security Controls Baseline(s) if Federal information is processed or stored within the external system** in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance;\n b. Defines and documents government oversight and user roles and responsibilities with regard to external information system services; and\n c. Employs **Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored** to monitor security control compliance by external service providers on an ongoing basis." - }, - { - "ref": "SA-9 (1)", - "title": "External Information Systems | Risk Assessments / Organizational Approvals", - "summary": "The organization:\n (a) Conducts an organizational assessment of risk prior to the acquisition or outsourcing of dedicated information security services; and\n (b) Ensures that the acquisition or outsourcing of dedicated information security services is approved by [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SA-9 (2)", - "title": "External Information Systems | Identification of Functions / Ports / Protocols / Services", - "summary": "The organization requires providers of **all external systems where Federal information is processed or stored** to identify the functions, ports, protocols, and other services required for the use of such services." - }, - { - "ref": "SA-9 (4)", - "title": "External Information Systems | Consistent Interests of Consumers and Providers", - "summary": "The organization employs **all external systems where Federal information is processed or stored** to ensure that the interests of [Assignment: organization-defined external service providers] are consistent with and reflect organizational interests." - }, - { - "ref": "SA-9 (5)", - "title": "External Information Systems | Processing, Storage, and Service Location", - "summary": "The organization restricts the location of [Selection (one or more): information processing; information/data; information system services] to **information processing, information data, AND information services** based on [Assignment: organization-defined requirements or conditions]." - }, - { - "ref": "SA-10", - "title": "Developer Configuration Management", - "summary": "The organization requires the developer of the information system, system component, or information system service to:\n a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation];\n b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management];\n c. Implement only organization-approved changes to the system, component, or service;\n d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and\n e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel]." - }, - { - "ref": "SA-10 (1)", - "title": "Developer Configuration Management | Software / Firmware Integrity Verification", - "summary": "The organization requires the developer of the information system, system component, or information system service to enable integrity verification of software and firmware components." - }, - { - "ref": "SA-11", - "title": "Developer Security Testing and Evaluation", - "summary": "The organization requires the developer of the information system, system component, or information system service to:\n a. Create and implement a security assessment plan;\n b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage];\n c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation;\n d. Implement a verifiable flaw remediation process; and\n e. Correct flaws identified during security testing/evaluation." - }, - { - "ref": "SA-11 (1)", - "title": "Developer Security Testing and Evaluation | Static Code Analysis", - "summary": "The organization requires the developer of the information system, system component, or information system service to employ static code analysis tools to identify common flaws and document the results of the analysis." - }, - { - "ref": "SA-11 (2)", - "title": "Developer Security Testing and Evaluation | Threat and Vulnerability Analyses", - "summary": "The organization requires the developer of the information system, system component, or information system service to perform threat and vulnerability analyses and subsequent testing/evaluation of the as-built system, component, or service." - }, - { - "ref": "SA-11 (8)", - "title": "Developer Security Testing and Evaluation | Dynamic Code Analysis", - "summary": "The organization requires the developer of the information system, system component, or information system service to employ dynamic code analysis tools to identify common flaws and document the results of the analysis." - } - ] - }, - { - "title": "SYSTEM AND COMMUNICATIONS PROTECTION", - "controls": [ - { - "ref": "SC-1", - "title": "System and Communications Protection Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and communications protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and communications protection policy and associated system and communications protection controls; and\n b. Reviews and updates the current:\n 1. System and communications protection policy **at least every 3 years**; and\n 2. System and communications protection procedures **at least annually**." - }, - { - "ref": "SC-2", - "title": "Application Partitioning", - "summary": "The information system separates user functionality (including user interface services) from information system management functionality." - }, - { - "ref": "SC-4", - "title": "Information in Shared Resources", - "summary": "The information system prevents unauthorized and unintended information transfer via shared system resources." - }, - { - "ref": "SC-5", - "title": "Denial of Service Protection", - "summary": "The information system protects against or limits the effects of the following types of denial of service attacks: [Assignment: organization-defined types of denial of service attacks or reference to source for such information] by employing [Assignment: organization-defined security safeguards]." - }, - { - "ref": "SC-6", - "title": "Resource Availability", - "summary": "The information system protects the availability of resources by allocating [Assignment: organization-defined resources] by [Selection (one or more); priority; quota; [Assignment: organization-defined security safeguards]]." - }, - { - "ref": "SC-7", - "title": "Boundary Protection", - "summary": "The information system:\n a. Monitors and controls communications at the external boundary of the system and at key internal boundaries within the system;\n b. Implements subnetworks for publicly accessible system components that are [Selection: physically; logically] separated from internal organizational networks; and\n c. Connects to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture." - }, - { - "ref": "SC-7 (3)", - "title": "Boundary Protection | Access Points", - "summary": "The organization limits the number of external network connections to the information system." - }, - { - "ref": "SC-7 (4)", - "title": "Boundary Protection | External Telecommunications Services", - "summary": "The organization:\n (a) Implements a managed interface for each external telecommunication service; \n (b) Establishes a traffic flow policy for each managed interface;\n (c) Protects the confidentiality and integrity of the information being transmitted across each interface;\n (d) Documents each exception to the traffic flow policy with a supporting mission/business need and duration of that need; and\n (e) Reviews exceptions to the traffic flow policy [Assignment: organization-defined frequency] and removes exceptions that are no longer supported by an explicit mission/business need." - }, - { - "ref": "SC-7 (5)", - "title": "Boundary Protection | Deny By Default / Allow By Exception", - "summary": "The information system at managed interfaces denies network communications traffic by default and allows network communications traffic by exception (i.e., deny all, permit by exception)." - }, - { - "ref": "SC-7 (7)", - "title": "Boundary Protection | Prevent Split Tunneling for Remote Devices", - "summary": "The information system, in conjunction with a remote device, prevents the device from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks." - }, - { - "ref": "SC-7 (8)", - "title": "Boundary Protection | Route Traffic To Authenticated Proxy Servers", - "summary": "The information system routes [Assignment: organization-defined internal communications traffic] to [Assignment: organization-defined external networks] through authenticated proxy servers at managed interfaces." - }, - { - "ref": "SC-7 (12)", - "title": "Boundary Protection | Host-Based Protection", - "summary": "The organization implements [Assignment: organization-defined host-based boundary protection mechanisms] at [Assignment: organization-defined information system components]." - }, - { - "ref": "SC-7 (13)", - "title": "Boundary Protection | Isolation of Security Tools / Mechanisms / Support Components", - "summary": "The organization isolates [Assignment: organization-defined information security tools, mechanisms, and support components] from other internal information system components by implementing physically separate subnetworks with managed interfaces to other components of the system." - }, - { - "ref": "SC-7 (18)", - "title": "Boundary Protection | Fail Secure", - "summary": "The information system fails securely in the event of an operational failure of a boundary protection device." - }, - { - "ref": "SC-8", - "title": "Transmission Confidentiality and Integrity", - "summary": "The information system protects the [Selection (one or more): confidentiality; integrity] of transmitted information." - }, - { - "ref": "SC-8 (1)", - "title": "Transmission Confidentiality and Integrity | Cryptographic or Alternate Physical Protection", - "summary": "The information system implements cryptographic mechanisms to [Selection (one or more): prevent unauthorized disclosure of information; detect changes to information] during transmission unless otherwise protected by **prevent unauthorized disclosure of information AND detect changes to information**." - }, - { - "ref": "SC-10", - "title": "Network Disconnect", - "summary": "The information system terminates the network connection associated with a communications session at the end of the session or after **no longer than 30 minutes for RAS-based sessions or no longer than 60 minutes for non-interactive user sessions** of inactivity." - }, - { - "ref": "SC-12", - "title": "Cryptographic Key Establishment and Management", - "summary": "The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction]." - }, - { - "ref": "SC-12 (2)", - "title": "Cryptographic Key Establishment and Management | Symmetric Keys", - "summary": "The organization produces, controls, and distributes symmetric cryptographic keys using [Selection: NIST FIPS-compliant; NSA-approved] key management technology and processes." - }, - { - "ref": "SC-12 (3)", - "title": "Cryptographic Key Establishment and Management | Asymmetric Keys", - "summary": "The organization produces, controls, and distributes asymmetric cryptographic keys using [Selection: NSA-approved key management technology and processes; approved PKI Class 3 certificates or prepositioned keying material; approved PKI Class 3 or Class 4 certificates and hardware security tokens that protect the user’s private key]." - }, - { - "ref": "SC-13", - "title": "Cryptographic Protection", - "summary": "The information system implements **FIPS-validated or NSA-approved cryptography** in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards." - }, - { - "ref": "SC-15", - "title": "Collaborative Computing Devices", - "summary": "The information system:\n a. Prohibits remote activation of collaborative computing devices with the following exceptions: **no exceptions**; and\n b. Provides an explicit indication of use to users physically present at the devices." - }, - { - "ref": "SC-17", - "title": "Public Key Infrastructure Certificates", - "summary": "The organization issues public key certificates under an [Assignment: organization- defined certificate policy] or obtains public key certificates from an approved service provider." - }, - { - "ref": "SC-18", - "title": "Mobile Code", - "summary": "The organization:\n a. Defines acceptable and unacceptable mobile code and mobile code technologies;\n b. Establishes usage restrictions and implementation guidance for acceptable mobile code and mobile code technologies; and\n c. Authorizes, monitors, and controls the use of mobile code within the information system." - }, - { - "ref": "SC-19", - "title": "Voice Over Internet Protocol", - "summary": "The organization:\n a. Establishes usage restrictions and implementation guidance for Voice over Internet Protocol (VoIP) technologies based on the potential to cause damage to the information system if used maliciously; and\n b. Authorizes, monitors, and controls the use of VoIP within the information system." - }, - { - "ref": "SC-20", - "title": "Secure Name /Address Resolution Service (Authoritative Source)", - "summary": "The information system:\n a. Provides additional data origin and integrity artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and\n b. Provides the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace." - }, - { - "ref": "SC-21", - "title": "Secure Name /Address Resolution Service (Recursive or Caching Resolver)", - "summary": "The information system requests and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources." - }, - { - "ref": "SC-22", - "title": "Architecture and Provisioning for Name/Address Resolution Service", - "summary": "The information systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal/external role separation." - }, - { - "ref": "SC-23", - "title": "Session Authenticity", - "summary": "The information system protects the authenticity of communications sessions." - }, - { - "ref": "SC-28", - "title": "Protection of Information At Rest", - "summary": "The information system protects the [Selection (one or more): confidentiality; integrity] of **confidentiality AND integrity**." - }, - { - "ref": "SC-28 (1)", - "title": "Protection of Information At Rest | Cryptographic Protection", - "summary": "The information system implements cryptographic mechanisms to prevent unauthorized disclosure and modification of [Assignment: organization-defined information] on [Assignment: organization-defined information system components]." - }, - { - "ref": "SC-39", - "title": "Process Isolation", - "summary": "The information system maintains a separate execution domain for each executing process." - } - ] - }, - { - "title": "SYSTEM AND INFORMATION INTEGRITY", - "controls": [ - { - "ref": "SI-1", - "title": "System and Information Integrity Policy and Procedures", - "summary": "The organization:\n a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:\n 1. A system and information integrity policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n 2. Procedures to facilitate the implementation of the system and information integrity policy and associated system and information integrity controls; and\n b. Reviews and updates the current:\n 1. System and information integrity policy **at least every 3 years**; and\n 2. System and information integrity procedures **at least annually**." - }, - { - "ref": "SI-2", - "title": "Flaw Remediation", - "summary": "The organization:\na. Identifies, reports, and corrects information system flaws;\nb. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;\nc. Installs security-relevant software and firmware updates within **within thirty (30) days of release of updates** of the release of the updates; and\nd. Incorporates flaw remediation into the organizational configuration management process." - }, - { - "ref": "SI-2 (2)", - "title": "Flaw Remediation | Automated Flaw Remediation Status", - "summary": "The organization employs automated mechanisms **at least monthly** to determine the state of information system components with regard to flaw remediation." - }, - { - "ref": "SI-2 (3)", - "title": "Flaw Remediation | Time To Remediate Flaws / Benchmarks for Corrective Actions", - "summary": "The organization:\n (a) Measures the time between flaw identification and flaw remediation; and\n (b) Establishes [Assignment: organization-defined benchmarks] for taking corrective actions." - }, - { - "ref": "SI-3", - "title": "Malicious Code Protection", - "summary": "The organization:\n a. Employs malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code;\n b. Updates malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy and procedures;\n c. Configures malicious code protection mechanisms to:\n 1. Perform periodic scans of the information system **at least weekly** and real-time scans of files from external sources at [Selection (one or more); endpoint; network entry/exit points] as the files are downloaded, opened, or executed in accordance with organizational security policy; and\n 2. [Selection (one or more): block malicious code; quarantine malicious code; send alert to administrator; [Assignment: organization-defined action, **to include alerting administrator or defined security personnel**]] in response to malicious code detection; and\n d. Addresses the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the information system." - }, - { - "ref": "SI-3 (1)", - "title": "Malicious Code Protection | Central Management", - "summary": "The organization centrally manages malicious code protection mechanisms." - }, - { - "ref": "SI-3 (2)", - "title": "Malicious Code Protection | Automatic Updates", - "summary": "The information system automatically updates malicious code protection mechanisms." - }, - { - "ref": "SI-3 (7)", - "title": "Malicious Code Protection | Nonsignature-Based Detection", - "summary": "The information system implements nonsignature-based malicious code detection mechanisms." - }, - { - "ref": "SI-4", - "title": "Information System Monitoring", - "summary": "The organization:\n a. Monitors the information system to detect:\n 1. Attacks and indicators of potential attacks in accordance with [Assignment: organization- defined monitoring objectives]; and\n 2. Unauthorized local, network, and remote connections;\n b. Identifies unauthorized use of the information system through [Assignment: organization- defined techniques and methods];\n c. Deploys monitoring devices: (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;\n d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;\n e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;\n f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and\n g. Provides [Assignment: or ganization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]]." - }, - { - "ref": "SI-4 (1)", - "title": "Information System Monitoring | System-Wide Intrusion Detection System", - "summary": "The organization connects and configures individual intrusion detection tools into an information system-wide intrusion detection system." - }, - { - "ref": "SI-4 (2)", - "title": "Information System Monitoring | Automated Tools for Real-Time Analysis", - "summary": "The organization employs automated tools to support near real-time analysis of events." - }, - { - "ref": "SI-4 (4)", - "title": "Information System Monitoring | Inbound and Outbound Communications Traffic", - "summary": "The information system monitors inbound and outbound communications traffic **continuously** for unusual or unauthorized activities or conditions." - }, - { - "ref": "SI-4 (5)", - "title": "Information System Monitoring | System-Generated Alerts", - "summary": "The information system alerts [Assignment: organization-defined personnel or roles] when the following indications of compromise or potential compromise occur: [Assignment: organization- defined compromise indicators]." - }, - { - "ref": "SI-4 (14)", - "title": "Information System Monitoring | Wireless Intrusion Detection", - "summary": "The organization employs a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises/breaches to the information system." - }, - { - "ref": "SI-4 (16)", - "title": "Information System Monitoring | Correlate Monitoring Information", - "summary": "The organization correlates information from monitoring tools employed throughout the information system." - }, - { - "ref": "SI-4 (23)", - "title": "Information System Monitoring | Host-Based Devices", - "summary": "The organization implements [Assignment: organization-defined host-based monitoring mechanisms] at [Assignment: organization-defined information system components]." - }, - { - "ref": "SI-5", - "title": "Security Alerts, Advisories, and Directives", - "summary": "The organization:\n a. Receives information system security alerts, advisories, and directives from [Assignment: organization-defined external organizations, **to include US-CERT**] on an ongoing basis;\n b. Generates internal security alerts, advisories, and directives as deemed necessary;\n c. Disseminates security alerts, advisories, and directives to: [Selection (one or more): [Assignment: organization-defined personnel or roles, **to include system security personnel and administrators with configuration/patch-management responsibilities**]; [Assignment: organization-defined elements within the organization]; [Assignment: organization-defined external organizations]]; and\n d. Implements security directives in accordance with established time frames, or notifies the issuing organization of the degree of noncompliance." - }, - { - "ref": "SI-6", - "title": "Security Function Verification", - "summary": "The information system:\n a. Verifies the correct operation of [Assignment: organization-defined security functions];\n b. Performs this verification [Selection (one or more): [Assignment: organization-defined system transitional states, **to include upon system startup and/or restart and at least monthly**]; upon command by user with appropriate privilege; [Assignment: organization-defined frequency]];\n c. Notifies [Assignment: organization-defined personnel or roles, **to include system administrators and security personnel**] of failed security verification tests; and\n d. [Selection (one or more): shuts the information system down; restarts the information system; [Assignment: organization-defined alternative action(s), **to include notification of system administrators and security personnel**]] when anomalies are discovered." - }, - { - "ref": "SI-7", - "title": "Software, Firmware, and Information Integrity", - "summary": "The organization employs integrity verification tools to detect unauthorized changes to [Assignment: organization-defined software, firmware, and information]." - }, - { - "ref": "SI-7 (1)", - "title": "Software, Firmware, and Information Integrity | Integrity Checks", - "summary": "The information system performs an integrity check of [Assignment: organization-defined software, firmware, and information] [Selection (one or more): at startup; at [Assignment: organization-defined transitional states or security-relevant events, **selection to include security relevant events**]; **at least monthly**]." - }, - { - "ref": "SI-7 (7)", - "title": "Software, Firmware, and Information Integrity | Integration of Detection and Response", - "summary": "The organization incorporates the detection of unauthorized [Assignment: organization-defined security-relevant changes to the information system] into the organizational incident response capability." - }, - { - "ref": "SI-8", - "title": "Spam Protection", - "summary": "The organization:\n a. Employs spam protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages; and\n b. Updates spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures." - }, - { - "ref": "SI-8 (1)", - "title": "Spam Protection | Central Management", - "summary": "The organization centrally manages spam protection mechanisms." - }, - { - "ref": "SI-8 (2)", - "title": "Spam Protection | Automatic Updates", - "summary": "The information system automatically updates spam protection mechanisms." - }, - { - "ref": "SI-10", - "title": "Information Input Validation", - "summary": "The information system checks the validity of [Assignment: organization-defined information inputs]." - }, - { - "ref": "SI-11", - "title": "Error Handling", - "summary": "The information system:\n a. Generates error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries; and\n b. Reveals error messages only to [Assignment: organization-defined personnel or roles]." - }, - { - "ref": "SI-12", - "title": "Information Handling and Retention", - "summary": "The organization handles and retains information within the information system and information output from the system in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and operational requirements." - }, - { - "ref": "SI-16", - "title": "Memory Protection", - "summary": "The information system implements [Assignment: organization-defined security safeguards] to protect its memory from unauthorized code execution." + "standard": "FedRAMP Rev 5 Moderate Baseline", + "version": "Rev 5", + "basedOn": "fedramp-2.0.0-oscal1.0.4", + "webLink": "https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog.json", + "domains": [ + { + "title": "Access Control", + "controls": [ + { + "ref": "AC-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} access control policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the access control policy and the associated access controls;\nb. Designate an {{ official - an official to manage the access control policy and procedures is defined; }} to manage the development, documentation, and dissemination of the access control policy and procedures; and\nc. Review and update the current access control:\n1. Policy at least every 3 years and following {{ events - events that would require the current access control policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AC-2", + "title": "Account Management", + "summary": "Account Management\na. Define and document the types of accounts allowed and specifically prohibited for use within the system;\nb. Assign account managers;\nc. Require {{ prerequisites and criteria - prerequisites and criteria for group and role membership are defined; }} for group and role membership;\nd. Specify:\n1. Authorized users of the system;\n2. Group and role membership; and\n3. Access authorizations (i.e., privileges) and {{ attributes (as required) - attributes (as required) for each account are defined; }} for each account;\ne. Require approvals by {{ personnel or roles - personnel or roles required to approve requests to create accounts is/are defined; }} for requests to create accounts;\nf. Create, enable, modify, disable, and remove accounts in accordance with {{ policy, procedures, prerequisites, and criteria - policy, procedures, prerequisites, and criteria for account creation, enabling, modification, disabling, and removal are defined; }};\ng. Monitor the use of accounts;\nh. Notify account managers and {{ personnel or roles - personnel or roles to be notified is/are defined; }} within:\n1. twenty-four (24) hours when accounts are no longer required;\n2. eight (8) hours when users are terminated or transferred; and\n3. eight (8) hours when system usage or need-to-know changes for an individual;\ni. Authorize access to the system based on:\n1. A valid access authorization;\n2. Intended system usage; and\n3. {{ attributes (as required) - attributes needed to authorize system access (as required) are defined; }};\nj. Review accounts for compliance with account management requirements quarterly for privileged access, annually for non-privileged access;\nk. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and\nl. Align account management processes with personnel termination and transfer processes.\ncontrols AC-2(1) Automated System Account Management\nSupport the management of system accounts using {{ automated mechanisms - automated mechanisms used to support the management of system accounts are defined; }}.\nAC-2(2) Automated Temporary and Emergency Account Management\nAutomatically disables temporary and emergency accounts after no more than 96 hours from last use.\nAC-2(3) Disable Accounts\nDisable accounts within 24 hours for user accounts when the accounts:\n(a) Have expired;\n(b) Are no longer associated with a user or individual;\n(c) Are in violation of organizational policy; or\n(d) Have been inactive for ninety (90) days (See additional requirements and guidance.).\nAC-2 (3) Additional FedRAMP Requirements and Guidance Requirement: The service provider defines the time period for non-user accounts (e.g., accounts associated with devices). The time periods are approved and accepted by the JAB/AO. Where user management is a function of the service, reports of activity of consumer users shall be made available.\n(d) Requirement: The service provider defines the time period of inactivity for device identifiers.\nAC-2(4) Automated Audit Actions\nAutomatically audit account creation, modification, enabling, disabling, and removal actions.\nAC-2(5) Inactivity Logout\nRequire that users log out when for privileged users, it is the end of a user's standard work period.\nAC-2 (5) Additional FedRAMP Requirements and Guidance \nAC-2(7) Privileged User Accounts\n(a) Establish and administer privileged user accounts in accordance with {{ a role-based access scheme OR an attribute-based access scheme }};\n(b) Monitor privileged role or attribute assignments;\n(c) Monitor changes to roles or attributes; and\n(d) Revoke access when privileged role or attribute assignments are no longer appropriate.\nAC-2(9) Restrictions on Use of Shared and Group Accounts\nOnly permit the use of shared and group accounts that meet organization-defined need with justification statement that explains why such accounts are necessary.\nAC-2 (9) Additional FedRAMP Requirements and Guidance Requirement: Required if shared/group accounts are deployed.\nAC-2(12) Account Monitoring for Atypical Usage\n(a) Monitor system accounts for {{ atypical usage - atypical usage for which to monitor system accounts is defined; }} ; and\n(b) Report atypical usage of system accounts to at a minimum, the ISSO and/or similar role within the organization.\nAC-2 (12) Additional FedRAMP Requirements and Guidance (a) Requirement: Required for privileged accounts.\n(b) Requirement: Required for privileged accounts.\nAC-2(13) Disable Accounts for High-risk Individuals\nDisable accounts of individuals within one (1) hour of discovery of {{ significant risks - significant risks leading to disabling accounts are defined; }}.", + "guidance": "Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.\n\nWhere access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.\n\nTemporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training." + }, + { + "ref": "AC-3", + "title": "Access Enforcement", + "summary": "Access Enforcement\nEnforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.", + "guidance": "Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (i.e., devices, files, records, domains) in organizational systems. In addition to enforcing authorized access at the system level and recognizing that systems can host many applications and services in support of mission and business functions, access enforcement mechanisms can also be employed at the application and service level to provide increased information security and privacy. In contrast to logical access controls that are implemented within the system, physical access controls are addressed by the controls in the Physical and Environmental Protection ( [PE] ) family." + }, + { + "ref": "AC-4", + "title": "Information Flow Enforcement", + "summary": "Information Flow Enforcement\nEnforce approved authorizations for controlling the flow of information within the system and between connected systems based on {{ information flow control policies - information flow control policies within the system and between connected systems are defined; }}.\ncontrols AC-4(21) Physical or Logical Separation of Information Flows\nSeparate information flows logically or physically using {{ organization-defined mechanisms and/or techniques }} to accomplish {{ required separations - required separations by types of information are defined; }}.", + "guidance": "Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see [CA-3] ). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regrading mechanisms to reassign security or privacy attributes and labels.\n\nOrganizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS)." + }, + { + "ref": "AC-5", + "title": "Separation of Duties", + "summary": "Separation of Duties\na. Identify and document {{ duties of individuals - duties of individuals requiring separation are defined; }} ; and\nb. Define system access authorizations to support separation of duties.\nAC-5 Additional FedRAMP Requirements and Guidance ", + "guidance": "Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. Separation of duties includes dividing mission or business functions and support functions among different individuals or roles, conducting system support functions with different individuals, and ensuring that security personnel who administer access control functions do not also administer audit functions. Because separation of duty violations can span systems and application domains, organizations consider the entirety of systems and system components when developing policy on separation of duties. Separation of duties is enforced through the account management activities in [AC-2] , access control mechanisms in [AC-3] , and identity management activities in [IA-2], [IA-4] , and [IA-12]." + }, + { + "ref": "AC-6", + "title": "Least Privilege", + "summary": "Least Privilege\nEmploy the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.\ncontrols AC-6(1) Authorize Access to Security Functions\nAuthorize access for {{ individuals and roles - individuals and roles with authorized access to security functions and security-relevant information are defined; }} to:\n(a) {{ organization-defined security functions (deployed in hardware, software, and firmware) }} ; and\n(b) {{ security-relevant information - security-relevant information for authorized access is defined; }}.\nAC-6(2) Non-privileged Access for Nonsecurity Functions\nRequire that users of system accounts (or roles) with access to all security functions use non-privileged accounts or roles, when accessing nonsecurity functions.\nAC-6 (2) Additional FedRAMP Requirements and Guidance \nAC-6(5) Privileged Accounts\nRestrict privileged accounts on the system to {{ personnel or roles - personnel or roles to which privileged accounts on the system are to be restricted is/are defined; }}.\nAC-6(7) Review of User Privileges\n(a) Review at a minimum, annually the privileges assigned to all users with privileges to validate the need for such privileges; and\n(b) Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.\nAC-6(9) Log Use of Privileged Functions\nLog the execution of privileged functions.\nAC-6(10) Prohibit Non-privileged Users from Executing Privileged Functions\nPrevent non-privileged users from executing privileged functions.", + "guidance": "Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions. Organizations consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege. Organizations apply least privilege to the development, implementation, and operation of organizational systems." + }, + { + "ref": "AC-7", + "title": "Unsuccessful Logon Attempts", + "summary": "Unsuccessful Logon Attempts\na. Enforce a limit of {{ number - the number of consecutive invalid logon attempts by a user allowed during a time period is defined; }} consecutive invalid logon attempts by a user during a {{ time period - the time period to which the number of consecutive invalid logon attempts by a user is limited is defined; }} ; and\nb. Automatically {{ one or more: lock the account or node for {{ time period - time period for an account or node to be locked is defined (if selected); }} , lock the account or node until released by an administrator, delay next logon prompt per {{ delay algorithm - delay algorithm for the next logon prompt is defined (if selected); }} , notify system administrator, take other {{ action - other action to be taken when the maximum number of unsuccessful attempts is exceeded is defined (if selected); }} }} when the maximum number of unsuccessful attempts is exceeded.\nAC-7 Additional FedRAMP Requirements and Guidance Requirement: In alignment with NIST SP 800-63B", + "guidance": "The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need." + }, + { + "ref": "AC-8", + "title": "System Use Notification", + "summary": "System Use Notification\na. Display see additional Requirements and Guidance to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:\n1. Users are accessing a U.S. Government system;\n2. System usage may be monitored, recorded, and subject to audit;\n3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and\n4. Use of the system indicates consent to monitoring and recording;\nb. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and\nc. For publicly accessible systems:\n1. Display system use information see additional Requirements and Guidance , before granting further access to the publicly accessible system;\n2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and\n3. Include a description of the authorized uses of the system.\nAC-8 Additional FedRAMP Requirements and Guidance Requirement: If not performed as part of a Configuration Baseline check, then there must be documented agreement on how to provide results of verification and the necessary periodicity of the verification by the service provider. The documented agreement on how to provide verification of the results are approved and accepted by the JAB/AO.", + "guidance": "System use notifications can be implemented using messages or warning banners displayed before individuals log in to systems. System use notifications are used only for access via logon interfaces with human users. Notifications are not required when human interfaces do not exist. Based on an assessment of risk, organizations consider whether or not a secondary system use notification is needed to access applications or other system resources after the initial network logon. Organizations consider system use notification messages or banners displayed in multiple languages based on organizational needs and the demographics of system users. Organizations consult with the privacy office for input regarding privacy messaging and the Office of the General Counsel or organizational equivalent for legal review and approval of warning banner content." + }, + { + "ref": "AC-11", + "title": "Device Lock", + "summary": "Device Lock\na. Prevent further access to the system by {{ one or more: initiating a device lock after fifteen (15) minutes of inactivity, requiring the user to initiate a device lock before leaving the system unattended }} ; and\nb. Retain the device lock until the user reestablishes access using established identification and authentication procedures.\ncontrols AC-11(1) Pattern-hiding Displays\nConceal, via the device lock, information previously visible on the display with a publicly viewable image.", + "guidance": "Device locks are temporary actions taken to prevent logical access to organizational systems when users stop work and move away from the immediate vicinity of those systems but do not want to log out because of the temporary nature of their absences. Device locks can be implemented at the operating system level or at the application level. A proximity lock may be used to initiate the device lock (e.g., via a Bluetooth-enabled device or dongle). User-initiated device locking is behavior or policy-based and, as such, requires users to take physical action to initiate the device lock. Device locks are not an acceptable substitute for logging out of systems, such as when organizations require users to log out at the end of workdays." + }, + { + "ref": "AC-12", + "title": "Session Termination", + "summary": "Session Termination\nAutomatically terminate a user session after {{ conditions or trigger events - conditions or trigger events requiring session disconnect are defined; }}.", + "guidance": "Session termination addresses the termination of user-initiated logical sessions (in contrast to [SC-10] , which addresses the termination of network connections associated with communications sessions (i.e., network disconnect)). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational system. Such user sessions can be terminated without terminating network sessions. Session termination ends all processes associated with a user\u2019s logical session except for those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events that require automatic termination of the session include organization-defined periods of user inactivity, targeted responses to certain types of incidents, or time-of-day restrictions on system use." + }, + { + "ref": "AC-14", + "title": "Permitted Actions Without Identification or Authentication", + "summary": "Permitted Actions Without Identification or Authentication\na. Identify {{ user actions - user actions that can be performed on the system without identification or authentication are defined; }} that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and\nb. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.", + "guidance": "Specific user actions may be permitted without identification or authentication if organizations determine that identification and authentication are not required for the specified user actions. Organizations may allow a limited number of user actions without identification or authentication, including when individuals access public websites or other publicly accessible federal systems, when individuals use mobile phones to receive calls, or when facsimiles are received. Organizations identify actions that normally require identification or authentication but may, under certain circumstances, allow identification or authentication mechanisms to be bypassed. Such bypasses may occur, for example, via a software-readable physical switch that commands bypass of the logon functionality and is protected from accidental or unmonitored use. Permitting actions without identification or authentication does not apply to situations where identification and authentication have already occurred and are not repeated but rather to situations where identification and authentication have not yet occurred. Organizations may decide that there are no user actions that can be performed on organizational systems without identification and authentication, and therefore, the value for the assignment operation can be \"none.\" " + }, + { + "ref": "AC-17", + "title": "Remote Access", + "summary": "Remote Access\na. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and\nb. Authorize each type of remote access to the system prior to allowing such connections.\ncontrols AC-17(1) Monitoring and Control\nEmploy automated mechanisms to monitor and control remote access methods.\nAC-17(2) Protection of Confidentiality and Integrity Using Encryption\nImplement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.\nAC-17(3) Managed Access Control Points\nRoute remote accesses through authorized and managed network access control points.\nAC-17(4) Privileged Commands and Access\n(a) Authorize the execution of privileged commands and access to security-relevant information via remote access only in a format that provides assessable evidence and for the following needs: {{ organization-defined needs }} ; and\n(b) Document the rationale for remote access in the security plan for the system.", + "guidance": "Remote access is access to organizational systems (or processes acting on behalf of users) that communicate through external networks such as the Internet. Types of remote access include dial-up, broadband, and wireless. Organizations use encrypted virtual private networks (VPNs) to enhance confidentiality and integrity for remote connections. The use of encrypted VPNs provides sufficient assurance to the organization that it can effectively treat such connections as internal networks if the cryptographic mechanisms used are implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Still, VPN connections traverse external networks, and the encrypted VPN does not enhance the availability of remote connections. VPNs with encrypted tunnels can also affect the ability to adequately monitor network communications traffic for malicious code. Remote access controls apply to systems other than public web servers or systems designed for public access. Authorization of each remote access type addresses authorization prior to allowing remote access without specifying the specific formats for such authorization. While organizations may use information exchange and system connection security agreements to manage remote access connections to other systems, such agreements are addressed as part of [CA-3] . Enforcing access restrictions for remote access is addressed via [AC-3]." + }, + { + "ref": "AC-18", + "title": "Wireless Access", + "summary": "Wireless Access\na. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and\nb. Authorize each type of wireless access to the system prior to allowing such connections.\ncontrols AC-18(1) Authentication and Encryption\nProtect wireless access to the system using authentication of {{ one or more: users, devices }} and encryption.\nAC-18(3) Disable Wireless Networking\nDisable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.", + "guidance": "Wireless technologies include microwave, packet radio (ultra-high frequency or very high frequency), 802.11x, and Bluetooth. Wireless networks use authentication protocols that provide authenticator protection and mutual authentication." + }, + { + "ref": "AC-19", + "title": "Access Control for Mobile Devices", + "summary": "Access Control for Mobile Devices\na. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and\nb. Authorize the connection of mobile devices to organizational systems.\ncontrols AC-19(5) Full Device or Container-based Encryption\nEmploy {{ full-device encryption OR container-based encryption }} to protect the confidentiality and integrity of information on {{ mobile devices - mobile devices on which to employ encryption are defined; }}.", + "guidance": "A mobile device is a computing device that has a small form factor such that it can easily be carried by a single individual; is designed to operate without a physical connection; possesses local, non-removable or removable data storage; and includes a self-contained power source. Mobile device functionality may also include voice communication capabilities, on-board sensors that allow the device to capture information, and/or built-in features for synchronizing local data with remote locations. Examples include smart phones and tablets. Mobile devices are typically associated with a single individual. The processing, storage, and transmission capability of the mobile device may be comparable to or merely a subset of notebook/desktop systems, depending on the nature and intended purpose of the device. Protection and control of mobile devices is behavior or policy-based and requires users to take physical action to protect and control such devices when outside of controlled areas. Controlled areas are spaces for which organizations provide physical or procedural controls to meet the requirements established for protecting information and systems.\n\nDue to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions and specific implementation guidance for mobile devices include configuration management, device identification and authentication, implementation of mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware.\n\nUsage restrictions and authorization to connect may vary among organizational systems. For example, the organization may authorize the connection of mobile devices to its network and impose a set of usage restrictions, while a system owner may withhold authorization for mobile device connection to specific applications or impose additional usage restrictions before allowing mobile device connections to a system. Adequate security for mobile devices goes beyond the requirements specified in [AC-19] . Many safeguards for mobile devices are reflected in other controls. [AC-20] addresses mobile devices that are not organization-controlled." + }, + { + "ref": "AC-20", + "title": "Use of External Systems", + "summary": "Use of External Systems\na. {{ one or more: establish {{ terms and conditions - terms and conditions consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems are defined (if selected); }} , identify {{ controls asserted - controls asserted to be implemented on external systems consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems are defined (if selected); }} }} , consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:\n1. Access the system from external systems; and\n2. Process, store, or transmit organization-controlled information using external systems; or\nb. Prohibit the use of {{ prohibited types of external systems - types of external systems prohibited from use are defined; }}.\nAC-20 Additional FedRAMP Requirements and Guidance \ncontrols AC-20(1) Limits on Authorized Use\nPermit authorized individuals to use an external system to access the system or to process, store, or transmit organization-controlled information only after:\n(a) Verification of the implementation of controls on the external system as specified in the organization\u2019s security and privacy policies and security and privacy plans; or\n(b) Retention of approved system connection or processing agreements with the organizational entity hosting the external system.\nAC-20(2) Portable Storage Devices \u2014 Restricted Use\nRestrict the use of organization-controlled portable storage devices by authorized individuals on external systems using {{ restrictions - restrictions on the use of organization-controlled portable storage devices by authorized individuals on external systems are defined; }}.", + "guidance": "External systems are systems that are used by but not part of organizational systems, and for which the organization has no direct control over the implementation of required controls or the assessment of control effectiveness. External systems include personally owned systems, components, or devices; privately owned computing and communications devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; systems managed by contractors; and federal information systems that are not owned by, operated by, or under the direct supervision or authority of the organization. External systems also include systems owned or operated by other components within the same organization and systems within the organization with different authorization boundaries. Organizations have the option to prohibit the use of any type of external system or prohibit the use of specified types of external systems, (e.g., prohibit the use of any external system that is not organizationally owned or prohibit the use of personally-owned systems).\n\nFor some external systems (i.e., systems operated by other organizations), the trust relationships that have been established between those organizations and the originating organization may be such that no explicit terms and conditions are required. Systems within these organizations may not be considered external. These situations occur when, for example, there are pre-existing information exchange agreements (either implicit or explicit) established between organizations or components or when such agreements are specified by applicable laws, executive orders, directives, regulations, policies, or standards. Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to organizational systems and over which organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals need not be uniform, as the restrictions may vary depending on trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments.\n\nExternal systems used to access public interfaces to organizational systems are outside the scope of [AC-20] . Organizations establish specific terms and conditions for the use of external systems in accordance with organizational security policies and procedures. At a minimum, terms and conditions address the specific types of applications that can be accessed on organizational systems from external systems and the highest security category of information that can be processed, stored, or transmitted on external systems. If the terms and conditions with the owners of the external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems." + }, + { + "ref": "AC-21", + "title": "Information Sharing", + "summary": "Information Sharing\na. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information\u2019s access and use restrictions for {{ information-sharing circumstances - information-sharing circumstances where user discretion is required to determine whether access authorizations assigned to a sharing partner match the information\u2019s access and use restrictions are defined; }} ; and\nb. Employ {{ automated mechanisms - automated mechanisms or manual processes that assist users in making information-sharing and collaboration decisions are defined; }} to assist users in making information sharing and collaboration decisions.", + "guidance": "Information sharing applies to information that may be restricted in some manner based on some formal or administrative determination. Examples of such information include, contract-sensitive information, classified information related to special access programs or compartments, privileged information, proprietary information, and personally identifiable information. Security and privacy risk assessments as well as applicable laws, regulations, and policies can provide useful inputs to these determinations. Depending on the circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program or compartment. Access restrictions may include non-disclosure agreements (NDA). Information flow techniques and security attributes may be used to provide automated assistance to users making sharing and collaboration decisions." + }, + { + "ref": "AC-22", + "title": "Publicly Accessible Content", + "summary": "Publicly Accessible Content\na. Designate individuals authorized to make information publicly accessible;\nb. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;\nc. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and\nd. Review the content on the publicly accessible system for nonpublic information at least quarterly and remove such information, if discovered.", + "guidance": "In accordance with applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the public is not authorized to have access to nonpublic information, including information protected under the [PRIVACT] and proprietary information. Publicly accessible content addresses systems that are controlled by the organization and accessible to the public, typically without identification or authentication. Posting information on non-organizational systems (e.g., non-organizational public websites, forums, and social media) is covered by organizational policy. While organizations may have individuals who are responsible for developing and implementing policies about the information that can be made publicly accessible, publicly accessible content addresses the management of the individuals who make such information publicly accessible." + } + ] + }, + { + "title": "Awareness and Training", + "controls": [ + { + "ref": "AT-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} awareness and training policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the awareness and training policy and the associated awareness and training controls;\nb. Designate an {{ official - an official to manage the awareness and training policy and procedures is defined; }} to manage the development, documentation, and dissemination of the awareness and training policy and procedures; and\nc. Review and update the current awareness and training:\n1. Policy at least every 3 years and following {{ events - events that would require the current awareness and training policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Awareness and training policy and procedures address the controls in the AT family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of awareness and training policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to awareness and training policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AT-2", + "title": "Literacy Training and Awareness", + "summary": "Literacy Training and Awareness\na. Provide security and privacy literacy training to system users (including managers, senior executives, and contractors):\n1. As part of initial training for new users and at least annually thereafter; and\n2. When required by system changes or following {{ organization-defined events }};\nb. Employ the following techniques to increase the security and privacy awareness of system users {{ awareness techniques - techniques to be employed to increase the security and privacy awareness of system users are defined; }};\nc. Update literacy training and awareness content at least annually and following {{ events - events that would require literacy training and awareness content to be updated are defined; }} ; and\nd. Incorporate lessons learned from internal or external security incidents or breaches into literacy training and awareness techniques.\ncontrols AT-2(2) Insider Threat\nProvide literacy training on recognizing and reporting potential indicators of insider threat.\nAT-2(3) Social Engineering and Mining\nProvide literacy training on recognizing and reporting potential and actual instances of social engineering and social mining.", + "guidance": "Organizations provide basic and advanced levels of literacy training to system users, including measures to test the knowledge level of users. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and privacy as well as actions by users to maintain security and personal privacy and to respond to suspected incidents. The content addresses the need for operations security and the handling of personally identifiable information.\n\nAwareness techniques include displaying posters, offering supplies inscribed with security and privacy reminders, displaying logon screen messages, generating email advisories or notices from organizational officials, and conducting awareness events. Literacy training after the initial training described in [AT-2a.1] is conducted at a minimum frequency consistent with applicable laws, directives, regulations, and policies. Subsequent literacy training may be satisfied by one or more short ad hoc sessions and include topical information on recent attack schemes, changes to organizational security and privacy policies, revised security and privacy expectations, or a subset of topics from the initial training. Updating literacy training and awareness content on a regular basis helps to ensure that the content remains relevant. Events that may precipitate an update to literacy training and awareness content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "AT-3", + "title": "Role-based Training", + "summary": "Role-based Training\na. Provide role-based security and privacy training to personnel with the following roles and responsibilities: {{ organization-defined roles and responsibilities }}:\n1. Before authorizing access to the system, information, or performing assigned duties, and at least annually thereafter; and\n2. When required by system changes;\nb. Update role-based training content at least annually and following {{ events - events that require role-based training content to be updated are defined; }} ; and\nc. Incorporate lessons learned from internal or external security incidents or breaches into role-based training.", + "guidance": "Organizations determine the content of training based on the assigned roles and responsibilities of individuals as well as the security and privacy requirements of organizations and the systems to which personnel have authorized access, including technical training specifically tailored for assigned duties. Roles that may require role-based training include senior leaders or management officials (e.g., head of agency/chief executive officer, chief information officer, senior accountable official for risk management, senior agency information security officer, senior agency official for privacy), system owners; authorizing officials; system security officers; privacy officers; acquisition and procurement officials; enterprise architects; systems engineers; software developers; systems security engineers; privacy engineers; system, network, and database administrators; auditors; personnel conducting configuration management activities; personnel performing verification and validation activities; personnel with access to system-level software; control assessors; personnel with contingency planning and incident response duties; personnel with privacy management responsibilities; and personnel with access to personally identifiable information.\n\nComprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls. Role-based training also includes policies, procedures, tools, methods, and artifacts for the security and privacy roles defined. Organizations provide the training necessary for individuals to fulfill their responsibilities related to operations and supply chain risk management within the context of organizational security and privacy programs. Role-based training also applies to contractors who provide services to federal agencies. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Updating role-based training on a regular basis helps to ensure that the content remains relevant and effective. Events that may precipitate an update to role-based training content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "AT-4", + "title": "Training Records", + "summary": "Training Records\na. Document and monitor information security and privacy training activities, including security and privacy awareness training and specific role-based security and privacy training; and\nb. Retain individual training records for at least one (1) year or 1 year after completion of a specific training program.", + "guidance": "Documentation for specialized training may be maintained by individual supervisors at the discretion of the organization. The National Archives and Records Administration provides guidance on records retention for federal agencies." + } + ] + }, + { + "title": "Audit and Accountability", + "controls": [ + { + "ref": "AU-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} audit and accountability policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the audit and accountability policy and the associated audit and accountability controls;\nb. Designate an {{ official - an official to manage the audit and accountability policy and procedures is defined; }} to manage the development, documentation, and dissemination of the audit and accountability policy and procedures; and\nc. Review and update the current audit and accountability:\n1. Policy at least every 3 years and following {{ events - events that would require the current audit and accountability policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Audit and accountability policy and procedures address the controls in the AU family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of audit and accountability policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to audit and accountability policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "AU-2", + "title": "Event Logging", + "summary": "Event Logging\na. Identify the types of events that the system is capable of logging in support of the audit function: successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes;\nb. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;\nc. Specify the following event types for logging within the system: organization-defined subset of the auditable events defined in AU-2a to be audited continually for each identified event.;\nd. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and\ne. Review and update the event types selected for logging annually and whenever there is a change in the threat environment.\nAU-2 Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.", + "guidance": "An event is an observable occurrence in a system. The types of events that require logging are those events that are significant and relevant to the security of systems and the privacy of individuals. Event logging also supports specific monitoring and auditing needs. Event types include password changes, failed logons or failed accesses related to systems, security or privacy attribute changes, administrative privilege usage, PIV credential usage, data action changes, query parameters, or external credential usage. In determining the set of event types that require logging, organizations consider the monitoring and auditing appropriate for each of the controls to be implemented. For completeness, event logging includes all protocols that are operational and supported by the system.\n\nTo balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. The types of events that organizations desire to be logged may change. Reviewing and updating the set of logged events is necessary to help ensure that the events remain relevant and continue to support the needs of the organization. Organizations consider how the types of logging events can reveal information about individuals that may give rise to privacy risk and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the logging event is based on patterns or time of usage.\n\nEvent logging requirements, including the need to log specific event types, may be referenced in other controls and control enhancements. These include [AC-2(4)], [AC-3(10)], [AC-6(9)], [AC-17(1)], [CM-3f], [CM-5(1)], [IA-3(3)(b)], [MA-4(1)], [MP-4(2)], [PE-3], [PM-21], [PT-7], [RA-8], [SC-7(9)], [SC-7(15)], [SI-3(8)], [SI-4(22)], [SI-7(8)] , and [SI-10(1)] . Organizations include event types that are required by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Audit records can be generated at various levels, including at the packet level as information traverses the network. Selecting the appropriate level of event logging is an important part of a monitoring and auditing capability and can identify the root causes of problems. When defining event types, organizations consider the logging necessary to cover related event types, such as the steps in distributed, transaction-based processes and the actions that occur in service-oriented architectures." + }, + { + "ref": "AU-3", + "title": "Content of Audit Records", + "summary": "Content of Audit Records\nEnsure that audit records contain information that establishes the following:\na. What type of event occurred;\nb. When the event occurred;\nc. Where the event occurred;\nd. Source of the event;\ne. Outcome of the event; and\nf. Identity of any individuals, subjects, or objects/entities associated with the event.\ncontrols AU-3(1) Additional Audit Information\nGenerate audit records containing the following additional information: session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands.\nAU-3 (1) Additional FedRAMP Requirements and Guidance ", + "guidance": "Audit record content that may be necessary to support the auditing function includes event descriptions (item a), time stamps (item b), source and destination addresses (item c), user or process identifiers (items d and f), success or fail indications (item e), and filenames involved (items a, c, e, and f) . Event outcomes include indicators of event success or failure and event-specific results, such as the system security and privacy posture after the event occurred. Organizations consider how audit records can reveal information about individuals that may give rise to privacy risks and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the trail records inputs or is based on patterns or time of usage." + }, + { + "ref": "AU-4", + "title": "Audit Log Storage Capacity", + "summary": "Audit Log Storage Capacity\nAllocate audit log storage capacity to accommodate {{ audit log retention requirements - audit log retention requirements are defined; }}.", + "guidance": "Organizations consider the types of audit logging to be performed and the audit log processing requirements when allocating audit log storage capacity. Allocating sufficient audit log storage capacity reduces the likelihood of such capacity being exceeded and resulting in the potential loss or reduction of audit logging capability." + }, + { + "ref": "AU-5", + "title": "Response to Audit Logging Process Failures", + "summary": "Response to Audit Logging Process Failures\na. Alert {{ personnel or roles - personnel or roles receiving audit logging process failure alerts are defined; }} within {{ time period - time period for personnel or roles receiving audit logging process failure alerts is defined; }} in the event of an audit logging process failure; and\nb. Take the following additional actions: overwrite oldest record.", + "guidance": "Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Organization-defined actions include overwriting oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel." + }, + { + "ref": "AU-6", + "title": "Audit Record Review, Analysis, and Reporting", + "summary": "Audit Record Review, Analysis, and Reporting\na. Review and analyze system audit records at least weekly for indications of {{ inappropriate or unusual activity - inappropriate or unusual activity is defined; }} and the potential impact of the inappropriate or unusual activity;\nb. Report findings to {{ personnel or roles - personnel or roles to receive findings from reviews and analyses of system records is/are defined; }} ; and\nc. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.\nAU-6 Additional FedRAMP Requirements and Guidance Requirement: Coordination between service provider and consumer shall be documented and accepted by the JAB/AO. In multi-tenant environments, capability and means for providing review, analysis, and reporting to consumer for data pertaining to consumer shall be documented.\ncontrols AU-6(1) Automated Process Integration\nIntegrate audit record review, analysis, and reporting processes using {{ automated mechanisms - automated mechanisms used for integrating audit record review, analysis, and reporting processes are defined; }}.\nAU-6(3) Correlate Audit Record Repositories\nAnalyze and correlate audit records across different repositories to gain organization-wide situational awareness.", + "guidance": "Audit record review, analysis, and reporting covers information security- and privacy-related logging performed by organizations, including logging that results from the monitoring of account usage, remote access, wireless connectivity, mobile device connection, configuration settings, system component inventory, use of maintenance tools and non-local maintenance, physical access, temperature and humidity, equipment delivery and removal, communications at system interfaces, and use of mobile code or Voice over Internet Protocol (VoIP). Findings can be reported to organizational entities that include the incident response team, help desk, and security or privacy offices. If organizations are prohibited from reviewing and analyzing audit records or unable to conduct such activities, the review or analysis may be carried out by other organizations granted such authority. The frequency, scope, and/or depth of the audit record review, analysis, and reporting may be adjusted to meet organizational needs based on new information received." + }, + { + "ref": "AU-7", + "title": "Audit Record Reduction and Report Generation", + "summary": "Audit Record Reduction and Report Generation\nProvide and implement an audit record reduction and report generation capability that:\na. Supports on-demand audit record review, analysis, and reporting requirements and after-the-fact investigations of incidents; and\nb. Does not alter the original content or time ordering of audit records.\ncontrols AU-7(1) Automatic Processing\nProvide and implement the capability to process, sort, and search audit records for events of interest based on the following content: {{ fields within audit records - fields within audit records that can be processed, sorted, or searched are defined; }}.", + "guidance": "Audit record reduction is a process that manipulates collected audit log information and organizes it into a summary format that is more meaningful to analysts. Audit record reduction and report generation capabilities do not always emanate from the same system or from the same organizational entities that conduct audit logging activities. The audit record reduction capability includes modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the system can generate customizable reports. Time ordering of audit records can be an issue if the granularity of the timestamp in the record is insufficient." + }, + { + "ref": "AU-8", + "title": "Time Stamps", + "summary": "Time Stamps\na. Use internal system clocks to generate time stamps for audit records; and\nb. Record time stamps for audit records that meet one second granularity of time measurement and that use Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or that include the local time offset as part of the time stamp.", + "guidance": "Time stamps generated by the system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. Granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., clocks synchronizing within hundreds of milliseconds or tens of milliseconds). Organizations may define different time granularities for different system components. Time service can be critical to other security capabilities such as access control and identification and authentication, depending on the nature of the mechanisms used to support those capabilities." + }, + { + "ref": "AU-9", + "title": "Protection of Audit Information", + "summary": "Protection of Audit Information\na. Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and\nb. Alert {{ personnel or roles - personnel or roles to be alerted upon detection of unauthorized access, modification, or deletion of audit information is/are defined; }} upon detection of unauthorized access, modification, or deletion of audit information.\ncontrols AU-9(4) Access by Subset of Privileged Users\nAuthorize access to management of audit logging functionality to only {{ subset of privileged users or roles - a subset of privileged users or roles authorized to access management of audit logging functionality is defined; }}.", + "guidance": "Audit information includes all information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are those programs and devices used to conduct system audit and logging activities. Protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by both media protection controls and physical and environmental protection controls." + }, + { + "ref": "AU-11", + "title": "Audit Record Retention", + "summary": "Audit Record Retention\nRetain audit records for a time period in compliance with M-21-31 to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.\nAU-11 Additional FedRAMP Requirements and Guidance Requirement: The service provider must support Agency requirements to comply with M-21-31 (https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf)", + "guidance": "Organizations retain audit records until it is determined that the records are no longer needed for administrative, legal, audit, or other operational purposes. This includes the retention and availability of audit records relative to Freedom of Information Act (FOIA) requests, subpoenas, and law enforcement actions. Organizations develop standard categories of audit records relative to such types of actions and standard response processes for each type of action. The National Archives and Records Administration (NARA) General Records Schedules provide federal policy on records retention." + }, + { + "ref": "AU-12", + "title": "Audit Record Generation", + "summary": "Audit Record Generation\na. Provide audit record generation capability for the event types the system is capable of auditing as defined in [AU-2a] on all information system and network components where audit capability is deployed/available;\nb. Allow {{ personnel or roles - personnel or roles allowed to select the event types that are to be logged by specific components of the system is/are defined; }} to select the event types that are to be logged by specific components of the system; and\nc. Generate audit records for the event types defined in [AU-2c] that include the audit record content defined in [AU-3].", + "guidance": "Audit records can be generated from many different system components. The event types specified in [AU-2d] are the event types for which audit logs are to be generated and are a subset of all event types for which the system can generate audit records." + } + ] + }, + { + "title": "Assessment, Authorization, and Monitoring", + "controls": [ + { + "ref": "CA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} assessment, authorization, and monitoring policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the assessment, authorization, and monitoring policy and the associated assessment, authorization, and monitoring controls;\nb. Designate an {{ official - an official to manage the assessment, authorization, and monitoring policy and procedures is defined; }} to manage the development, documentation, and dissemination of the assessment, authorization, and monitoring policy and procedures; and\nc. Review and update the current assessment, authorization, and monitoring:\n1. Policy at least every 3 years and following {{ events - events that would require the current assessment, authorization, and monitoring policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Assessment, authorization, and monitoring policy and procedures address the controls in the CA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of assessment, authorization, and monitoring policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to assessment, authorization, and monitoring policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CA-2", + "title": "Control Assessments", + "summary": "Control Assessments\na. Select the appropriate assessor or assessment team for the type of assessment to be conducted;\nb. Develop a control assessment plan that describes the scope of the assessment including:\n1. Controls and control enhancements under assessment;\n2. Assessment procedures to be used to determine control effectiveness; and\n3. Assessment environment, assessment team, and assessment roles and responsibilities;\nc. Ensure the control assessment plan is reviewed and approved by the authorizing official or designated representative prior to conducting the assessment;\nd. Assess the controls in the system and its environment of operation at least annually to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements;\ne. Produce a control assessment report that document the results of the assessment; and\nf. Provide the results of the control assessment to individuals or roles to include FedRAMP PMO.\nCA-2 Additional FedRAMP Requirements and Guidance \ncontrols CA-2(1) Independent Assessors\nEmploy independent assessors or assessment teams to conduct control assessments.\nCA-2 (1) Additional FedRAMP Requirements and Guidance Requirement: For JAB Authorization, must use an accredited 3PAO.\nCA-2(3) Leveraging Results from External Organizations\nLeverage the results of control assessments performed by any FedRAMP Accredited 3PAO on {{ system - system on which a control assessment was performed by an external organization is defined; }} when the assessment meets the conditions of the JAB/AO in the FedRAMP Repository.", + "guidance": "Organizations ensure that control assessors possess the required skills and technical expertise to develop effective assessment plans and to conduct assessments of system-specific, hybrid, common, and program management controls, as appropriate. The required skills include general knowledge of risk management concepts and approaches as well as comprehensive knowledge of and experience with the hardware, software, and firmware system components implemented.\n\nOrganizations assess controls in systems and the environments in which those systems operate as part of initial and ongoing authorizations, continuous monitoring, FISMA annual assessments, system design and development, systems security engineering, privacy engineering, and the system development life cycle. Assessments help to ensure that organizations meet information security and privacy requirements, identify weaknesses and deficiencies in the system design and development process, provide essential information needed to make risk-based decisions as part of authorization processes, and comply with vulnerability mitigation procedures. Organizations conduct assessments on the implemented controls as documented in security and privacy plans. Assessments can also be conducted throughout the system development life cycle as part of systems engineering and systems security engineering processes. The design for controls can be assessed as RFPs are developed, responses assessed, and design reviews conducted. If a design to implement controls and subsequent implementation in accordance with the design are assessed during development, the final control testing can be a simple confirmation utilizing previously completed control assessment and aggregating the outcomes.\n\nOrganizations may develop a single, consolidated security and privacy assessment plan for the system or maintain separate plans. A consolidated assessment plan clearly delineates the roles and responsibilities for control assessment. If multiple organizations participate in assessing a system, a coordinated approach can reduce redundancies and associated costs.\n\nOrganizations can use other types of assessment activities, such as vulnerability scanning and system monitoring, to maintain the security and privacy posture of systems during the system life cycle. Assessment reports document assessment results in sufficient detail, as deemed necessary by organizations, to determine the accuracy and completeness of the reports and whether the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting requirements. Assessment results are provided to the individuals or roles appropriate for the types of assessments being conducted. For example, assessments conducted in support of authorization decisions are provided to authorizing officials, senior agency officials for privacy, senior agency information security officers, and authorizing official designated representatives.\n\nTo satisfy annual assessment requirements, organizations can use assessment results from the following sources: initial or ongoing system authorizations, continuous monitoring, systems engineering processes, or system development life cycle activities. Organizations ensure that assessment results are current, relevant to the determination of control effectiveness, and obtained with the appropriate level of assessor independence. Existing control assessment results can be reused to the extent that the results are still valid and can also be supplemented with additional assessments as needed. After the initial authorizations, organizations assess controls during continuous monitoring. Organizations also establish the frequency for ongoing assessments in accordance with organizational continuous monitoring strategies. External audits, including audits by external entities such as regulatory agencies, are outside of the scope of [CA-2]." + }, + { + "ref": "CA-3", + "title": "Information Exchange", + "summary": "Information Exchange\na. Approve and manage the exchange of information between the system and other systems using {{ one or more: interconnection security agreements, information exchange security agreements, memoranda of understanding or agreement, service level agreements, user agreements, non-disclosure agreements, {{ type of agreement - the type of agreement used to approve and manage the exchange of information is defined (if selected); }} }};\nb. Document, as part of each exchange agreement, the interface characteristics, security and privacy requirements, controls, and responsibilities for each system, and the impact level of the information communicated; and\nc. Review and update the agreements at least annually and on input from JAB/AO.", + "guidance": "System information exchange requirements apply to information exchanges between two or more systems. System information exchanges include connections via leased lines or virtual private networks, connections to internet service providers, database sharing or exchanges of database transaction information, connections and exchanges with cloud services, exchanges via web-based services, or exchanges of files via file transfer protocols, network protocols (e.g., IPv4, IPv6), email, or other organization-to-organization communications. Organizations consider the risk related to new or increased threats that may be introduced when systems exchange information with other systems that may have different security and privacy requirements and controls. This includes systems within the same organization and systems that are external to the organization. A joint authorization of the systems exchanging information, as described in [CA-6(1)] or [CA-6(2)] , may help to communicate and reduce risk.\n\nAuthorizing officials determine the risk associated with system information exchange and the controls needed for appropriate risk mitigation. The types of agreements selected are based on factors such as the impact level of the information being exchanged, the relationship between the organizations exchanging information (e.g., government to government, government to business, business to business, government or business to service provider, government or business to individual), or the level of access to the organizational system by users of the other system. If systems that exchange information have the same authorizing official, organizations need not develop agreements. Instead, the interface characteristics between the systems (e.g., how the information is being exchanged. how the information is protected) are described in the respective security and privacy plans. If the systems that exchange information have different authorizing officials within the same organization, the organizations can develop agreements or provide the same information that would be provided in the appropriate agreement type from [CA-3a] in the respective security and privacy plans for the systems. Organizations may incorporate agreement information into formal contracts, especially for information exchanges established between federal agencies and nonfederal organizations (including service providers, contractors, system developers, and system integrators). Risk considerations include systems that share the same networks." + }, + { + "ref": "CA-5", + "title": "Plan of Action and Milestones", + "summary": "Plan of Action and Milestones\na. Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and\nb. Update existing plan of action and milestones at least monthly based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.\nCA-5 Additional FedRAMP Requirements and Guidance Requirement: POA&Ms must be provided at least monthly.", + "guidance": "Plans of action and milestones are useful for any type of organization to track planned remedial actions. Plans of action and milestones are required in authorization packages and subject to federal reporting requirements established by OMB." + }, + { + "ref": "CA-6", + "title": "Authorization", + "summary": "Authorization\na. Assign a senior official as the authorizing official for the system;\nb. Assign a senior official as the authorizing official for common controls available for inheritance by organizational systems;\nc. Ensure that the authorizing official for the system, before commencing operations:\n1. Accepts the use of common controls inherited by the system; and\n2. Authorizes the system to operate;\nd. Ensure that the authorizing official for common controls authorizes the use of those controls for inheritance by organizational systems;\ne. Update the authorizations in accordance with OMB A-130 requirements or when a significant change occurs.\nCA-6 Additional FedRAMP Requirements and Guidance ", + "guidance": "Authorizations are official management decisions by senior officials to authorize operation of systems, authorize the use of common controls for inheritance by organizational systems, and explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon controls. Authorizing officials provide budgetary oversight for organizational systems and common controls or assume responsibility for the mission and business functions supported by those systems or common controls. The authorization process is a federal responsibility, and therefore, authorizing officials must be federal employees. Authorizing officials are both responsible and accountable for security and privacy risks associated with the operation and use of organizational systems. Nonfederal organizations may have similar processes to authorize systems and senior officials that assume the authorization role and associated responsibilities.\n\nAuthorizing officials issue ongoing authorizations of systems based on evidence produced from implemented continuous monitoring programs. Robust continuous monitoring programs reduce the need for separate reauthorization processes. Through the employment of comprehensive continuous monitoring processes, the information contained in authorization packages (i.e., security and privacy plans, assessment reports, and plans of action and milestones) is updated on an ongoing basis. This provides authorizing officials, common control providers, and system owners with an up-to-date status of the security and privacy posture of their systems, controls, and operating environments. To reduce the cost of reauthorization, authorizing officials can leverage the results of continuous monitoring processes to the maximum extent possible as the basis for rendering reauthorization decisions." + }, + { + "ref": "CA-7", + "title": "Continuous Monitoring", + "summary": "Continuous Monitoring\nDevelop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes:\na. Establishing the following system-level metrics to be monitored: {{ system-level metrics - system-level metrics to be monitored are defined; }};\nb. Establishing {{ frequencies - frequencies at which to monitor control effectiveness are defined; }} for monitoring and {{ frequencies - frequencies at which to assess control effectiveness are defined; }} for assessment of control effectiveness;\nc. Ongoing control assessments in accordance with the continuous monitoring strategy;\nd. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy;\ne. Correlation and analysis of information generated by control assessments and monitoring;\nf. Response actions to address results of the analysis of control assessment and monitoring information; and\ng. Reporting the security and privacy status of the system to to include JAB/AO {{ organization-defined frequency }}.\nCA-7 Additional FedRAMP Requirements and Guidance Requirement: CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (Con Mon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSPs authorized via the Agency path as each agency customer is responsible for performing Con Mon oversight. It does not apply to CSPs authorized via the JAB path because the JAB performs Con Mon oversight.\ncontrols CA-7(1) Independent Assessment\nEmploy independent assessors or assessment teams to monitor the controls in the system on an ongoing basis.\nCA-7(4) Risk Monitoring\nEnsure risk monitoring is an integral part of the continuous monitoring strategy that includes the following:\n(a) Effectiveness monitoring;\n(b) Compliance monitoring; and\n(c) Change monitoring.", + "guidance": "Continuous monitoring at the system level facilitates ongoing awareness of the system security and privacy posture to support organizational risk management decisions. The terms \"continuous\" and \"ongoing\" imply that organizations assess and monitor their controls and risks at a frequency sufficient to support risk-based decisions. Different types of controls may require different monitoring frequencies. The results of continuous monitoring generate risk response actions by organizations. When monitoring the effectiveness of multiple controls that have been grouped into capabilities, a root-cause analysis may be needed to determine the specific control that has failed. Continuous monitoring programs allow organizations to maintain the authorizations of systems and common controls in highly dynamic environments of operation with changing mission and business needs, threats, vulnerabilities, and technologies. Having access to security and privacy information on a continuing basis through reports and dashboards gives organizational officials the ability to make effective and timely risk management decisions, including ongoing authorization decisions.\n\nAutomation supports more frequent updates to hardware, software, and firmware inventories, authorization packages, and other system information. Effectiveness is further enhanced when continuous monitoring outputs are formatted to provide information that is specific, measurable, actionable, relevant, and timely. Continuous monitoring activities are scaled in accordance with the security categories of systems. Monitoring requirements, including the need for specific monitoring, may be referenced in other controls and control enhancements, such as [AC-2g], [AC-2(7)], [AC-2(12)(a)], [AC-2(7)(b)], [AC-2(7)(c)], [AC-17(1)], [AT-4a], [AU-13], [AU-13(1)], [AU-13(2)], [CM-3f], [CM-6d], [CM-11c], [IR-5], [MA-2b], [MA-3a], [MA-4a], [PE-3d], [PE-6], [PE-14b], [PE-16], [PE-20], [PM-6], [PM-23], [PM-31], [PS-7e], [SA-9c], [SR-4], [SC-5(3)(b)], [SC-7a], [SC-7(24)(b)], [SC-18b], [SC-43b] , and [SI-4]." + }, + { + "ref": "CA-8", + "title": "Penetration Testing", + "summary": "Penetration Testing\nConduct penetration testing at least annually on {{ system(s) or system components - systems or system components on which penetration testing is to be conducted are defined; }}.\nCA-8 Additional FedRAMP Requirements and Guidance \ncontrols CA-8(1) Independent Penetration Testing Agent or Team\nEmploy an independent penetration testing agent or team to perform penetration testing on the system or system components.\nCA-8(2) Red Team Exercises\nEmploy the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement: {{ red team exercises - red team exercises to simulate attempts by adversaries to compromise organizational systems are defined; }}.\nCM-2 Additional FedRAMP Requirements and Guidance ", + "guidance": "Penetration testing is a specialized type of assessment conducted on systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Penetration testing goes beyond automated vulnerability scanning and is conducted by agents and teams with demonstrable skills and experience that include technical expertise in network, operating system, and/or application level security. Penetration testing can be used to validate vulnerabilities or determine the degree of penetration resistance of systems to adversaries within specified constraints. Such constraints include time, resources, and skills. Penetration testing attempts to duplicate the actions of adversaries and provides a more in-depth analysis of security- and privacy-related weaknesses or deficiencies. Penetration testing is especially important when organizations are transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6 network protocols).\n\nOrganizations can use the results of vulnerability analyses to support penetration testing activities. Penetration testing can be conducted internally or externally on the hardware, software, or firmware components of a system and can exercise both physical and technical controls. A standard method for penetration testing includes a pretest analysis based on full knowledge of the system, pretest identification of potential vulnerabilities based on the pretest analysis, and testing designed to determine the exploitability of vulnerabilities. All parties agree to the rules of engagement before commencing penetration testing scenarios. Organizations correlate the rules of engagement for the penetration tests with the tools, techniques, and procedures that are anticipated to be employed by adversaries. Penetration testing may result in the exposure of information that is protected by laws or regulations, to individuals conducting the testing. Rules of engagement, contracts, or other appropriate mechanisms can be used to communicate expectations for how to protect this information. Risk assessments guide the decisions on the level of independence required for the personnel conducting penetration testing." + }, + { + "ref": "CA-9", + "title": "Internal System Connections", + "summary": "Internal System Connections\na. Authorize internal connections of {{ system components - system components or classes of components requiring internal connections to the system are defined; }} to the system;\nb. Document, for each internal connection, the interface characteristics, security and privacy requirements, and the nature of the information communicated;\nc. Terminate internal system connections after {{ conditions - conditions requiring termination of internal connections are defined; }} ; and\nd. Review at least annually the continued need for each internal connection.", + "guidance": "Internal system connections are connections between organizational systems and separate constituent system components (i.e., connections between components that are part of the same system) including components used for system development. Intra-system connections include connections with mobile devices, notebook and desktop computers, tablets, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each internal system connection individually, organizations can authorize internal connections for a class of system components with common characteristics and/or configurations, including printers, scanners, and copiers with a specified processing, transmission, and storage capability or smart phones and tablets with a specific baseline configuration. The continued need for an internal system connection is reviewed from the perspective of whether it provides support for organizational missions or business functions." + } + ] + }, + { + "title": "Configuration Management", + "controls": [ + { + "ref": "CM-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} configuration management policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls;\nb. Designate an {{ official - an official to manage the configuration management policy and procedures is defined; }} to manage the development, documentation, and dissemination of the configuration management policy and procedures; and\nc. Review and update the current configuration management:\n1. Policy at least every 3 years and following {{ events - events that would require the current configuration management policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Configuration management policy and procedures address the controls in the CM family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of configuration management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to configuration management policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CM-2", + "title": "Baseline Configuration", + "summary": "Baseline Configuration\na. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and\nb. Review and update the baseline configuration of the system:\n1. at least annually and when a significant change occurs;\n2. When required due to to include when directed by the JAB ; and\n3. When system components are installed or upgraded.\nCM-2 Additional FedRAMP Requirements and Guidance \ncontrols CM-2(2) Automation Support for Accuracy and Currency\nMaintain the currency, completeness, accuracy, and availability of the baseline configuration of the system using {{ automated mechanisms - automated mechanisms for maintaining baseline configuration of the system are defined; }}.\nCM-2(3) Retention of Previous Configurations\nRetain {{ number - the number of previous baseline configuration versions to be retained is defined; }} of previous versions of baseline configurations of the system to support rollback.\nCM-2(7) Configure Systems and Components for High-risk Areas\n(a) Issue {{ systems or system components - the systems or system components to be issued when individuals travel to high-risk areas are defined; }} with {{ configurations - configurations for systems or system components to be issued when individuals travel to high-risk areas are defined; }} to individuals traveling to locations that the organization deems to be of significant risk; and\n(b) Apply the following controls to the systems or components when the individuals return from travel: {{ controls - the controls to be applied when the individuals return from travel are defined; }}.", + "guidance": "Baseline configurations for systems and system components include connectivity, operational, and communications aspects of systems. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, or changes to systems and include security and privacy control implementations, operational procedures, information about system components, network topology, and logical placement of components in the system architecture. Maintaining baseline configurations requires creating new baselines as organizational systems change over time. Baseline configurations of systems reflect the current enterprise architecture." + }, + { + "ref": "CM-3", + "title": "Configuration Change Control", + "summary": "Configuration Change Control\na. Determine and document the types of changes to the system that are configuration-controlled;\nb. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses;\nc. Document configuration change decisions associated with the system;\nd. Implement approved configuration-controlled changes to the system;\ne. Retain records of configuration-controlled changes to the system for {{ time period - the time period to retain records of configuration-controlled changes is defined; }};\nf. Monitor and review activities associated with configuration-controlled changes to the system; and\ng. Coordinate and provide oversight for configuration change control activities through {{ configuration change control element - the configuration change control element responsible for coordinating and overseeing change control activities is defined; }} that convenes {{ one or more: {{ frequency - the frequency at which the configuration control element convenes is defined (if selected); }} , when {{ configuration change conditions - configuration change conditions that prompt the configuration control element to convene are defined (if selected); }} }}.\nCM-3 Additional FedRAMP Requirements and Guidance Requirement: The service provider establishes a central means of communicating major changes to or developments in the information system or environment of operations that may affect its services to the federal government and associated service consumers (e.g., electronic bulletin board, web status page). The means of communication are approved and accepted by the JAB/AO.\ncontrols CM-3(2) Testing, Validation, and Documentation of Changes\nTest, validate, and document changes to the system before finalizing the implementation of the changes.\nCM-3(4) Security and Privacy Representatives\nRequire {{ organization-defined security and privacy representatives }} to be members of the Configuration control board (CCB) or similar (as defined in CM-3).", + "guidance": "Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of system changes, including system upgrades and modifications. Configuration change control includes changes to baseline configurations, configuration items of systems, operational procedures, configuration settings for system components, remediate vulnerabilities, and unscheduled or unauthorized changes. Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes. For changes that impact privacy risk, the senior agency official for privacy updates privacy impact assessments and system of records notices. For new systems or major upgrades, organizations consider including representatives from the development organizations on the Configuration Control Boards or Change Advisory Boards. Auditing of changes includes activities before and after changes are made to systems and the auditing activities required to implement such changes. See also [SA-10]." + }, + { + "ref": "CM-4", + "title": "Impact Analyses", + "summary": "Impact Analyses\nAnalyze changes to the system to determine potential security and privacy impacts prior to change implementation.\ncontrols CM-4(2) Verification of Controls\nAfter system changes, verify that the impacted controls are implemented correctly, operating as intended, and producing the desired outcome with regard to meeting the security and privacy requirements for the system.", + "guidance": "Organizational personnel with security or privacy responsibilities conduct impact analyses. Individuals conducting impact analyses possess the necessary skills and technical expertise to analyze the changes to systems as well as the security or privacy ramifications. Impact analyses include reviewing security and privacy plans, policies, and procedures to understand control requirements; reviewing system design documentation and operational procedures to understand control implementation and how specific system changes might affect the controls; reviewing the impact of changes on organizational supply chain partners with stakeholders; and determining how potential changes to a system create new risks to the privacy of individuals and the ability of implemented controls to mitigate those risks. Impact analyses also include risk assessments to understand the impact of the changes and determine if additional controls are required." + }, + { + "ref": "CM-5", + "title": "Access Restrictions for Change", + "summary": "Access Restrictions for Change\nDefine, document, approve, and enforce physical and logical access restrictions associated with changes to the system.\ncontrols CM-5(1) Automated Access Enforcement and Audit Records\n(a) Enforce access restrictions using {{ automated mechanisms - mechanisms used to automate the enforcement of access restrictions are defined; }} ; and\n(b) Automatically generate audit records of the enforcement actions.\nCM-5(5) Privilege Limitation for Production and Operation\n(a) Limit privileges to change system components and system-related information within a production or operational environment; and\n(b) Review and reevaluate privileges at least quarterly.", + "guidance": "Changes to the hardware, software, or firmware components of systems or the operational procedures related to the system can potentially have significant effects on the security of the systems or individuals\u2019 privacy. Therefore, organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes. Access restrictions include physical and logical access controls (see [AC-3] and [PE-3] ), software libraries, workflow automation, media libraries, abstract layers (i.e., changes implemented into external interfaces rather than directly into systems), and change windows (i.e., changes occur only during specified times)." + }, + { + "ref": "CM-6", + "title": "Configuration Settings", + "summary": "Configuration Settings\na. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using {{ common secure configurations - common secure configurations to establish and document configuration settings for components employed within the system are defined; }};\nb. Implement the configuration settings;\nc. Identify, document, and approve any deviations from established configuration settings for {{ system components - system components for which approval of deviations is needed are defined; }} based on {{ operational requirements - operational requirements necessitating approval of deviations are defined; }} ; and\nd. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.\nCM-6 Additional FedRAMP Requirements and Guidance (a) Requirement 1: The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available.\n(a) Requirement 2: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).\ncontrols CM-6(1) Automated Management, Application, and Verification\nManage, apply, and verify configuration settings for {{ system components - system components for which to manage, apply, and verify configuration settings are defined; }} using {{ organization-defined automated mechanisms }}.", + "guidance": "Configuration settings are the parameters that can be changed in the hardware, software, or firmware components of the system that affect the security and privacy posture or functionality of the system. Information technology products for which configuration settings can be defined include mainframe computers, servers, workstations, operating systems, mobile devices, input/output devices, protocols, and applications. Parameters that impact the security posture of systems include registry settings; account, file, or directory permission settings; and settings for functions, protocols, ports, services, and remote connections. Privacy parameters are parameters impacting the privacy posture of systems, including the parameters required to satisfy other privacy controls. Privacy parameters include settings for access controls, data processing preferences, and processing and retention permissions. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the configuration baseline for the system.\n\nCommon secure configurations (also known as security configuration checklists, lockdown and hardening guides, and security reference guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for information technology products and platforms as well as instructions for configuring those products or platforms to meet operational requirements. Common secure configurations can be developed by a variety of organizations, including information technology product developers, manufacturers, vendors, federal agencies, consortia, academia, industry, and other organizations in the public and private sectors.\n\nImplementation of a common secure configuration may be mandated at the organization level, mission and business process level, system level, or at a higher level, including by a regulatory agency. Common secure configurations include the United States Government Configuration Baseline [USGCB] and security technical implementation guides (STIGs), which affect the implementation of [CM-6] and other controls such as [AC-19] and [CM-7] . The Security Content Automation Protocol (SCAP) and the defined standards within the protocol provide an effective method to uniquely identify, track, and control configuration settings." + }, + { + "ref": "CM-7", + "title": "Least Functionality", + "summary": "Least Functionality\na. Configure the system to provide only {{ mission-essential capabilities - mission-essential capabilities for the system are defined; }} ; and\nb. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: {{ organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services }}.\nCM-7 Additional FedRAMP Requirements and Guidance (b) Requirement: The service provider shall use Security guidelines (See CM-6) to establish list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, protocols, and/or services if STIGs or CIS is not available.\ncontrols CM-7(1) Periodic Review\n(a) Review the system at least annually to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services; and\n(b) Disable or remove {{ organization-defined functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure }}.\nCM-7(2) Prevent Program Execution\nPrevent program execution in accordance with {{ one or more: {{ policies, rules of behavior, and/or access agreements regarding software program usage and restrictions - policies, rules of behavior, and/or access agreements regarding software program usage and restrictions are defined (if selected); }} , rules authorizing the terms and conditions of software program usage }}.\nCM-7 (2) Additional FedRAMP Requirements and Guidance \nCM-7(5) Authorized Software \u2014 Allow-by-exception\n(a) Identify {{ software programs - software programs authorized to execute on the system are defined; }};\n(b) Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and\n(c) Review and update the list of authorized software programs at least quarterly or when there is a change.", + "guidance": "Systems provide a wide variety of functions and services. Some of the functions and services routinely provided by default may not be necessary to support essential organizational missions, functions, or operations. Additionally, it is sometimes convenient to provide multiple services from a single system component, but doing so increases risk over limiting the services provided by that single component. Where feasible, organizations limit component functionality to a single function per component. Organizations consider removing unused or unnecessary software and disabling unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of components, transfer of information, and tunneling. Organizations employ network scanning tools, intrusion detection and prevention systems, and end-point protection technologies, such as firewalls and host-based intrusion detection systems, to identify and prevent the use of prohibited functions, protocols, ports, and services. Least functionality can also be achieved as part of the fundamental design and development of the system (see [SA-8], [SC-2] , and [SC-3])." + }, + { + "ref": "CM-8", + "title": "System Component Inventory", + "summary": "System Component Inventory\na. Develop and document an inventory of system components that:\n1. Accurately reflects the system;\n2. Includes all components within the system;\n3. Does not include duplicate accounting of components or components assigned to any other system;\n4. Is at the level of granularity deemed necessary for tracking and reporting; and\n5. Includes the following information to achieve system component accountability: {{ information - information deemed necessary to achieve effective system component accountability is defined; }} ; and\nb. Review and update the system component inventory at least monthly.\nCM-8 Additional FedRAMP Requirements and Guidance Requirement: must be provided at least monthly or when there is a change.\ncontrols CM-8(1) Updates During Installation and Removal\nUpdate the inventory of system components as part of component installations, removals, and system updates.\nCM-8(3) Automated Unauthorized Component Detection\n(a) Detect the presence of unauthorized hardware, software, and firmware components within the system using automated mechanisms with a maximum five-minute delay in detection continuously ; and\n(b) Take the following actions when unauthorized components are detected: {{ one or more: disable network access by unauthorized components, isolate unauthorized components, notify {{ personnel or roles - personnel or roles to be notified when unauthorized components are detected is/are defined (if selected); }} }}.", + "guidance": "System components are discrete, identifiable information technology assets that include hardware, software, and firmware. Organizations may choose to implement centralized system component inventories that include components from all organizational systems. In such situations, organizations ensure that the inventories include system-specific information required for component accountability. The information necessary for effective accountability of system components includes the system name, software owners, software version numbers, hardware inventory specifications, software license information, and for networked components, the machine names and network addresses across all implemented protocols (e.g., IPv4, IPv6). Inventory specifications include date of receipt, cost, model, serial number, manufacturer, supplier information, component type, and physical location.\n\nPreventing duplicate accounting of system components addresses the lack of accountability that occurs when component ownership and system association is not known, especially in large or complex connected systems. Effective prevention of duplicate accounting of system components necessitates use of a unique identifier for each component. For software inventory, centrally managed software that is accessed via other systems is addressed as a component of the system on which it is installed and managed. Software installed on multiple organizational systems and managed at the system level is addressed for each individual system and may appear more than once in a centralized component inventory, necessitating a system association for each software instance in the centralized inventory to avoid duplicate accounting of components. Scanning systems implementing multiple network protocols (e.g., IPv4 and IPv6) can result in duplicate components being identified in different address spaces. The implementation of [CM-8(7)] can help to eliminate duplicate accounting of components." + }, + { + "ref": "CM-9", + "title": "Configuration Management Plan", + "summary": "Configuration Management Plan\nDevelop, document, and implement a configuration management plan for the system that:\na. Addresses roles, responsibilities, and configuration management processes and procedures;\nb. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items;\nc. Defines the configuration items for the system and places the configuration items under configuration management;\nd. Is reviewed and approved by {{ personnel or roles - personnel or roles to review and approve the configuration management plan is/are defined; }} ; and\ne. Protects the configuration management plan from unauthorized disclosure and modification.", + "guidance": "Configuration management activities occur throughout the system development life cycle. As such, there are developmental configuration management activities (e.g., the control of code and software libraries) and operational configuration management activities (e.g., control of installed components and how the components are configured). Configuration management plans satisfy the requirements in configuration management policies while being tailored to individual systems. Configuration management plans define processes and procedures for how configuration management is used to support system development life cycle activities.\n\nConfiguration management plans are generated during the development and acquisition stage of the system development life cycle. The plans describe how to advance changes through change management processes; update configuration settings and baselines; maintain component inventories; control development, test, and operational environments; and develop, release, and update key documents.\n\nOrganizations can employ templates to help ensure the consistent and timely development and implementation of configuration management plans. Templates can represent a configuration management plan for the organization with subsets of the plan implemented on a system by system basis. Configuration management approval processes include the designation of key stakeholders responsible for reviewing and approving proposed changes to systems, and personnel who conduct security and privacy impact analyses prior to the implementation of changes to the systems. Configuration items are the system components, such as the hardware, software, firmware, and documentation to be configuration-managed. As systems continue through the system development life cycle, new configuration items may be identified, and some existing configuration items may no longer need to be under configuration control." + }, + { + "ref": "CM-10", + "title": "Software Usage Restrictions", + "summary": "Software Usage Restrictions\na. Use software and associated documentation in accordance with contract agreements and copyright laws;\nb. Track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and\nc. Control and document the use of 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.", + "guidance": "Software license tracking can be accomplished by manual or automated methods, depending on organizational needs. Examples of contract agreements include software license agreements and non-disclosure agreements." + }, + { + "ref": "CM-11", + "title": "User-installed Software", + "summary": "User-installed Software\na. Establish {{ policies - policies governing the installation of software by users are defined; }} governing the installation of software by users;\nb. Enforce software installation policies through the following methods: {{ methods - methods used to enforce software installation policies are defined; }} ; and\nc. Monitor policy compliance Continuously (via CM-7 (5)).", + "guidance": "If provided the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved \"app stores.\" Prohibited software installations include software with unknown or suspect pedigrees or software that organizations consider potentially malicious. Policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods." + }, + { + "ref": "CM-12", + "title": "Information Location", + "summary": "Information Location\na. Identify and document the location of {{ information - information for which the location is to be identified and documented is defined; }} and the specific system components on which the information is processed and stored;\nb. Identify and document the users who have access to the system and system components where the information is processed and stored; and\nc. Document changes to the location (i.e., system or system components) where the information is processed and stored.\nCM-12 Additional FedRAMP Requirements and Guidance Requirement: According to FedRAMP Authorization Boundary Guidance\ncontrols CM-12(1) Automated Tools to Support Information Location\nUse automated tools to identify Federal data and system data that must be protected at the High or Moderate impact levels on {{ system components - system components where the information is located are defined; }} to ensure controls are in place to protect organizational information and individual privacy.\nCM-12 (1) Additional FedRAMP Requirements and Guidance Requirement: According to FedRAMP Authorization Boundary Guidance.", + "guidance": "Information location addresses the need to understand where information is being processed and stored. Information location includes identifying where specific information types and information reside in system components and how information is being processed so that information flow can be understood and adequate protection and policy management provided for such information and system components. The security category of the information is also a factor in determining the controls necessary to protect the information and the system component where the information resides (see [FIPS 199] ). The location of the information and system components is also a factor in the architecture and design of the system (see [SA-4], [SA-8], [SA-17])." + } + ] + }, + { + "title": "Contingency Planning", + "controls": [ + { + "ref": "CP-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} contingency planning policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the contingency planning policy and the associated contingency planning controls;\nb. Designate an {{ official - an official to manage the contingency planning policy and procedures is defined; }} to manage the development, documentation, and dissemination of the contingency planning policy and procedures; and\nc. Review and update the current contingency planning:\n1. Policy at least every 3 years and following {{ events - events that would require the current contingency planning policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Contingency planning policy and procedures address the controls in the CP family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of contingency planning policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to contingency planning policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "CP-2", + "title": "Contingency Plan", + "summary": "Contingency Plan\na. Develop a contingency plan for the system that:\n1. Identifies essential mission and business functions and associated contingency requirements;\n2. Provides recovery objectives, restoration priorities, and metrics;\n3. Addresses contingency roles, responsibilities, assigned individuals with contact information;\n4. Addresses maintaining essential mission and business functions despite a system disruption, compromise, or failure;\n5. Addresses eventual, full system restoration without deterioration of the controls originally planned and implemented;\n6. Addresses the sharing of contingency information; and\n7. Is reviewed and approved by {{ organization-defined personnel or roles }};\nb. Distribute copies of the contingency plan to {{ organization-defined key contingency personnel (identified by name and/or by role) and organizational elements }};\nc. Coordinate contingency planning activities with incident handling activities;\nd. Review the contingency plan for the system at least annually;\ne. Update the contingency plan to address changes to the organization, system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing;\nf. Communicate contingency plan changes to {{ organization-defined key contingency personnel (identified by name and/or by role) and organizational elements }};\ng. Incorporate lessons learned from contingency plan testing, training, or actual contingency activities into contingency testing and training; and\nh. Protect the contingency plan from unauthorized disclosure and modification.\nCP-2 Additional FedRAMP Requirements and Guidance Requirement: CSPs must use the FedRAMP Information System Contingency Plan (ISCP) Template (available on the fedramp.gov: https://www.fedramp.gov/assets/resources/templates/SSP-A06-FedRAMP-ISCP-Template.docx).\ncontrols CP-2(1) Coordinate with Related Plans\nCoordinate contingency plan development with organizational elements responsible for related plans.\nCP-2(3) Resume Mission and Business Functions\nPlan for the resumption of all mission and business functions within time period defined in service provider and organization SLA of contingency plan activation.\nCP-2(8) Identify Critical Assets\nIdentify critical system assets supporting {{ all OR essential }} mission and business functions.", + "guidance": "Contingency planning for systems is part of an overall program for achieving continuity of operations for organizational mission and business functions. Contingency planning addresses system restoration and implementation of alternative mission or business processes when systems are compromised or breached. Contingency planning is considered throughout the system development life cycle and is a fundamental part of the system design. Systems can be designed for redundancy, to provide backup capabilities, and for resilience. Contingency plans reflect the degree of restoration required for organizational systems since not all systems need to fully recover to achieve the level of continuity of operations desired. System recovery objectives reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, organizational risk tolerance, and system impact level.\n\nActions addressed in contingency plans include orderly system degradation, system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when systems are under attack. By coordinating contingency planning with incident handling activities, organizations ensure that the necessary planning activities are in place and activated in the event of an incident. Organizations consider whether continuity of operations during an incident conflicts with the capability to automatically disable the system, as specified in [IR-4(5)] . Incident response planning is part of contingency planning for organizations and is addressed in the [IR] (Incident Response) family." + }, + { + "ref": "CP-3", + "title": "Contingency Training", + "summary": "Contingency Training\na. Provide contingency training to system users consistent with assigned roles and responsibilities:\n1. Within \\*See Additional Requirements of assuming a contingency role or responsibility;\n2. When required by system changes; and\n3. at least annually thereafter; and\nb. Review and update contingency training content at least annually and following {{ events - events necessitating review and update of contingency training are defined; }}.\nCP-3 Additional FedRAMP Requirements and Guidance (a) Requirement: Privileged admins and engineers must take the basic contingency training within 10 days. Consideration must be given for those privileged admins and engineers with critical contingency-related roles, to gain enough system context and situational awareness to understand the full impact of contingency training as it applies to their respective level. Newly hired critical contingency personnel must take this more in-depth training within 60 days of hire date when the training will have more impact.", + "guidance": "Contingency training provided by organizations is linked to the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail is included in such training. For example, some individuals may only need to know when and where to report for duty during contingency operations and if normal duties are affected; system administrators may require additional training on how to establish systems at alternate processing and storage sites; and organizational officials may receive more specific training on how to conduct mission-essential functions in designated off-site locations and how to establish communications with other governmental entities for purposes of coordination on contingency-related activities. Training for contingency roles or responsibilities reflects the specific continuity requirements in the contingency plan. Events that may precipitate an update to contingency training content include, but are not limited to, contingency plan testing or an actual contingency (lessons learned), assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. At the discretion of the organization, participation in a contingency plan test or exercise, including lessons learned sessions subsequent to the test or exercise, may satisfy contingency plan training requirements." + }, + { + "ref": "CP-4", + "title": "Contingency Plan Testing", + "summary": "Contingency Plan Testing\na. Test the contingency plan for the system at least annually using the following tests to determine the effectiveness of the plan and the readiness to execute the plan: functional exercises.\nb. Review the contingency plan test results; and\nc. Initiate corrective actions, if needed.\nCP-4 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider develops test plans in accordance with NIST Special Publication 800-34 (as amended); plans are approved by the JAB/AO prior to initiating testing.\n(b) Requirement: The service provider must include the Contingency Plan test results with the security package within the Contingency Plan-designated appendix (Appendix G, Contingency Plan Test Report).\ncontrols CP-4(1) Coordinate with Related Plans\nCoordinate contingency plan testing with organizational elements responsible for related plans.", + "guidance": "Methods for testing contingency plans to determine the effectiveness of the plans and identify potential weaknesses include checklists, walk-through and tabletop exercises, simulations (parallel or full interrupt), and comprehensive exercises. Organizations conduct testing based on the requirements in contingency plans and include a determination of the effects on organizational operations, assets, and individuals due to contingency operations. Organizations have flexibility and discretion in the breadth, depth, and timelines of corrective actions." + }, + { + "ref": "CP-6", + "title": "Alternate Storage Site", + "summary": "Alternate Storage Site\na. Establish an alternate storage site, including necessary agreements to permit the storage and retrieval of system backup information; and\nb. Ensure that the alternate storage site provides controls equivalent to that of the primary site.\ncontrols CP-6(1) Separation from Primary Site\nIdentify an alternate storage site that is sufficiently separated from the primary storage site to reduce susceptibility to the same threats.\nCP-6(3) Accessibility\nIdentify potential accessibility problems to the alternate storage site in the event of an area-wide disruption or disaster and outline explicit mitigation actions.", + "guidance": "Alternate storage sites are geographically distinct from primary storage sites and maintain duplicate copies of information and data if the primary storage site is not available. Similarly, alternate processing sites provide processing capability if the primary processing site is not available. Geographically distributed architectures that support contingency requirements may be considered alternate storage sites. Items covered by alternate storage site agreements include environmental conditions at the alternate sites, access rules for systems and facilities, physical and environmental protection requirements, and coordination of delivery and retrieval of backup media. Alternate storage sites reflect the requirements in contingency plans so that organizations can maintain essential mission and business functions despite compromise, failure, or disruption in organizational systems." + }, + { + "ref": "CP-7", + "title": "Alternate Processing Site", + "summary": "Alternate Processing Site\na. Establish an alternate processing site, including necessary agreements to permit the transfer and resumption of {{ system operations - system operations for essential mission and business functions are defined; }} for essential mission and business functions within {{ time period - time period consistent with recovery time and recovery point objectives is defined; }} when the primary processing capabilities are unavailable;\nb. Make available at the alternate processing site, the equipment and supplies required to transfer and resume operations or put contracts in place to support delivery to the site within the organization-defined time period for transfer and resumption; and\nc. Provide controls at the alternate processing site that are equivalent to those at the primary site.\nCP-7 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider defines a time period consistent with the recovery time objectives and business impact analysis.\ncontrols CP-7(1) Separation from Primary Site\nIdentify an alternate processing site that is sufficiently separated from the primary processing site to reduce susceptibility to the same threats.\nCP-7 (1) Additional FedRAMP Requirements and Guidance \nCP-7(2) Accessibility\nIdentify potential accessibility problems to alternate processing sites in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.\nCP-7(3) Priority of Service\nDevelop alternate processing site agreements that contain priority-of-service provisions in accordance with availability requirements (including recovery time objectives).", + "guidance": "Alternate processing sites are geographically distinct from primary processing sites and provide processing capability if the primary processing site is not available. The alternate processing capability may be addressed using a physical processing site or other alternatives, such as failover to a cloud-based service provider or other internally or externally provided processing service. Geographically distributed architectures that support contingency requirements may also be considered alternate processing sites. Controls that are covered by alternate processing site agreements include the environmental conditions at alternate sites, access rules, physical and environmental protection requirements, and the coordination for the transfer and assignment of personnel. Requirements are allocated to alternate processing sites that reflect the requirements in contingency plans to maintain essential mission and business functions despite disruption, compromise, or failure in organizational systems." + }, + { + "ref": "CP-8", + "title": "Telecommunications Services", + "summary": "Telecommunications Services\nEstablish alternate telecommunications services, including necessary agreements to permit the resumption of {{ system operations - system operations to be resumed for essential mission and business functions are defined; }} for essential mission and business functions within {{ time period - time period within which to resume essential mission and business functions when the primary telecommunications capabilities are unavailable is defined; }} when the primary telecommunications capabilities are unavailable at either the primary or alternate processing or storage sites.\nCP-8 Additional FedRAMP Requirements and Guidance Requirement: The service provider defines a time period consistent with the recovery time objectives and business impact analysis.\ncontrols CP-8(1) Priority of Service Provisions\n(a) Develop primary and alternate telecommunications service agreements that contain priority-of-service provisions in accordance with availability requirements (including recovery time objectives); and\n(b) Request Telecommunications Service Priority for all telecommunications services used for national security emergency preparedness if the primary and/or alternate telecommunications services are provided by a common carrier.\nCP-8(2) Single Points of Failure\nObtain alternate telecommunications services to reduce the likelihood of sharing a single point of failure with primary telecommunications services.", + "guidance": "Telecommunications services (for data and voice) for primary and alternate processing and storage sites are in scope for [CP-8] . Alternate telecommunications services reflect the continuity requirements in contingency plans to maintain essential mission and business functions despite the loss of primary telecommunications services. Organizations may specify different time periods for primary or alternate sites. Alternate telecommunications services include additional organizational or commercial ground-based circuits or lines, network-based approaches to telecommunications, or the use of satellites. Organizations consider factors such as availability, quality of service, and access when entering into alternate telecommunications agreements." + }, + { + "ref": "CP-9", + "title": "System Backup", + "summary": "System Backup\na. Conduct backups of user-level information contained in {{ system components - system components for which to conduct backups of user-level information is defined; }} daily incremental; weekly full;\nb. Conduct backups of system-level information contained in the system daily incremental; weekly full;\nc. Conduct backups of system documentation, including security- and privacy-related documentation daily incremental; weekly full ; and\nd. Protect the confidentiality, integrity, and availability of backup information.\nCP-9 Additional FedRAMP Requirements and Guidance Requirement: The service provider shall determine what elements of the cloud environment require the Information System Backup control. The service provider shall determine how Information System Backup is going to be verified and appropriate periodicity of the check.\n(a) Requirement: The service provider maintains at least three backup copies of user-level information (at least one of which is available online) or provides an equivalent alternative.\n(b) Requirement: The service provider maintains at least three backup copies of system-level information (at least one of which is available online) or provides an equivalent alternative.\n(c) Requirement: The service provider maintains at least three backup copies of information system documentation including security information (at least one of which is available online) or provides an equivalent alternative.\ncontrols CP-9(1) Testing for Reliability and Integrity\nTest backup information at least annually to verify media reliability and information integrity.\nCP-9(8) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure and modification of all backup files.\nCP-9 (8) Additional FedRAMP Requirements and Guidance ", + "guidance": "System-level information includes system state information, operating system software, middleware, application software, and licenses. User-level information includes information other than system-level information. Mechanisms employed to protect the integrity of system backups include digital signatures and cryptographic hashes. Protection of system backup information while in transit is addressed by [MP-5] and [SC-8] . System backups reflect the requirements in contingency plans as well as other organizational requirements for backing up information. Organizations may be subject to laws, executive orders, directives, regulations, or policies with requirements regarding specific categories of information (e.g., personal health information). Organizational personnel consult with the senior agency official for privacy and legal counsel regarding such requirements." + }, + { + "ref": "CP-10", + "title": "System Recovery and Reconstitution", + "summary": "System Recovery and Reconstitution\nProvide for the recovery and reconstitution of the system to a known state within {{ organization-defined time period consistent with recovery time and recovery point objectives }} after a disruption, compromise, or failure.\ncontrols CP-10(2) Transaction Recovery\nImplement transaction recovery for systems that are transaction-based.", + "guidance": "Recovery is executing contingency plan activities to restore organizational mission and business functions. Reconstitution takes place following recovery and includes activities for returning systems to fully operational states. Recovery and reconstitution operations reflect mission and business priorities; recovery point, recovery time, and reconstitution objectives; and organizational metrics consistent with contingency plan requirements. Reconstitution includes the deactivation of interim system capabilities that may have been needed during recovery operations. Reconstitution also includes assessments of fully restored system capabilities, reestablishment of continuous monitoring activities, system reauthorization (if required), and activities to prepare the system and organization for future disruptions, breaches, compromises, or failures. Recovery and reconstitution capabilities can include automated mechanisms and manual procedures. Organizations establish recovery time and recovery point objectives as part of contingency planning." + } + ] + }, + { + "title": "Identification and Authentication", + "controls": [ + { + "ref": "IA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} identification and authentication policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the identification and authentication policy and the associated identification and authentication controls;\nb. Designate an {{ official - an official to manage the identification and authentication policy and procedures is defined; }} to manage the development, documentation, and dissemination of the identification and authentication policy and procedures; and\nc. Review and update the current identification and authentication:\n1. Policy at least every 3 years and following {{ events - events that would require the current identification and authentication policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Identification and authentication policy and procedures address the controls in the IA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of identification and authentication policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to identification and authentication policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "IA-2", + "title": "Identification and Authentication (Organizational Users)", + "summary": "Identification and Authentication (Organizational Users)\nUniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.\nIA-2 Additional FedRAMP Requirements and Guidance Requirement: All uses of encrypted virtual private networks must meet all applicable Federal requirements and architecture, dataflow, and security and privacy controls must be documented, assessed, and authorized to operate.\ncontrols IA-2(1) Multi-factor Authentication to Privileged Accounts\nImplement multi-factor authentication for access to privileged accounts.\nIA-2 (1) Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\nIA-2(2) Multi-factor Authentication to Non-privileged Accounts\nImplement multi-factor authentication for access to non-privileged accounts.\nIA-2 (2) Additional FedRAMP Requirements and Guidance Requirement: Multi-factor authentication must be phishing-resistant.\nIA-2(5) Individual Authentication with Group Authentication\nWhen shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.\nIA-2(6) Access to Accounts \u2014separate Device\nImplement multi-factor authentication for local, network and remote access to privileged accounts; non-privileged accounts such that:\n(a) One of the factors is provided by a device separate from the system gaining access; and\n(b) The device meets FIPS-validated or NSA-approved cryptography.\nIA-2 (6) Additional FedRAMP Requirements and Guidance \nIA-2(8) Access to Accounts \u2014 Replay Resistant\nImplement replay-resistant authentication mechanisms for access to privileged accounts; non-privileged accounts.\nIA-2(12) Acceptance of PIV Credentials\nAccept and electronically verify Personal Identity Verification-compliant credentials.\nIA-2 (12) Additional FedRAMP Requirements and Guidance ", + "guidance": "Organizations can satisfy the identification and authentication requirements by complying with the requirements in [HSPD 12] . Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in [AC-14] and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity.\n\nOrganizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks.\n\nThe use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in [IA-8]." + }, + { + "ref": "IA-3", + "title": "Device Identification and Authentication", + "summary": "Device Identification and Authentication\nUniquely identify and authenticate {{ devices and/or types of devices - devices and/or types of devices to be uniquely identified and authenticated before establishing a connection are defined; }} before establishing a {{ one or more: local, remote, network }} connection.", + "guidance": "Devices that require unique device-to-device identification and authentication are defined by type, device, or a combination of type and device. Organization-defined device types include devices that are not owned by the organization. Systems use shared known information (e.g., Media Access Control [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and wide area networks. Organizations determine the required strength of authentication mechanisms based on the security categories of systems and mission or business requirements. Because of the challenges of implementing device authentication on a large scale, organizations can restrict the application of the control to a limited number/type of devices based on mission or business needs." + }, + { + "ref": "IA-4", + "title": "Identifier Management", + "summary": "Identifier Management\nManage system identifiers by:\na. Receiving authorization from at a minimum, the ISSO (or similar role within the organization) to assign an individual, group, role, service, or device identifier;\nb. Selecting an identifier that identifies an individual, group, role, service, or device;\nc. Assigning the identifier to the intended individual, group, role, service, or device; and\nd. Preventing reuse of identifiers for at least two (2) years.\ncontrols IA-4(4) Identify User Status\nManage individual identifiers by uniquely identifying each individual as contractors; foreign nationals.", + "guidance": "Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. The management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the usernames of the system accounts assigned to those individuals. In such instances, the account management activities of [AC-2] use account names provided by [IA-4] . Identifier management also addresses individual identifiers not necessarily associated with system accounts. Preventing the reuse of identifiers implies preventing the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices." + }, + { + "ref": "IA-5", + "title": "Authenticator Management", + "summary": "Authenticator Management\nManage system authenticators by:\na. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator;\nb. Establishing initial authenticator content for any authenticators issued by the organization;\nc. Ensuring that authenticators have sufficient strength of mechanism for their intended use;\nd. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators;\ne. Changing default authenticators prior to first use;\nf. Changing or refreshing authenticators {{ time period by authenticator type - a time period for changing or refreshing authenticators by authenticator type is defined; }} or when {{ events - events that trigger the change or refreshment of authenticators are defined; }} occur;\ng. Protecting authenticator content from unauthorized disclosure and modification;\nh. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and\ni. Changing authenticators for group or role accounts when membership to those accounts changes.\nIA-5 Additional FedRAMP Requirements and Guidance Requirement: Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 2. Link https://pages.nist.gov/800-63-3\ncontrols IA-5(1) Password-based Authentication\nFor password-based authentication:\n(a) Maintain a list of commonly-used, expected, or compromised passwords and update the list {{ frequency - the frequency at which to update the list of commonly used, expected, or compromised passwords is defined; }} and when organizational passwords are suspected to have been compromised directly or indirectly;\n(b) Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a);\n(c) Transmit passwords only over cryptographically-protected channels;\n(d) Store passwords using an approved salted key derivation function, preferably using a keyed hash;\n(e) Require immediate selection of a new password upon account recovery;\n(f) Allow user selection of long passwords and passphrases, including spaces and all printable characters;\n(g) Employ automated tools to assist the user in selecting strong password authenticators; and\n(h) Enforce the following composition and complexity rules: {{ composition and complexity rules - authenticator composition and complexity rules are defined; }}.\nIA-5 (1) Additional FedRAMP Requirements and Guidance Requirement: Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.\n(h) Requirement: For cases where technology doesn\u2019t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.\n\nFor emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.\nIA-5(2) Public Key-based Authentication\n(a) For public key-based authentication:\n(1) Enforce authorized access to the corresponding private key; and\n(2) Map the authenticated identity to the account of the individual or group; and\n(b) When public key infrastructure (PKI) is used:\n(1) Validate certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status information; and\n(2) Implement a local cache of revocation data to support path discovery and validation.\nIA-5(6) Protection of Authenticators\nProtect authenticators commensurate with the security category of the information to which use of the authenticator permits access.\nIA-5(7) No Embedded Unencrypted Static Authenticators\nEnsure that unencrypted static authenticators are not embedded in applications or other forms of static storage.\nIA-5 (7) Additional FedRAMP Requirements and Guidance ", + "guidance": "Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length). Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control [PL-4] or [PS-6] for authenticators in the possession of individuals and by controls [AC-3], [AC-6] , and [SC-28] for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges.\n\nSystems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics (e.g., minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication). Actions can be taken to safeguard individual authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed." + }, + { + "ref": "IA-6", + "title": "Authentication Feedback", + "summary": "Authentication Feedback\nObscure feedback of authentication information during the authentication process to protect the information from possible exploitation and use by unauthorized individuals.", + "guidance": "Authentication feedback from systems does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of systems, such as desktops or notebooks with relatively large monitors, the threat (referred to as shoulder surfing) may be significant. For other types of systems, such as mobile devices with small displays, the threat may be less significant and is balanced against the increased likelihood of typographic input errors due to small keyboards. Thus, the means for obscuring authentication feedback is selected accordingly. Obscuring authentication feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a very limited time before obscuring it." + }, + { + "ref": "IA-7", + "title": "Cryptographic Module Authentication", + "summary": "Cryptographic Module Authentication\nImplement mechanisms for authentication to a cryptographic module that meet the requirements of applicable laws, executive orders, directives, policies, regulations, standards, and guidelines for such authentication.", + "guidance": "Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role." + }, + { + "ref": "IA-8", + "title": "Identification and Authentication (Non-organizational Users)", + "summary": "Identification and Authentication (Non-organizational Users)\nUniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users.\ncontrols IA-8(1) Acceptance of PIV Credentials from Other Agencies\nAccept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.\nIA-8(2) Acceptance of External Authenticators\n(a) Accept only external authenticators that are NIST-compliant; and\n(b) Document and maintain a list of accepted external authenticators.\nIA-8(4) Use of Defined Profiles\nConform to the following profiles for identity management {{ identity management profiles - identity management profiles are defined; }}.", + "guidance": "Non-organizational users include system users other than organizational users explicitly covered by [IA-2] . Non-organizational users are uniquely identified and authenticated for accesses other than those explicitly identified and documented in [AC-14] . Identification and authentication of non-organizational users accessing federal systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems). Organizations consider many factors\u2014including security, privacy, scalability, and practicality\u2014when balancing the need to ensure ease of use for access to federal information and systems with the need to protect and adequately mitigate risk." + }, + { + "ref": "IA-11", + "title": "Re-authentication", + "summary": "Re-authentication\nRequire users to re-authenticate when {{ circumstances or situations - circumstances or situations requiring re-authentication are defined; }}.\nIA-11 Additional FedRAMP Requirements and Guidance ", + "guidance": "In addition to the re-authentication requirements associated with device locks, organizations may require re-authentication of individuals in certain situations, including when roles, authenticators or credentials change, when security categories of systems change, when the execution of privileged functions occurs, after a fixed time period, or periodically." + }, + { + "ref": "IA-12", + "title": "Identity Proofing", + "summary": "Identity Proofing\na. Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines;\nb. Resolve user identities to a unique individual; and\nc. Collect, validate, and verify identity evidence.\nIA-12 Additional FedRAMP Requirements and Guidance \ncontrols IA-12(2) Identity Evidence\nRequire evidence of individual identification be presented to the registration authority.\nIA-12(3) Identity Evidence Validation and Verification\nRequire that the presented identity evidence be validated and verified through {{ methods of validation and verification - methods of validation and verification of identity evidence are defined; }}.\nIA-12(5) Address Confirmation\nRequire that a {{ registration code OR notice of proofing }} be delivered through an out-of-band channel to verify the users address (physical or digital) of record.\nIA-12 (5) Additional FedRAMP Requirements and Guidance ", + "guidance": "Identity proofing is the process of collecting, validating, and verifying a user\u2019s identity information for the purposes of establishing credentials for accessing a system. Identity proofing is intended to mitigate threats to the registration of users and the establishment of their accounts. Standards and guidelines specifying identity assurance levels for identity proofing include [SP 800-63-3] and [SP 800-63A] . Organizations may be subject to laws, executive orders, directives, regulations, or policies that address the collection of identity evidence. Organizational personnel consult with the senior agency official for privacy and legal counsel regarding such requirements." + } + ] + }, + { + "title": "Incident Response", + "controls": [ + { + "ref": "IR-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} incident response policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the incident response policy and the associated incident response controls;\nb. Designate an {{ official - an official to manage the incident response policy and procedures is defined; }} to manage the development, documentation, and dissemination of the incident response policy and procedures; and\nc. Review and update the current incident response:\n1. Policy at least every 3 years and following {{ events - events that would require the current incident response policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Incident response policy and procedures address the controls in the IR family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of incident response policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to incident response policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "IR-2", + "title": "Incident Response Training", + "summary": "Incident Response Training\na. Provide incident response training to system users consistent with assigned roles and responsibilities:\n1. Within ten (10) days for privileged users, thirty (30) days for Incident Response roles of assuming an incident response role or responsibility or acquiring system access;\n2. When required by system changes; and\n3. at least annually thereafter; and\nb. Review and update incident response training content at least annually and following {{ events - events that initiate a review of the incident response training content are defined; }}.", + "guidance": "Incident response training is associated with the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail are included in such training. For example, users may only need to know who to call or how to recognize an incident; system administrators may require additional training on how to handle incidents; and incident responders may receive more specific training on forensics, data collection techniques, reporting, system recovery, and system restoration. Incident response training includes user training in identifying and reporting suspicious activities from external and internal sources. Incident response training for users may be provided as part of [AT-2] or [AT-3] . Events that may precipitate an update to incident response training content include, but are not limited to, incident response plan testing or response to an actual incident (lessons learned), assessment or audit findings, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "IR-3", + "title": "Incident Response Testing", + "summary": "Incident Response Testing\nTest the effectiveness of the incident response capability for the system functional, at least annually using the following tests: {{ tests - tests used to test the effectiveness of the incident response capability for the system are defined; }}.\nIR-3-2 Additional FedRAMP Requirements and Guidance Requirement: The service provider defines tests and/or exercises in accordance with NIST Special Publication 800-61 (as amended). Functional testing must occur prior to testing for initial authorization. Annual functional testing may be concurrent with required penetration tests (see CA-8). The service provider provides test plans to the JAB/AO annually. Test plans are approved and accepted by the JAB/AO prior to test commencing.\ncontrols IR-3(2) Coordination with Related Plans\nCoordinate incident response testing with organizational elements responsible for related plans.", + "guidance": "Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Incident response testing includes the use of checklists, walk-through or tabletop exercises, and simulations (parallel or full interrupt). Incident response testing can include a determination of the effects on organizational operations and assets and individuals due to incident response. The use of qualitative and quantitative data aids in determining the effectiveness of incident response processes." + }, + { + "ref": "IR-4", + "title": "Incident Handling", + "summary": "Incident Handling\na. Implement an incident handling capability for incidents that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery;\nb. Coordinate incident handling activities with contingency planning activities;\nc. Incorporate lessons learned from ongoing incident handling activities into incident response procedures, training, and testing, and implement the resulting changes accordingly; and\nd. Ensure the rigor, intensity, scope, and results of incident handling activities are comparable and predictable across the organization.\nIR-4 Additional FedRAMP Requirements and Guidance Requirement: The service provider ensures that individuals conducting incident handling meet personnel security requirements commensurate with the criticality/sensitivity of the information being processed, stored, and transmitted by the information system.\ncontrols IR-4(1) Automated Incident Handling Processes\nSupport the incident handling process using {{ automated mechanisms - automated mechanisms used to support the incident handling process are defined; }}.", + "guidance": "Organizations recognize that incident response capabilities are dependent on the capabilities of organizational systems and the mission and business processes being supported by those systems. Organizations consider incident response as part of the definition, design, and development of mission and business processes and systems. Incident-related information can be obtained from a variety of sources, including audit monitoring, physical access monitoring, and network monitoring; user or administrator reports; and reported supply chain events. An effective incident handling capability includes coordination among many organizational entities (e.g., mission or business owners, system owners, authorizing officials, human resources offices, physical security offices, personnel security offices, legal departments, risk executive [function], operations personnel, procurement offices). Suspected security incidents include the receipt of suspicious email communications that can contain malicious code. Suspected supply chain incidents include the insertion of counterfeit hardware or malicious code into organizational systems or system components. For federal agencies, an incident that involves personally identifiable information is considered a breach. A breach results in unauthorized disclosure, the loss of control, unauthorized acquisition, compromise, or a similar occurrence where a person other than an authorized user accesses or potentially accesses personally identifiable information or an authorized user accesses or potentially accesses such information for other than authorized purposes." + }, + { + "ref": "IR-5", + "title": "Incident Monitoring", + "summary": "Incident Monitoring\nTrack and document incidents.", + "guidance": "Documenting incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics as well as evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources, including network monitoring, incident reports, incident response teams, user complaints, supply chain partners, audit monitoring, physical access monitoring, and user and administrator reports. [IR-4] provides information on the types of incidents that are appropriate for monitoring." + }, + { + "ref": "IR-6", + "title": "Incident Reporting", + "summary": "Incident Reporting\na. Require personnel to report suspected incidents to the organizational incident response capability within US-CERT incident reporting timelines as specified in NIST Special Publication 800-61 (as amended) ; and\nb. Report incident information to {{ authorities - authorities to whom incident information is to be reported are defined; }}.\nIR-6 Additional FedRAMP Requirements and Guidance Requirement: Reports security incident information according to FedRAMP Incident Communications Procedure.\ncontrols IR-6(1) Automated Reporting\nReport incidents using {{ automated mechanisms - automated mechanisms used for reporting incidents are defined; }}.\nIR-6(3) Supply Chain Coordination\nProvide incident information to the provider of the product or service and other organizations involved in the supply chain or supply chain governance for systems or system components related to the incident.", + "guidance": "The types of incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Incident information can inform risk assessments, control effectiveness assessments, security requirements for acquisitions, and selection criteria for technology products." + }, + { + "ref": "IR-7", + "title": "Incident Response Assistance", + "summary": "Incident Response Assistance\nProvide an incident response support resource, integral to the organizational incident response capability, that offers advice and assistance to users of the system for the handling and reporting of incidents.\ncontrols IR-7(1) Automation Support for Availability of Information and Support\nIncrease the availability of incident response information and support using {{ automated mechanisms - automated mechanisms used to increase the availability of incident response information and support are defined; }}.", + "guidance": "Incident response support resources provided by organizations include help desks, assistance groups, automated ticketing systems to open and track incident response tickets, and access to forensics services or consumer redress services, when required." + }, + { + "ref": "IR-8", + "title": "Incident Response Plan", + "summary": "Incident Response Plan\na. Develop an incident response plan that:\n1. Provides the organization with a roadmap for implementing its incident response capability;\n2. Describes the structure and organization of the incident response capability;\n3. Provides a high-level approach for how the incident response capability fits into the overall organization;\n4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;\n5. Defines reportable incidents;\n6. Provides metrics for measuring the incident response capability within the organization;\n7. Defines the resources and management support needed to effectively maintain and mature an incident response capability;\n8. Addresses the sharing of incident information;\n9. Is reviewed and approved by {{ personnel or roles - personnel or roles that review and approve the incident response plan is/are identified; }} at least annually ; and\n10. Explicitly designates responsibility for incident response to {{ entities, personnel, or roles - entities, personnel, or roles with designated responsibility for incident response are defined; }}.\nb. Distribute copies of the incident response plan to see additional FedRAMP Requirements and Guidance;\nc. Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing;\nd. Communicate incident response plan changes to see additional FedRAMP Requirements and Guidance ; and\ne. Protect the incident response plan from unauthorized disclosure and modification.\nIR-8 Additional FedRAMP Requirements and Guidance (b) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.\n(d) Requirement: The service provider defines a list of incident response personnel (identified by name and/or by role) and organizational elements. The incident response list includes designated FedRAMP personnel.", + "guidance": "It is important that organizations develop and implement a coordinated approach to incident response. Organizational mission and business functions determine the structure of incident response capabilities. As part of the incident response capabilities, organizations consider the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain. For incidents involving personally identifiable information (i.e., breaches), include a process to determine whether notice to oversight organizations or affected individuals is appropriate and provide that notice accordingly." + }, + { + "ref": "IR-9", + "title": "Information Spillage Response", + "summary": "Information Spillage Response\nRespond to information spills by:\na. Assigning {{ personnel or roles - personnel or roles assigned the responsibility for responding to information spills is/are defined; }} with responsibility for responding to information spills;\nb. Identifying the specific information involved in the system contamination;\nc. Alerting {{ personnel or roles - personnel or roles to be alerted of the information spill using a method of communication not associated with the spill is/are defined; }} of the information spill using a method of communication not associated with the spill;\nd. Isolating the contaminated system or system component;\ne. Eradicating the information from the contaminated system or component;\nf. Identifying other systems or system components that may have been subsequently contaminated; and\ng. Performing the following additional actions: {{ actions - actions to be performed are defined; }}.\ncontrols IR-9(2) Training\nProvide information spillage response training at least annually.\nIR-9(3) Post-spill Operations\nImplement the following procedures to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions: {{ procedures - procedures to be implemented to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions are defined; }}.\nIR-9(4) Exposure to Unauthorized Personnel\nEmploy the following controls for personnel exposed to information not within assigned access authorizations: {{ controls - controls employed for personnel exposed to information not within assigned access authorizations are defined; }}.", + "guidance": "Information spillage refers to instances where information is placed on systems that are not authorized to process such information. Information spills occur when information that is thought to be a certain classification or impact level is transmitted to a system and subsequently is determined to be of a higher classification or impact level. At that point, corrective action is required. The nature of the response is based on the classification or impact level of the spilled information, the security capabilities of the system, the specific nature of the contaminated storage media, and the access authorizations of individuals with authorized access to the contaminated system. The methods used to communicate information about the spill after the fact do not involve methods directly associated with the actual spill to minimize the risk of further spreading the contamination before such contamination is isolated and eradicated." + } + ] + }, + { + "title": "Maintenance", + "controls": [ + { + "ref": "MA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} maintenance policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the maintenance policy and the associated maintenance controls;\nb. Designate an {{ official - an official to manage the maintenance policy and procedures is defined; }} to manage the development, documentation, and dissemination of the maintenance policy and procedures; and\nc. Review and update the current maintenance:\n1. Policy at least every 3 years and following {{ events - events that would require the current maintenance policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Maintenance policy and procedures address the controls in the MA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of maintenance policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to maintenance policy and procedures assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "MA-2", + "title": "Controlled Maintenance", + "summary": "Controlled Maintenance\na. Schedule, document, and review records of maintenance, repair, and replacement on system components in accordance with manufacturer or vendor specifications and/or organizational requirements;\nb. Approve and monitor all maintenance activities, whether performed on site or remotely and whether the system or system components are serviced on site or removed to another location;\nc. Require that {{ personnel or roles - personnel or roles required to explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance or repairs is/are defined; }} explicitly approve the removal of the system or system components from organizational facilities for off-site maintenance, repair, or replacement;\nd. Sanitize equipment to remove the following information from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement: {{ information - information to be removed from associated media prior to removal from organizational facilities for off-site maintenance, repair, or replacement is defined; }};\ne. Check all potentially impacted controls to verify that the controls are still functioning properly following maintenance, repair, or replacement actions; and\nf. Include the following information in organizational maintenance records: {{ information - information to be included in organizational maintenance records is defined; }}.", + "guidance": "Controlling system maintenance addresses the information security aspects of the system maintenance program and applies to all types of maintenance to system components conducted by local or nonlocal entities. Maintenance includes peripherals such as scanners, copiers, and printers. Information necessary for creating effective maintenance records includes the date and time of maintenance, a description of the maintenance performed, names of the individuals or group performing the maintenance, name of the escort, and system components or equipment that are removed or replaced. Organizations consider supply chain-related risks associated with replacement components for systems." + }, + { + "ref": "MA-3", + "title": "Maintenance Tools", + "summary": "Maintenance Tools\na. Approve, control, and monitor the use of system maintenance tools; and\nb. Review previously approved system maintenance tools at least annually.\ncontrols MA-3(1) Inspect Tools\nInspect the maintenance tools used by maintenance personnel for improper or unauthorized modifications.\nMA-3(2) Inspect Media\nCheck media containing diagnostic and test programs for malicious code before the media are used in the system.\nMA-3(3) Prevent Unauthorized Removal\nPrevent the removal of maintenance equipment containing organizational information by:\n(a) Verifying that there is no organizational information contained on the equipment;\n(b) Sanitizing or destroying the equipment;\n(c) Retaining the equipment within the facility; or\n(d) Obtaining an exemption from the information owner explicitly authorizing removal of the equipment from the facility.", + "guidance": "Approving, controlling, monitoring, and reviewing maintenance tools address security-related issues associated with maintenance tools that are not within system authorization boundaries and are used specifically for diagnostic and repair actions on organizational systems. Organizations have flexibility in determining roles for the approval of maintenance tools and how that approval is documented. A periodic review of maintenance tools facilitates the withdrawal of approval for outdated, unsupported, irrelevant, or no-longer-used tools. Maintenance tools can include hardware, software, and firmware items and may be pre-installed, brought in with maintenance personnel on media, cloud-based, or downloaded from a website. Such tools can be vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into systems. Maintenance tools can include hardware and software diagnostic test equipment and packet sniffers. The hardware and software components that support maintenance and are a part of the system (including the software implementing utilities such as \"ping,\" \"ls,\" \"ipconfig,\" or the hardware and software implementing the monitoring port of an Ethernet switch) are not addressed by maintenance tools." + }, + { + "ref": "MA-4", + "title": "Nonlocal Maintenance", + "summary": "Nonlocal Maintenance\na. Approve and monitor nonlocal maintenance and diagnostic activities;\nb. Allow the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the system;\nc. Employ strong authentication in the establishment of nonlocal maintenance and diagnostic sessions;\nd. Maintain records for nonlocal maintenance and diagnostic activities; and\ne. Terminate session and network connections when nonlocal maintenance is completed.", + "guidance": "Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network. Local maintenance and diagnostic activities are carried out by individuals who are physically present at the system location and not communicating across a network connection. Authentication techniques used to establish nonlocal maintenance and diagnostic sessions reflect the network access requirements in [IA-2] . Strong authentication requires authenticators that are resistant to replay attacks and employ multi-factor authentication. Strong authenticators include PKI where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing requirements in [MA-4] is accomplished, in part, by other controls. [SP 800-63B] provides additional guidance on strong authentication and authenticators." + }, + { + "ref": "MA-5", + "title": "Maintenance Personnel", + "summary": "Maintenance Personnel\na. Establish a process for maintenance personnel authorization and maintain a list of authorized maintenance organizations or personnel;\nb. Verify that non-escorted personnel performing maintenance on the system possess the required access authorizations; and\nc. Designate organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations.\ncontrols MA-5(1) Individuals Without Appropriate Access\n(a) Implement procedures for the use of maintenance personnel that lack appropriate security clearances or are not U.S. citizens, that include the following requirements:\n(1) Maintenance personnel who do not have needed access authorizations, clearances, or formal access approvals are escorted and supervised during the performance of maintenance and diagnostic activities on the system by approved organizational personnel who are fully cleared, have appropriate access authorizations, and are technically qualified; and\n(2) Prior to initiating maintenance or diagnostic activities by personnel who do not have needed access authorizations, clearances or formal access approvals, all volatile information storage components within the system are sanitized and all nonvolatile storage media are removed or physically disconnected from the system and secured; and\n(b) Develop and implement {{ alternate controls - alternate controls to be developed and implemented in the event that a system component cannot be sanitized, removed, or disconnected from the system are defined; }} in the event a system component cannot be sanitized, removed, or disconnected from the system.\nMA-5 (1) Additional FedRAMP Requirements and Guidance Requirement: Only MA-5 (1) (a) (1) is required by FedRAMP Moderate Baseline", + "guidance": "Maintenance personnel refers to individuals who perform hardware or software maintenance on organizational systems, while [PE-2] addresses physical access for individuals whose maintenance duties place them within the physical protection perimeter of the systems. Technical competence of supervising individuals relates to the maintenance performed on the systems, while having required access authorizations refers to maintenance on and near the systems. Individuals not previously identified as authorized maintenance personnel\u2014such as information technology manufacturers, vendors, systems integrators, and consultants\u2014may require privileged access to organizational systems, such as when they are required to conduct maintenance activities with little or no notice. Based on organizational assessments of risk, organizations may issue temporary credentials to these individuals. Temporary credentials may be for one-time use or for very limited time periods." + }, + { + "ref": "MA-6", + "title": "Timely Maintenance", + "summary": "Timely Maintenance\nObtain maintenance support and/or spare parts for {{ system components - system components for which maintenance support and/or spare parts are obtained are defined; }} within a timeframe to support advertised uptime and availability of failure.", + "guidance": "Organizations specify the system components that result in increased risk to organizational operations and assets, individuals, other organizations, or the Nation when the functionality provided by those components is not operational. Organizational actions to obtain maintenance support include having appropriate contracts in place." + } + ] + }, + { + "title": "Media Protection", + "controls": [ + { + "ref": "MP-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} media protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the media protection policy and the associated media protection controls;\nb. Designate an {{ official - an official to manage the media protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the media protection policy and procedures; and\nc. Review and update the current media protection:\n1. Policy at least every 3 years and following {{ events - events that would require the current media protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Media protection policy and procedures address the controls in the MP family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of media protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to media protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "MP-2", + "title": "Media Access", + "summary": "Media Access\nRestrict access to all types of digital and/or non-digital media containing sensitive information to {{ organization-defined personnel or roles }}.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Denying access to patient medical records in a community hospital unless the individuals seeking access to such records are authorized healthcare providers is an example of restricting access to non-digital media. Limiting access to the design specifications stored on compact discs in the media library to individuals on the system development team is an example of restricting access to digital media." + }, + { + "ref": "MP-3", + "title": "Media Marking", + "summary": "Media Marking\na. Mark system media indicating the distribution limitations, handling caveats, and applicable security markings (if any) of the information; and\nb. Exempt no removable media types from marking if the media remain within organization-defined security safeguards not applicable.\nMP-3 Additional FedRAMP Requirements and Guidance ", + "guidance": "Security marking refers to the application or use of human-readable security attributes. Digital media includes diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), flash drives, compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Controlled unclassified information is defined by the National Archives and Records Administration along with the appropriate safeguarding and dissemination requirements for such information and is codified in [32 CFR 2002] . Security markings are generally not required for media that contains information determined by organizations to be in the public domain or to be publicly releasable. Some organizations may require markings for public information indicating that the information is publicly releasable. System media marking reflects applicable laws, executive orders, directives, policies, regulations, standards, and guidelines." + }, + { + "ref": "MP-4", + "title": "Media Storage", + "summary": "Media Storage\na. Physically control and securely store all types of digital and non-digital media with sensitive information within see additional FedRAMP requirements and guidance ; and\nb. Protect system media types defined in MP-4a until the media are destroyed or sanitized using approved equipment, techniques, and procedures.\nMP-4 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider defines controlled areas within facilities where the information and information system reside.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state, magnetic), compact discs, and digital versatile discs. Non-digital media includes paper and microfilm. Physically controlling stored media includes conducting inventories, ensuring procedures are in place to allow individuals to check out and return media to the library, and maintaining accountability for stored media. Secure storage includes a locked drawer, desk, or cabinet or a controlled media library. The type of media storage is commensurate with the security category or classification of the information on the media. Controlled areas are spaces that provide physical and procedural controls to meet the requirements established for protecting information and systems. Fewer controls may be needed for media that contains information determined to be in the public domain, publicly releasable, or have limited adverse impacts on organizations, operations, or individuals if accessed by other than authorized personnel. In these situations, physical access controls provide adequate protection." + }, + { + "ref": "MP-5", + "title": "Media Transport", + "summary": "Media Transport\na. Protect and control all media with sensitive information during transport outside of controlled areas using prior to leaving secure/controlled environment: for digital media, encryption in compliance with Federal requirements and utilizes FIPS validated or NSA approved cryptography (see SC-13.); for non-digital media, secured in locked container;\nb. Maintain accountability for system media during transport outside of controlled areas;\nc. Document activities associated with the transport of system media; and\nd. Restrict the activities associated with the transport of system media to authorized personnel.\nMP-5 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider defines security measures to protect digital and non-digital media in transport. The security measures are approved and accepted by the JAB/AO.", + "guidance": "System media includes digital and non-digital media. Digital media includes flash drives, diskettes, magnetic tapes, external or removable hard disk drives (e.g., solid state and magnetic), compact discs, and digital versatile discs. Non-digital media includes microfilm and paper. Controlled areas are spaces for which organizations provide physical or procedural controls to meet requirements established for protecting information and systems. Controls to protect media during transport include cryptography and locked containers. Cryptographic mechanisms can provide confidentiality and integrity protections depending on the mechanisms implemented. Activities associated with media transport include releasing media for transport, ensuring that media enters the appropriate transport processes, and the actual transport. Authorized transport and courier personnel may include individuals external to the organization. Maintaining accountability of media during transport includes restricting transport activities to authorized personnel and tracking and/or obtaining records of transport activities as the media moves through the transportation system to prevent and detect loss, destruction, or tampering. Organizations establish documentation requirements for activities associated with the transport of system media in accordance with organizational assessments of risk. Organizations maintain the flexibility to define record-keeping methods for the different types of media transport as part of a system of transport-related records." + }, + { + "ref": "MP-6", + "title": "Media Sanitization", + "summary": "Media Sanitization\na. Sanitize techniques and procedures IAW NIST SP 800-88 Section 4: Reuse and Disposal of Storage Media and Hardware prior to disposal, release out of organizational control, or release for reuse using {{ organization-defined sanitization techniques and procedures }} ; and\nb. Employ sanitization mechanisms with the strength and integrity commensurate with the security category or classification of the information.", + "guidance": "Media sanitization applies to all digital and non-digital system media subject to disposal or reuse, whether or not the media is considered removable. Examples include digital media in scanners, copiers, printers, notebook computers, workstations, network components, mobile devices, and non-digital media (e.g., paper and microfilm). The sanitization process removes information from system media such that the information cannot be retrieved or reconstructed. Sanitization techniques\u2014including clearing, purging, cryptographic erase, de-identification of personally identifiable information, and destruction\u2014prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal. Organizations determine the appropriate sanitization methods, recognizing that destruction is sometimes necessary when other methods cannot be applied to media requiring sanitization. Organizations use discretion on the employment of approved sanitization techniques and procedures for media that contains information deemed to be in the public domain or publicly releasable or information deemed to have no adverse impact on organizations or individuals if released for reuse or disposal. Sanitization of non-digital media includes destruction, removing a classified appendix from an otherwise unclassified document, or redacting selected sections or words from a document by obscuring the redacted sections or words in a manner equivalent in effectiveness to removing them from the document. NSA standards and policies control the sanitization process for media that contains classified information. NARA policies control the sanitization process for controlled unclassified information." + }, + { + "ref": "MP-7", + "title": "Media Use", + "summary": "Media Use\na. {{ restrict OR prohibit }} the use of {{ types of system media - types of system media to be restricted or prohibited from use on systems or system components are defined; }} on {{ systems or system components - systems or system components on which the use of specific types of system media to be restricted or prohibited are defined; }} using {{ controls - controls to restrict or prohibit the use of specific types of system media on systems or system components are defined; }} ; and\nb. Prohibit the use of portable storage devices in organizational systems when such devices have no identifiable owner.", + "guidance": "System media includes both digital and non-digital media. Digital media includes diskettes, magnetic tapes, flash drives, compact discs, digital versatile discs, and removable hard disk drives. Non-digital media includes paper and microfilm. Media use protections also apply to mobile devices with information storage capabilities. In contrast to [MP-2] , which restricts user access to media, MP-7 restricts the use of certain types of media on systems, for example, restricting or prohibiting the use of flash drives or external hard disk drives. Organizations use technical and nontechnical controls to restrict the use of system media. Organizations may restrict the use of portable storage devices, for example, by using physical cages on workstations to prohibit access to certain external ports or disabling or removing the ability to insert, read, or write to such devices. Organizations may also limit the use of portable storage devices to only approved devices, including devices provided by the organization, devices provided by other approved organizations, and devices that are not personally owned. Finally, organizations may restrict the use of portable storage devices based on the type of device, such as by prohibiting the use of writeable, portable storage devices and implementing this restriction by disabling or removing the capability to write to such devices. Requiring identifiable owners for storage devices reduces the risk of using such devices by allowing organizations to assign responsibility for addressing known vulnerabilities in the devices." + } + ] + }, + { + "title": "Physical and Environmental Protection", + "controls": [ + { + "ref": "PE-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} physical and environmental protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the physical and environmental protection policy and the associated physical and environmental protection controls;\nb. Designate an {{ official - an official to manage the physical and environmental protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the physical and environmental protection policy and procedures; and\nc. Review and update the current physical and environmental protection:\n1. Policy at least every 3 years and following {{ events - events that would require the current physical and environmental protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Physical and environmental protection policy and procedures address the controls in the PE family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of physical and environmental protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to physical and environmental protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PE-2", + "title": "Physical Access Authorizations", + "summary": "Physical Access Authorizations\na. Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides;\nb. Issue authorization credentials for facility access;\nc. Review the access list detailing authorized facility access by individuals at least annually ; and\nd. Remove individuals from the facility access list when access is no longer required.", + "guidance": "Physical access authorizations apply to employees and visitors. Individuals with permanent physical access authorization credentials are not considered visitors. Authorization credentials include ID badges, identification cards, and smart cards. Organizations determine the strength of authorization credentials needed consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Physical access authorizations may not be necessary to access certain areas within facilities that are designated as publicly accessible." + }, + { + "ref": "PE-3", + "title": "Physical Access Control", + "summary": "Physical Access Control\na. Enforce physical access authorizations at {{ entry and exit points - entry and exit points to the facility in which the system resides are defined; }} by:\n1. Verifying individual access authorizations before granting access to the facility; and\n2. Controlling ingress and egress to the facility using CSP defined physical access control systems/devices AND guards;\nb. Maintain physical access audit logs for {{ entry or exit points - entry or exit points for which physical access logs are maintained are defined; }};\nc. Control access to areas within the facility designated as publicly accessible by implementing the following controls: {{ physical access controls - physical access controls to control access to areas within the facility designated as publicly accessible are defined; }};\nd. Escort visitors and control visitor activity in all circumstances within restricted access area where the information system resides;\ne. Secure keys, combinations, and other physical access devices;\nf. Inventory {{ physical access devices - physical access devices to be inventoried are defined; }} every at least annually ; and\ng. Change combinations and keys at least annually or earlier as required by a security relevant event. and/or when keys are lost, combinations are compromised, or when individuals possessing the keys or combinations are transferred or terminated.", + "guidance": "Physical access control applies to employees and visitors. Individuals with permanent physical access authorizations are not considered visitors. Physical access controls for publicly accessible areas may include physical access control logs/records, guards, or physical access devices and barriers to prevent movement from publicly accessible areas to non-public areas. Organizations determine the types of guards needed, including professional security staff, system users, or administrative staff. Physical access devices include keys, locks, combinations, biometric readers, and card readers. Physical access control systems comply with applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Organizations have flexibility in the types of audit logs employed. Audit logs can be procedural, automated, or some combination thereof. Physical access points can include facility access points, interior access points to systems that require supplemental access controls, or both. Components of systems may be in areas designated as publicly accessible with organizations controlling access to the components." + }, + { + "ref": "PE-4", + "title": "Access Control for Transmission", + "summary": "Access Control for Transmission\nControl physical access to {{ system distribution and transmission lines - system distribution and transmission lines requiring physical access controls are defined; }} within organizational facilities using {{ security controls - security controls to be implemented to control physical access to system distribution and transmission lines within the organizational facility are defined; }}.", + "guidance": "Security controls applied to system distribution and transmission lines prevent accidental damage, disruption, and physical tampering. Such controls may also be necessary to prevent eavesdropping or modification of unencrypted transmissions. Security controls used to control physical access to system distribution and transmission lines include disconnected or locked spare jacks, locked wiring closets, protection of cabling by conduit or cable trays, and wiretapping sensors." + }, + { + "ref": "PE-5", + "title": "Access Control for Output Devices", + "summary": "Access Control for Output Devices\nControl physical access to output from {{ output devices - output devices that require physical access control to output are defined; }} to prevent unauthorized individuals from obtaining the output.", + "guidance": "Controlling physical access to output devices includes placing output devices in locked rooms or other secured areas with keypad or card reader access controls and allowing access to authorized individuals only, placing output devices in locations that can be monitored by personnel, installing monitor or screen filters, and using headphones. Examples of output devices include monitors, printers, scanners, audio devices, facsimile machines, and copiers." + }, + { + "ref": "PE-6", + "title": "Monitoring Physical Access", + "summary": "Monitoring Physical Access\na. Monitor physical access to the facility where the system resides to detect and respond to physical security incidents;\nb. Review physical access logs at least monthly and upon occurrence of {{ events - events or potential indication of events requiring physical access logs to be reviewed are defined; }} ; and\nc. Coordinate results of reviews and investigations with the organizational incident response capability.\ncontrols PE-6(1) Intrusion Alarms and Surveillance Equipment\nMonitor physical access to the facility where the system resides using physical intrusion alarms and surveillance equipment.", + "guidance": "Physical access monitoring includes publicly accessible areas within organizational facilities. Examples of physical access monitoring include the employment of guards, video surveillance equipment (i.e., cameras), and sensor devices. Reviewing physical access logs can help identify suspicious activity, anomalous events, or potential threats. The reviews can be supported by audit logging controls, such as [AU-2] , if the access logs are part of an automated system. Organizational incident response capabilities include investigations of physical security incidents and responses to the incidents. Incidents include security violations or suspicious physical access activities. Suspicious physical access activities include accesses outside of normal work hours, repeated accesses to areas not normally accessed, accesses for unusual lengths of time, and out-of-sequence accesses." + }, + { + "ref": "PE-8", + "title": "Visitor Access Records", + "summary": "Visitor Access Records\na. Maintain visitor access records to the facility where the system resides for for a minimum of one (1) year;\nb. Review visitor access records at least monthly ; and\nc. Report anomalies in visitor access records to {{ personnel - personnel to whom visitor access records anomalies are reported to is/are defined; }}.", + "guidance": "Visitor access records include the names and organizations of individuals visiting, visitor signatures, forms of identification, dates of access, entry and departure times, purpose of visits, and the names and organizations of individuals visited. Access record reviews determine if access authorizations are current and are still required to support organizational mission and business functions. Access records are not required for publicly accessible areas." + }, + { + "ref": "PE-9", + "title": "Power Equipment and Cabling", + "summary": "Power Equipment and Cabling\nProtect power equipment and power cabling for the system from damage and destruction.", + "guidance": "Organizations determine the types of protection necessary for the power equipment and cabling employed at different locations that are both internal and external to organizational facilities and environments of operation. Types of power equipment and cabling include internal cabling and uninterruptable power sources in offices or data centers, generators and power cabling outside of buildings, and power sources for self-contained components such as satellites, vehicles, and other deployable systems." + }, + { + "ref": "PE-10", + "title": "Emergency Shutoff", + "summary": "Emergency Shutoff\na. Provide the capability of shutting off power to {{ system or individual system components - system or individual system components that require the capability to shut off power in emergency situations is/are defined; }} in emergency situations;\nb. Place emergency shutoff switches or devices in near more than one egress point of the IT area and ensures it is labeled and protected by a cover to prevent accidental shut-off to facilitate access for authorized personnel; and\nc. Protect emergency power shutoff capability from unauthorized activation.", + "guidance": "Emergency power shutoff primarily applies to organizational facilities that contain concentrations of system resources, including data centers, mainframe computer rooms, server rooms, and areas with computer-controlled machinery." + }, + { + "ref": "PE-11", + "title": "Emergency Power", + "summary": "Emergency Power\nProvide an uninterruptible power supply to facilitate {{ an orderly shutdown of the system OR transition of the system to long-term alternate power }} in the event of a primary power source loss.", + "guidance": "An uninterruptible power supply (UPS) is an electrical system or mechanism that provides emergency power when there is a failure of the main power source. A UPS is typically used to protect computers, data centers, telecommunication equipment, or other electrical equipment where an unexpected power disruption could cause injuries, fatalities, serious mission or business disruption, or loss of data or information. A UPS differs from an emergency power system or backup generator in that the UPS provides near-instantaneous protection from unanticipated power interruptions from the main power source by providing energy stored in batteries, supercapacitors, or flywheels. The battery duration of a UPS is relatively short but provides sufficient time to start a standby power source, such as a backup generator, or properly shut down the system." + }, + { + "ref": "PE-12", + "title": "Emergency Lighting", + "summary": "Emergency Lighting\nEmploy and maintain automatic emergency lighting for the system that activates in the event of a power outage or disruption and that covers emergency exits and evacuation routes within the facility.", + "guidance": "The provision of emergency lighting applies primarily to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Emergency lighting provisions for the system are described in the contingency plan for the organization. If emergency lighting for the system fails or cannot be provided, organizations consider alternate processing sites for power-related contingencies." + }, + { + "ref": "PE-13", + "title": "Fire Protection", + "summary": "Fire Protection\nEmploy and maintain fire detection and suppression systems that are supported by an independent energy source.\ncontrols PE-13(1) Detection Systems \u2014 Automatic Activation and Notification\nEmploy fire detection systems that activate automatically and notify service provider building maintenance/physical security personnel and service provider emergency responders with incident response responsibilities in the event of a fire.\nPE-13(2) Suppression Systems \u2014 Automatic Activation and Notification\n(a) Employ fire suppression systems that activate automatically and notify {{ personnel or roles - personnel or roles to be notified in the event of a fire is/are defined; }} and {{ emergency responders - emergency responders to be notified in the event of a fire are defined; }} ; and\n(b) Employ an automatic fire suppression capability when the facility is not staffed on a continuous basis.", + "guidance": "The provision of fire detection and suppression systems applies primarily to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Fire detection and suppression systems that may require an independent energy source include sprinkler systems and smoke detectors. An independent energy source is an energy source, such as a microgrid, that is separate, or can be separated, from the energy sources providing power for the other parts of the facility." + }, + { + "ref": "PE-14", + "title": "Environmental Controls", + "summary": "Environmental Controls\na. Maintain consistent with American Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) document entitled Thermal Guidelines for Data Processing Environments levels within the facility where the system resides at {{ acceptable levels - acceptable levels for environmental controls are defined; }} ; and\nb. Monitor environmental control levels continuously.\nPE-14 Additional FedRAMP Requirements and Guidance (a) Requirement: The service provider measures temperature at server inlets and humidity levels by dew point.", + "guidance": "The provision of environmental controls applies primarily to organizational facilities that contain concentrations of system resources (e.g., data centers, mainframe computer rooms, and server rooms). Insufficient environmental controls, especially in very harsh environments, can have a significant adverse impact on the availability of systems and system components that are needed to support organizational mission and business functions." + }, + { + "ref": "PE-15", + "title": "Water Damage Protection", + "summary": "Water Damage Protection\nProtect the system from damage resulting from water leakage by providing master shutoff or isolation valves that are accessible, working properly, and known to key personnel.", + "guidance": "The provision of water damage protection primarily applies to organizational facilities that contain concentrations of system resources, including data centers, server rooms, and mainframe computer rooms. Isolation valves can be employed in addition to or in lieu of master shutoff valves to shut off water supplies in specific areas of concern without affecting entire organizations." + }, + { + "ref": "PE-16", + "title": "Delivery and Removal", + "summary": "Delivery and Removal\na. Authorize and control all information system components entering and exiting the facility; and\nb. Maintain records of the system components.", + "guidance": "Enforcing authorizations for entry and exit of system components may require restricting access to delivery areas and isolating the areas from the system and media libraries." + }, + { + "ref": "PE-17", + "title": "Alternate Work Site", + "summary": "Alternate Work Site\na. Determine and document the {{ alternate work sites - alternate work sites allowed for use by employees are defined; }} allowed for use by employees;\nb. Employ the following controls at alternate work sites: {{ controls - controls to be employed at alternate work sites are defined; }};\nc. Assess the effectiveness of controls at alternate work sites; and\nd. Provide a means for employees to communicate with information security and privacy personnel in case of incidents.", + "guidance": "Alternate work sites include government facilities or the private residences of employees. While distinct from alternative processing sites, alternate work sites can provide readily available alternate locations during contingency operations. Organizations can define different sets of controls for specific alternate work sites or types of sites depending on the work-related activities conducted at the sites. Implementing and assessing the effectiveness of organization-defined controls and providing a means to communicate incidents at alternate work sites supports the contingency planning activities of organizations." + } + ] + }, + { + "title": "Planning", + "controls": [ + { + "ref": "PL-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} planning policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the planning policy and the associated planning controls;\nb. Designate an {{ official - an official to manage the planning policy and procedures is defined; }} to manage the development, documentation, and dissemination of the planning policy and procedures; and\nc. Review and update the current planning:\n1. Policy at least every 3 years and following {{ events - events that would require the current planning policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Planning policy and procedures for the controls in the PL family implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to planning policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PL-2", + "title": "System Security and Privacy Plans", + "summary": "System Security and Privacy Plans\na. Develop security and privacy plans for the system that:\n1. Are consistent with the organization\u2019s enterprise architecture;\n2. Explicitly define the constituent system components;\n3. Describe the operational context of the system in terms of mission and business processes;\n4. Identify the individuals that fulfill system roles and responsibilities;\n5. Identify the information types processed, stored, and transmitted by the system;\n6. Provide the security categorization of the system, including supporting rationale;\n7. Describe any specific threats to the system that are of concern to the organization;\n8. Provide the results of a privacy risk assessment for systems processing personally identifiable information;\n9. Describe the operational environment for the system and any dependencies on or connections to other systems or system components;\n10. Provide an overview of the security and privacy requirements for the system;\n11. Identify any relevant control baselines or overlays, if applicable;\n12. Describe the controls in place or planned for meeting the security and privacy requirements, including a rationale for any tailoring decisions;\n13. Include risk determinations for security and privacy architecture and design decisions;\n14. Include security- and privacy-related activities affecting the system that require planning and coordination with to include chief privacy and ISSO and/or similar role or designees ; and\n15. Are reviewed and approved by the authorizing official or designated representative prior to plan implementation.\nb. Distribute copies of the plans and communicate subsequent changes to the plans to to include chief privacy and ISSO and/or similar role;\nc. Review the plans at least annually;\nd. Update the plans to address changes to the system and environment of operation or problems identified during plan implementation or control assessments; and\ne. Protect the plans from unauthorized disclosure and modification.", + "guidance": "System security and privacy plans are scoped to the system and system components within the defined authorization boundary and contain an overview of the security and privacy requirements for the system and the controls selected to satisfy the requirements. The plans describe the intended application of each selected control in the context of the system with a sufficient level of detail to correctly implement the control and to subsequently assess the effectiveness of the control. The control documentation describes how system-specific and hybrid controls are implemented and the plans and expectations regarding the functionality of the system. System security and privacy plans can also be used in the design and development of systems in support of life cycle-based security and privacy engineering processes. System security and privacy plans are living documents that are updated and adapted throughout the system development life cycle (e.g., during capability determination, analysis of alternatives, requests for proposal, and design reviews). [Section 2.1] describes the different types of requirements that are relevant to organizations during the system development life cycle and the relationship between requirements and controls.\n\nOrganizations may develop a single, integrated security and privacy plan or maintain separate plans. Security and privacy plans relate security and privacy requirements to a set of controls and control enhancements. The plans describe how the controls and control enhancements meet the security and privacy requirements but do not provide detailed, technical descriptions of the design or implementation of the controls and control enhancements. Security and privacy plans contain sufficient information (including specifications of control parameter values for selection and assignment operations explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented.\n\nSecurity and privacy plans need not be single documents. The plans can be a collection of various documents, including documents that already exist. Effective security and privacy plans make extensive use of references to policies, procedures, and additional documents, including design and implementation specifications where more detailed information can be obtained. The use of references helps reduce the documentation associated with security and privacy programs and maintains the security- and privacy-related information in other established management and operational areas, including enterprise architecture, system development life cycle, systems engineering, and acquisition. Security and privacy plans need not contain detailed contingency plan or incident response plan information but can instead provide\u2014explicitly or by reference\u2014sufficient information to define what needs to be accomplished by those plans.\n\nSecurity- and privacy-related activities that may require coordination and planning with other individuals or groups within the organization include assessments, audits, inspections, hardware and software maintenance, acquisition and supply chain risk management, patch management, and contingency plan testing. Planning and coordination include emergency and nonemergency (i.e., planned or non-urgent unplanned) situations. The process defined by organizations to plan and coordinate security- and privacy-related activities can also be included in other documents, as appropriate." + }, + { + "ref": "PL-4", + "title": "Rules of Behavior", + "summary": "Rules of Behavior\na. Establish and provide to individuals requiring access to the system, the rules that describe their responsibilities and expected behavior for information and system usage, security, and privacy;\nb. Receive a documented acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the system;\nc. Review and update the rules of behavior at least every 3 years ; and\nd. Require individuals who have acknowledged a previous version of the rules of behavior to read and re-acknowledge at least annually and when the rules are revised or changed.\ncontrols PL-4(1) Social Media and External Site/Application Usage Restrictions\nInclude in the rules of behavior, restrictions on:\n(a) Use of social media, social networking sites, and external sites/applications;\n(b) Posting organizational information on public websites; and\n(c) Use of organization-provided identifiers (e.g., email addresses) and authentication secrets (e.g., passwords) for creating accounts on external sites/applications.", + "guidance": "Rules of behavior represent a type of access agreement for organizational users. Other types of access agreements include nondisclosure agreements, conflict-of-interest agreements, and acceptable use agreements (see [PS-6] ). Organizations consider rules of behavior based on individual user roles and responsibilities and differentiate between rules that apply to privileged users and rules that apply to general users. Establishing rules of behavior for some types of non-organizational users, including individuals who receive information from federal systems, is often not feasible given the large number of such users and the limited nature of their interactions with the systems. Rules of behavior for organizational and non-organizational users can also be established in [AC-8] . The related controls section provides a list of controls that are relevant to organizational rules of behavior. [PL-4b] , the documented acknowledgment portion of the control, may be satisfied by the literacy training and awareness and role-based training programs conducted by organizations if such training includes rules of behavior. Documented acknowledgements for rules of behavior include electronic or physical signatures and electronic agreement check boxes or radio buttons." + }, + { + "ref": "PL-8", + "title": "Security and Privacy Architectures", + "summary": "Security and Privacy Architectures\na. Develop security and privacy architectures for the system that:\n1. Describe the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information;\n2. Describe the requirements and approach to be taken for processing personally identifiable information to minimize privacy risk to individuals;\n3. Describe how the architectures are integrated into and support the enterprise architecture; and\n4. Describe any assumptions about, and dependencies on, external systems and services;\nb. Review and update the architectures at least annually and when a significant change occurs to reflect changes in the enterprise architecture; and\nc. Reflect planned architecture changes in security and privacy plans, Concept of Operations (CONOPS), criticality analysis, organizational procedures, and procurements and acquisitions.\nPL-8 Additional FedRAMP Requirements and Guidance ", + "guidance": "The security and privacy architectures at the system level are consistent with the organization-wide security and privacy architectures described in [PM-7] , which are integral to and developed as part of the enterprise architecture. The architectures include an architectural description, the allocation of security and privacy functionality (including controls), security- and privacy-related information for external interfaces, information being exchanged across the interfaces, and the protection mechanisms associated with each interface. The architectures can also include other information, such as user roles and the access privileges assigned to each role; security and privacy requirements; types of information processed, stored, and transmitted by the system; supply chain risk management requirements; restoration priorities of information and system services; and other protection needs.\n\n [SP 800-160-1] provides guidance on the use of security architectures as part of the system development life cycle process. [OMB M-19-03] requires the use of the systems security engineering concepts described in [SP 800-160-1] for high value assets. Security and privacy architectures are reviewed and updated throughout the system development life cycle, from analysis of alternatives through review of the proposed architecture in the RFP responses to the design reviews before and during implementation (e.g., during preliminary design reviews and critical design reviews).\n\nIn today\u2019s modern computing architectures, it is becoming less common for organizations to control all information resources. There may be key dependencies on external information services and service providers. Describing such dependencies in the security and privacy architectures is necessary for developing a comprehensive mission and business protection strategy. Establishing, developing, documenting, and maintaining under configuration control a baseline configuration for organizational systems is critical to implementing and maintaining effective architectures. The development of the architectures is coordinated with the senior agency information security officer and the senior agency official for privacy to ensure that the controls needed to support security and privacy requirements are identified and effectively implemented. In many circumstances, there may be no distinction between the security and privacy architecture for a system. In other circumstances, security objectives may be adequately satisfied, but privacy objectives may only be partially satisfied by the security requirements. In these cases, consideration of the privacy requirements needed to achieve satisfaction will result in a distinct privacy architecture. The documentation, however, may simply reflect the combined architectures.\n\n [PL-8] is primarily directed at organizations to ensure that architectures are developed for the system and, moreover, that the architectures are integrated with or tightly coupled to the enterprise architecture. In contrast, [SA-17] is primarily directed at the external information technology product and system developers and integrators. [SA-17] , which is complementary to [PL-8] , is selected when organizations outsource the development of systems or components to external entities and when there is a need to demonstrate consistency with the organization\u2019s enterprise architecture and security and privacy architectures." + }, + { + "ref": "PL-10", + "title": "Baseline Selection", + "summary": "Baseline Selection\nSelect a control baseline for the system.\nPL-10 Additional FedRAMP Requirements and Guidance Requirement: Select the appropriate FedRAMP Baseline", + "guidance": "Control baselines are predefined sets of controls specifically assembled to address the protection needs of a group, organization, or community of interest. Controls are chosen for baselines to either satisfy mandates imposed by laws, executive orders, directives, regulations, policies, standards, and guidelines or address threats common to all users of the baseline under the assumptions specific to the baseline. Baselines represent a starting point for the protection of individuals\u2019 privacy, information, and information systems with subsequent tailoring actions to manage risk in accordance with mission, business, or other constraints (see [PL-11] ). Federal control baselines are provided in [SP 800-53B] . The selection of a control baseline is determined by the needs of stakeholders. Stakeholder needs consider mission and business requirements as well as mandates imposed by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. For example, the control baselines in [SP 800-53B] are based on the requirements from [FISMA] and [PRIVACT] . The requirements, along with the NIST standards and guidelines implementing the legislation, direct organizations to select one of the control baselines after the reviewing the information types and the information that is processed, stored, and transmitted on the system; analyzing the potential adverse impact of the loss or compromise of the information or system on the organization\u2019s operations and assets, individuals, other organizations, or the Nation; and considering the results from system and organizational risk assessments. [CNSSI 1253] provides guidance on control baselines for national security systems." + }, + { + "ref": "PL-11", + "title": "Baseline Tailoring", + "summary": "Baseline Tailoring\nTailor the selected control baseline by applying specified tailoring actions.", + "guidance": "The concept of tailoring allows organizations to specialize or customize a set of baseline controls by applying a defined set of tailoring actions. Tailoring actions facilitate such specialization and customization by allowing organizations to develop security and privacy plans that reflect their specific mission and business functions, the environments where their systems operate, the threats and vulnerabilities that can affect their systems, and any other conditions or situations that can impact their mission or business success. Tailoring guidance is provided in [SP 800-53B] . Tailoring a control baseline is accomplished by identifying and designating common controls, applying scoping considerations, selecting compensating controls, assigning values to control parameters, supplementing the control baseline with additional controls as needed, and providing information for control implementation. The general tailoring actions in [SP 800-53B] can be supplemented with additional actions based on the needs of organizations. Tailoring actions can be applied to the baselines in [SP 800-53B] in accordance with the security and privacy requirements from [FISMA], [PRIVACT] , and [OMB A-130] . Alternatively, other communities of interest adopting different control baselines can apply the tailoring actions in [SP 800-53B] to specialize or customize the controls that represent the specific needs and concerns of those entities." + } + ] + }, + { + "title": "Personnel Security", + "controls": [ + { + "ref": "PS-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} personnel security policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the personnel security policy and the associated personnel security controls;\nb. Designate an {{ official - an official to manage the personnel security policy and procedures is defined; }} to manage the development, documentation, and dissemination of the personnel security policy and procedures; and\nc. Review and update the current personnel security:\n1. Policy at least every 3 years and following {{ events - events that would require the current personnel security policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Personnel security policy and procedures for the controls in the PS family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to personnel security policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "PS-2", + "title": "Position Risk Designation", + "summary": "Position Risk Designation\na. Assign a risk designation to all organizational positions;\nb. Establish screening criteria for individuals filling those positions; and\nc. Review and update position risk designations at least every three years.", + "guidance": "Position risk designations reflect Office of Personnel Management (OPM) policy and guidance. Proper position designation is the foundation of an effective and consistent suitability and personnel security program. The Position Designation System (PDS) assesses the duties and responsibilities of a position to determine the degree of potential damage to the efficiency or integrity of the service due to misconduct of an incumbent of a position and establishes the risk level of that position. The PDS assessment also determines if the duties and responsibilities of the position present the potential for position incumbents to bring about a material adverse effect on national security and the degree of that potential effect, which establishes the sensitivity level of a position. The results of the assessment determine what level of investigation is conducted for a position. Risk designations can guide and inform the types of authorizations that individuals receive when accessing organizational information and information systems. Position screening criteria include explicit information security role appointment requirements. Parts 1400 and 731 of Title 5, Code of Federal Regulations, establish the requirements for organizations to evaluate relevant covered positions for a position sensitivity and position risk designation commensurate with the duties and responsibilities of those positions." + }, + { + "ref": "PS-3", + "title": "Personnel Screening", + "summary": "Personnel Screening\na. Screen individuals prior to authorizing access to the system; and\nb. Rescreen individuals in accordance with for national security clearances; a reinvestigation is required during the fifth (5th) year for top secret security clearance, the tenth (10th) year for secret security clearance, and fifteenth (15th) year for confidential security clearance.\n\nFor moderate risk law enforcement and high impact public trust level, a reinvestigation is required during the fifth (5th) year. There is no reinvestigation for other moderate risk positions or any low risk positions.\ncontrols PS-3(3) Information Requiring Special Protective Measures\nVerify that individuals accessing a system processing, storing, or transmitting information requiring special protection:\n(a) Have valid access authorizations that are demonstrated by assigned official government duties; and\n(b) Satisfy personnel screening criteria \u2013 as required by specific information.", + "guidance": "Personnel screening and rescreening activities reflect applicable laws, executive orders, directives, regulations, policies, standards, guidelines, and specific criteria established for the risk designations of assigned positions. Examples of personnel screening include background investigations and agency checks. Organizations may define different rescreening conditions and frequencies for personnel accessing systems based on types of information processed, stored, or transmitted by the systems." + }, + { + "ref": "PS-4", + "title": "Personnel Termination", + "summary": "Personnel Termination\nUpon termination of individual employment:\na. Disable system access within four (4) hours;\nb. Terminate or revoke any authenticators and credentials associated with the individual;\nc. Conduct exit interviews that include a discussion of {{ information security topics - information security topics to be discussed when conducting exit interviews are defined; }};\nd. Retrieve all security-related organizational system-related property; and\ne. Retain access to organizational information and systems formerly controlled by terminated individual.", + "guidance": "System property includes hardware authentication tokens, system administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that terminated individuals understand the security constraints imposed by being former employees and that proper accountability is achieved for system-related property. Security topics at exit interviews include reminding individuals of nondisclosure agreements and potential limitations on future employment. Exit interviews may not always be possible for some individuals, including in cases related to the unavailability of supervisors, illnesses, or job abandonment. Exit interviews are important for individuals with security clearances. The timely execution of termination actions is essential for individuals who have been terminated for cause. In certain situations, organizations consider disabling the system accounts of individuals who are being terminated prior to the individuals being notified." + }, + { + "ref": "PS-5", + "title": "Personnel Transfer", + "summary": "Personnel Transfer\na. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization;\nb. Initiate {{ transfer or reassignment actions - transfer or reassignment actions to be initiated following transfer or reassignment are defined; }} within twenty-four (24) hours;\nc. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and\nd. Notify including access control personnel responsible for the system within twenty-four (24) hours.", + "guidance": "Personnel transfer applies when reassignments or transfers of individuals are permanent or of such extended duration as to make the actions warranted. Organizations define actions appropriate for the types of reassignments or transfers, whether permanent or extended. Actions that may be required for personnel transfers or reassignments to other positions within organizations include returning old and issuing new keys, identification cards, and building passes; closing system accounts and establishing new accounts; changing system access authorizations (i.e., privileges); and providing for access to official records to which individuals had access at previous work locations and in previous system accounts." + }, + { + "ref": "PS-6", + "title": "Access Agreements", + "summary": "Access Agreements\na. Develop and document access agreements for organizational systems;\nb. Review and update the access agreements at least annually ; and\nc. Verify that individuals requiring access to organizational information and systems:\n1. Sign appropriate access agreements prior to being granted access; and\n2. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated or at least annually and any time there is a change to the user's level of access.", + "guidance": "Access agreements include nondisclosure agreements, acceptable use agreements, rules of behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that individuals have read, understand, and agree to abide by the constraints associated with organizational systems to which access is authorized. Organizations can use electronic signatures to acknowledge access agreements unless specifically prohibited by organizational policy." + }, + { + "ref": "PS-7", + "title": "External Personnel Security", + "summary": "External Personnel Security\na. Establish personnel security requirements, including security roles and responsibilities for external providers;\nb. Require external providers to comply with personnel security policies and procedures established by the organization;\nc. Document personnel security requirements;\nd. Require external providers to notify including access control personnel responsible for the system and/or facilities, as appropriate of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within within twenty-four (24) hours ; and\ne. Monitor provider compliance with personnel security requirements.", + "guidance": "External provider refers to organizations other than the organization operating or acquiring the system. External providers include service bureaus, contractors, and other organizations that provide system development, information technology services, testing or assessment services, outsourced applications, and network/security management. Organizations explicitly include personnel security requirements in acquisition-related documents. External providers may have personnel working at organizational facilities with credentials, badges, or system privileges issued by organizations. Notifications of external personnel changes ensure the appropriate termination of privileges and credentials. Organizations define the transfers and terminations deemed reportable by security-related characteristics that include functions, roles, and the nature of credentials or privileges associated with transferred or terminated individuals." + }, + { + "ref": "PS-8", + "title": "Personnel Sanctions", + "summary": "Personnel Sanctions\na. Employ a formal sanctions process for individuals failing to comply with established information security and privacy policies and procedures; and\nb. Notify to include the ISSO and/or similar role within the organization within 24 hours when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction.", + "guidance": "Organizational sanctions reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Sanctions processes are described in access agreements and can be included as part of general personnel policies for organizations and/or specified in security and privacy policies. Organizations consult with the Office of the General Counsel regarding matters of employee sanctions." + }, + { + "ref": "PS-9", + "title": "Position Descriptions", + "summary": "Position Descriptions\nIncorporate security and privacy roles and responsibilities into organizational position descriptions.", + "guidance": "Specification of security and privacy roles in individual organizational position descriptions facilitates clarity in understanding the security or privacy responsibilities associated with the roles and the role-based security and privacy training requirements for the roles." + } + ] + }, + { + "title": "Risk Assessment", + "controls": [ + { + "ref": "RA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} risk assessment policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the risk assessment policy and the associated risk assessment controls;\nb. Designate an {{ official - an official to manage the risk assessment policy and procedures is defined; }} to manage the development, documentation, and dissemination of the risk assessment policy and procedures; and\nc. Review and update the current risk assessment:\n1. Policy at least every 3 years and following {{ events - events that would require the current risk assessment policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Risk assessment policy and procedures address the controls in the RA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of risk assessment policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to risk assessment policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "RA-2", + "title": "Security Categorization", + "summary": "Security Categorization\na. Categorize the system and information it processes, stores, and transmits;\nb. Document the security categorization results, including supporting rationale, in the security plan for the system; and\nc. Verify that the authorizing official or authorizing official designated representative reviews and approves the security categorization decision.", + "guidance": "Security categories describe the potential adverse impacts or negative consequences to organizational operations, organizational assets, and individuals if organizational information and systems are compromised through a loss of confidentiality, integrity, or availability. Security categorization is also a type of asset loss characterization in systems security engineering processes that is carried out throughout the system development life cycle. Organizations can use privacy risk assessments or privacy impact assessments to better understand the potential adverse effects on individuals. [CNSSI 1253] provides additional guidance on categorization for national security systems.\n\nOrganizations conduct the security categorization process as an organization-wide activity with the direct involvement of chief information officers, senior agency information security officers, senior agency officials for privacy, system owners, mission and business owners, and information owners or stewards. Organizations consider the potential adverse impacts to other organizations and, in accordance with [USA PATRIOT] and Homeland Security Presidential Directives, potential national-level adverse impacts.\n\nSecurity categorization processes facilitate the development of inventories of information assets and, along with [CM-8] , mappings to specific system components where information is processed, stored, or transmitted. The security categorization process is revisited throughout the system development life cycle to ensure that the security categories remain accurate and relevant." + }, + { + "ref": "RA-3", + "title": "Risk Assessment", + "summary": "Risk Assessment\na. Conduct a risk assessment, including:\n1. Identifying threats to and vulnerabilities in the system;\n2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and\n3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;\nb. Integrate risk assessment results and risk management decisions from the organization and mission or business process perspectives with system-level risk assessments;\nc. Document risk assessment results in security assessment report;\nd. Review risk assessment results at least every three (3) years and when a significant change occurs;\ne. Disseminate risk assessment results to {{ personnel or roles - personnel or roles to whom risk assessment results are to be disseminated is/are defined; }} ; and\nf. Update the risk assessment at least every three (3) years or when there are significant changes to the system, its environment of operation, or other conditions that may impact the security or privacy state of the system.\nRA-3 Additional FedRAMP Requirements and Guidance (e) Requirement: Include all Authorizing Officials; for JAB authorizations to include FedRAMP.\ncontrols RA-3(1) Supply Chain Risk Assessment\n(a) Assess supply chain risks associated with {{ systems, system components, and system services - systems, system components, and system services to assess supply chain risks are defined; }} ; and\n(b) Update the supply chain risk assessment {{ frequency - the frequency at which to update the supply chain risk assessment is defined; }} , when there are significant changes to the relevant supply chain, or when changes to the system, environments of operation, or other conditions may necessitate a change in the supply chain.", + "guidance": "Risk assessments consider threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation. Risk assessments also consider risk from external parties, including contractors who operate systems on behalf of the organization, individuals who access organizational systems, service providers, and outsourcing entities.\n\nOrganizations can conduct risk assessments at all three levels in the risk management hierarchy (i.e., organization level, mission/business process level, or information system level) and at any stage in the system development life cycle. Risk assessments can also be conducted at various steps in the Risk Management Framework, including preparation, categorization, control selection, control implementation, control assessment, authorization, and control monitoring. Risk assessment is an ongoing activity carried out throughout the system development life cycle.\n\nRisk assessments can also address information related to the system, including system design, the intended use of the system, testing results, and supply chain-related information or artifacts. Risk assessments can play an important role in control selection processes, particularly during the application of tailoring guidance and in the earliest phases of capability determination." + }, + { + "ref": "RA-5", + "title": "Vulnerability Monitoring and Scanning", + "summary": "Vulnerability Monitoring and Scanning\na. Monitor and scan for vulnerabilities in the system and hosted applications monthly operating system/infrastructure; monthly web applications (including APIs) and databases and when new vulnerabilities potentially affecting the system are identified and reported;\nb. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:\n1. Enumerating platforms, software flaws, and improper configurations;\n2. Formatting checklists and test procedures; and\n3. Measuring vulnerability impact;\nc. Analyze vulnerability scan reports and results from vulnerability monitoring;\nd. Remediate legitimate vulnerabilities high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery in accordance with an organizational assessment of risk;\ne. Share information obtained from the vulnerability monitoring process and control assessments with {{ personnel or roles - personnel or roles with whom information obtained from the vulnerability scanning process and control assessments is to be shared; }} to help eliminate similar vulnerabilities in other systems; and\nf. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.\nRA-5 Additional FedRAMP Requirements and Guidance (a) Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.\n(d) Requirement: If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.\n(e) Requirement: to include all Authorizing Officials; for JAB authorizations to include FedRAMP\ncontrols RA-5(2) Update Vulnerabilities to Be Scanned\nUpdate the system vulnerabilities to be scanned within 24 hours prior to running scans.\nRA-5(3) Breadth and Depth of Coverage\nDefine the breadth and depth of vulnerability scanning coverage.\nRA-5(5) Privileged Access\nImplement privileged access authorization to all components that support authentication for all scans.\nRA-5(11) Public Disclosure Program\nEstablish a public reporting channel for receiving reports of vulnerabilities in organizational systems and system components.", + "guidance": "Security categorization of information and systems guides the frequency and comprehensiveness of vulnerability monitoring (including scans). Organizations determine the required vulnerability monitoring for system components, ensuring that the potential sources of vulnerabilities\u2014such as infrastructure components (e.g., switches, routers, guards, sensors), networked printers, scanners, and copiers\u2014are not overlooked. The capability to readily update vulnerability monitoring tools as new vulnerabilities are discovered and announced and as new scanning methods are developed helps to ensure that new vulnerabilities are not missed by employed vulnerability monitoring tools. The vulnerability monitoring tool update process helps to ensure that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability monitoring and analyses for custom software may require additional approaches, such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can use these analysis approaches in source code reviews and in a variety of tools, including web-based application scanners, static analysis tools, and binary analyzers.\n\nVulnerability monitoring includes scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for flow control mechanisms that are improperly configured or operating incorrectly. Vulnerability monitoring may also include continuous vulnerability monitoring tools that use instrumentation to continuously analyze components. Instrumentation-based tools may improve accuracy and may be run throughout an organization without scanning. Vulnerability monitoring tools that facilitate interoperability include tools that are Security Content Automated Protocol (SCAP)-validated. Thus, organizations consider using scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Control assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan. Organizations also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS).\n\nVulnerability monitoring includes a channel and process for receiving reports of security vulnerabilities from the public at-large. Vulnerability disclosure programs can be as simple as publishing a monitored email address or web form that can receive reports, including notification authorizing good-faith research and disclosure of security vulnerabilities. Organizations generally expect that such research is happening with or without their authorization and can use public vulnerability disclosure channels to increase the likelihood that discovered vulnerabilities are reported directly to the organization for remediation.\n\nOrganizations may also employ the use of financial incentives (also known as \"bug bounties\" ) to further encourage external security researchers to report discovered vulnerabilities. Bug bounty programs can be tailored to the organization\u2019s needs. Bounties can be operated indefinitely or over a defined period of time and can be offered to the general public or to a curated group. Organizations may run public and private bounties simultaneously and could choose to offer partially credentialed access to certain participants in order to evaluate security vulnerabilities from privileged vantage points." + }, + { + "ref": "RA-7", + "title": "Risk Response", + "summary": "Risk Response\nRespond to findings from security and privacy assessments, monitoring, and audits in accordance with organizational risk tolerance.", + "guidance": "Organizations have many options for responding to risk including mitigating risk by implementing new controls or strengthening existing controls, accepting risk with appropriate justification or rationale, sharing or transferring risk, or avoiding risk. The risk tolerance of the organization influences risk response decisions and actions. Risk response addresses the need to determine an appropriate response to risk before generating a plan of action and milestones entry. For example, the response may be to accept risk or reject risk, or it may be possible to mitigate the risk immediately so that a plan of action and milestones entry is not needed. However, if the risk response is to mitigate the risk, and the mitigation cannot be completed immediately, a plan of action and milestones entry is generated." + }, + { + "ref": "RA-9", + "title": "Criticality Analysis", + "summary": "Criticality Analysis\nIdentify critical system components and functions by performing a criticality analysis for {{ systems, system components, or system services - systems, system components, or system services to be analyzed for criticality are defined; }} at {{ decision points in the system development life cycle - decision points in the system development life cycle when a criticality analysis is to be performed are defined; }}.", + "guidance": "Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, executive orders, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and external to the system.\n\nThe operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber-physical systems, devices, system-of-systems, and outsourced IT services. System components that allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.\n\nCriticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design. Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in [RA-2]." + } + ] + }, + { + "title": "System and Services Acquisition", + "controls": [ + { + "ref": "SA-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} system and services acquisition policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;\nb. Designate an {{ official - an official to manage the system and services acquisition policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and\nc. Review and update the current system and services acquisition:\n1. Policy at least every 3 years and following {{ events - events that would require the current system and services acquisition policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SA-2", + "title": "Allocation of Resources", + "summary": "Allocation of Resources\na. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;\nb. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and\nc. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.", + "guidance": "Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle." + }, + { + "ref": "SA-3", + "title": "System Development Life Cycle", + "summary": "System Development Life Cycle\na. Acquire, develop, and manage the system using {{ system-development life cycle - system development life cycle is defined; }} that incorporates information security and privacy considerations;\nb. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;\nc. Identify individuals having information security and privacy roles and responsibilities; and\nd. Integrate the organizational information security and privacy risk management process into system development life cycle activities.", + "guidance": "A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in [SA-8] help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.\n\nThe effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle." + }, + { + "ref": "SA-4", + "title": "Acquisition Process", + "summary": "Acquisition Process\nInclude the following requirements, descriptions, and criteria, explicitly or by reference, using {{ one or more: standardized contract language, {{ contract language - contract language is defined (if selected); }} }} in the acquisition contract for the system, system component, or system service:\na. Security and privacy functional requirements;\nb. Strength of mechanism requirements;\nc. Security and privacy assurance requirements;\nd. Controls needed to satisfy the security and privacy requirements.\ne. Security and privacy documentation requirements;\nf. Requirements for protecting security and privacy documentation;\ng. Description of the system development environment and environment in which the system is intended to operate;\nh. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and\ni. Acceptance criteria.\nSA-4 Additional FedRAMP Requirements and Guidance Requirement: The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).\ncontrols SA-4(1) Functional Properties of Controls\nRequire the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.\nSA-4(2) Design and Implementation Information for Controls\nRequire the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: at a minimum to include security-relevant external system interfaces; high-level design; low-level design; source code or network and data flow diagram; at {{ level of detail - level of detail is defined; }}.\nSA-4(9) Functions, Ports, Protocols, and Services in Use\nRequire the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.\nSA-4(10) Use of Approved PIV Products\nEmploy only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.", + "guidance": "Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in [SA-2] . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1] describes the process of requirements engineering as part of the system development life cycle.\n\nControls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle.\n\nSecurity and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement." + }, + { + "ref": "SA-5", + "title": "System Documentation", + "summary": "System Documentation\na. Obtain or develop administrator documentation for the system, system component, or system service that describes:\n1. Secure configuration, installation, and operation of the system, component, or service;\n2. Effective use and maintenance of security and privacy functions and mechanisms; and\n3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;\nb. Obtain or develop user documentation for the system, system component, or system service that describes:\n1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;\n2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and\n3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;\nc. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take {{ actions - actions to take when system, system component, or system service documentation is either unavailable or nonexistent are defined; }} in response; and\nd. Distribute documentation to at a minimum, the ISSO (or similar role within the organization).", + "guidance": "System documentation helps personnel understand the implementation and operation of controls. Organizations consider establishing specific measures to determine the quality and completeness of the content provided. System documentation may be used to support the management of supply chain risk, incident response, and other functions. Personnel or roles that require documentation include system owners, system security officers, and system administrators. Attempts to obtain documentation include contacting manufacturers or suppliers and conducting web-based searches. The inability to obtain documentation may occur due to the age of the system or component or the lack of support from developers and contractors. When documentation cannot be obtained, organizations may need to recreate the documentation if it is essential to the implementation or operation of the controls. The protection provided for the documentation is commensurate with the security category or classification of the system. Documentation that addresses system vulnerabilities may require an increased level of protection. Secure operation of the system includes initially starting the system and resuming secure system operation after a lapse in system operation." + }, + { + "ref": "SA-8", + "title": "Security and Privacy Engineering Principles", + "summary": "Security and Privacy Engineering Principles\nApply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: {{ organization-defined systems security and privacy engineering principles }}.", + "guidance": "Systems security and privacy engineering principles are closely related to and implemented throughout the system development life cycle (see [SA-3] ). Organizations can apply systems security and privacy engineering principles to new systems under development or to systems undergoing upgrades. For existing systems, organizations apply systems security and privacy engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems.\n\nThe application of systems security and privacy engineering principles helps organizations develop trustworthy, secure, and resilient systems and reduces the susceptibility to disruptions, hazards, threats, and the creation of privacy problems for individuals. Examples of system security engineering principles include: developing layered protections; establishing security and privacy policies, architecture, and controls as the foundation for design and development; incorporating security and privacy requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; tailoring controls to meet organizational needs; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk.\n\nOrganizations that apply systems security and privacy engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk management decisions. System security engineering principles can also be used to protect against certain supply chain risks, including incorporating tamper-resistant hardware into a design." + }, + { + "ref": "SA-9", + "title": "External System Services", + "summary": "External System Services\na. Require that providers of external system services comply with organizational security and privacy requirements and employ the following controls: Appropriate FedRAMP Security Controls Baseline (s) if Federal information is processed or stored within the external system;\nb. Define and document organizational oversight and user roles and responsibilities with regard to external system services; and\nc. Employ the following processes, methods, and techniques to monitor control compliance by external service providers on an ongoing basis: Federal/FedRAMP Continuous Monitoring requirements must be met for external systems where Federal information is processed or stored.\ncontrols SA-9(1) Risk Assessments and Organizational Approvals\n(a) Conduct an organizational assessment of risk prior to the acquisition or outsourcing of information security services; and\n(b) Verify that the acquisition or outsourcing of dedicated information security services is approved by {{ personnel or roles - personnel or roles that approve the acquisition or outsourcing of dedicated information security services is/are defined; }}.\nSA-9(2) Identification of Functions, Ports, Protocols, and Services\nRequire providers of the following external system services to identify the functions, ports, protocols, and other services required for the use of such services: all external systems where Federal information is processed or stored.\nSA-9(5) Processing, Storage, and Service Location\nRestrict the location of information processing, information or data, AND system services to {{ locations - locations where information processing, information or data, AND system services is/are to be restricted are defined; }} based on {{ requirements - requirements or conditions for restricting the location of information processing, information or data, AND system services are defined; }}.", + "guidance": "External system services are provided by an external provider, and the organization has no direct control over the implementation of the required controls or the assessment of control effectiveness. Organizations establish relationships with external service providers in a variety of ways, including through business partnerships, contracts, interagency agreements, lines of business arrangements, licensing agreements, joint ventures, and supply chain exchanges. The responsibility for managing risks from the use of external system services remains with authorizing officials. For services external to organizations, a chain of trust requires that organizations establish and retain a certain level of confidence that each provider in the consumer-provider relationship provides adequate protection for the services rendered. The extent and nature of this chain of trust vary based on relationships between organizations and the external providers. Organizations document the basis for the trust relationships so that the relationships can be monitored. External system services documentation includes government, service providers, end user security roles and responsibilities, and service-level agreements. Service-level agreements define the expectations of performance for implemented controls, describe measurable outcomes, and identify remedies and response requirements for identified instances of noncompliance." + }, + { + "ref": "SA-10", + "title": "Developer Configuration Management", + "summary": "Developer Configuration Management\nRequire the developer of the system, system component, or system service to:\na. Perform configuration management during system, component, or service development, implementation, AND operation;\nb. Document, manage, and control the integrity of changes to {{ configuration items - configuration items under configuration management are defined; }};\nc. Implement only organization-approved changes to the system, component, or service;\nd. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and\ne. Track security flaws and flaw resolution within the system, component, or service and report findings to {{ personnel - personnel to whom security flaws and flaw resolutions within the system, component, or service are reported is/are defined; }}.\nSA-10 Additional FedRAMP Requirements and Guidance (e) Requirement: track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP.", + "guidance": "Organizations consider the quality and completeness of configuration management activities conducted by developers as direct evidence of applying effective security controls. Controls include protecting the master copies of material used to generate security-relevant portions of the system hardware, software, and firmware from unauthorized modification or destruction. Maintaining the integrity of changes to the system, system component, or system service requires strict configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.\n\nThe configuration items that are placed under configuration management include the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the current running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and source code with previous versions; and test fixtures and documentation. Depending on the mission and business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance stage of the system development life cycle." + }, + { + "ref": "SA-11", + "title": "Developer Testing and Evaluation", + "summary": "Developer Testing and Evaluation\nRequire the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:\na. Develop and implement a plan for ongoing security and privacy control assessments;\nb. Perform {{ one or more: unit, integration, system, regression }} testing/evaluation {{ frequency to conduct - frequency at which to conduct {{ one or more: unit, integration, system, regression }} testing/evaluation is defined; }} at {{ depth and coverage - depth and coverage of {{ one or more: unit, integration, system, regression }} testing/evaluation is defined; }};\nc. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;\nd. Implement a verifiable flaw remediation process; and\ne. Correct flaws identified during testing and evaluation.\ncontrols SA-11(1) Static Code Analysis\nRequire the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of the analysis.\nSA-11(1) Additional FedRAMP Requirements Requirement: The service provider must document its methodology for reviewing newly developed code for the Service in its Continuous Monitoring Plan.\n\nIf Static code analysis cannot be performed (for example, when the source code is not available), then dynamic code analysis must be performed (see SA-11 (8))\nSA-11(2) Threat Modeling and Vulnerability Analyses\nRequire the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service that:\n(a) Uses the following contextual information: {{ information - information concerning impact, environment of operations, known or assumed threats, and acceptable risk levels to be used as contextual information for threat modeling and vulnerability analyses is defined; }};\n(b) Employs the following tools and methods: {{ tools and methods - the tools and methods to be employed for threat modeling and vulnerability analyses are defined; }};\n(c) Conducts the modeling and analyses at the following level of rigor: {{ organization-defined breadth and depth of modeling and analyses }} ; and\n(d) Produces evidence that meets the following acceptance criteria: {{ organization-defined acceptance criteria }}.", + "guidance": "Developmental testing and evaluation confirms that the required controls are implemented correctly, operating as intended, enforcing the desired security and privacy policies, and meeting established security and privacy requirements. Security properties of systems and the privacy of individuals may be affected by the interconnection of system components or changes to those components. The interconnections or changes\u2014including upgrading or replacing applications, operating systems, and firmware\u2014may adversely affect previously implemented controls. Ongoing assessment during development allows for additional types of testing and evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as manual code review, security architecture review, and penetration testing, as well as and static analysis, dynamic analysis, binary analysis, or a hybrid of the three analysis approaches.\n\nDevelopers can use the analysis approaches, along with security instrumentation and fuzzing, in a variety of tools and in source code reviews. The security and privacy assessment plans include the specific activities that developers plan to carry out, including the types of analyses, testing, evaluation, and reviews of software and firmware components; the degree of rigor to be applied; the frequency of the ongoing testing and evaluation; and the types of artifacts produced during those processes. The depth of testing and evaluation refers to the rigor and level of detail associated with the assessment process. The coverage of testing and evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security and privacy assessment plans, flaw remediation processes, and the evidence that the plans and processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the system. Contracts may specify protection requirements for documentation." + }, + { + "ref": "SA-15", + "title": "Development Process, Standards, and Tools", + "summary": "Development Process, Standards, and Tools\na. Require the developer of the system, system component, or system service to follow a documented development process that:\n1. Explicitly addresses security and privacy requirements;\n2. Identifies the standards and tools used in the development process;\n3. Documents the specific tool options and tool configurations used in the development process; and\n4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and\nb. Review the development process, standards, tools, tool options, and tool configurations frequency at least annually to determine if the process, standards, tools, tool options and tool configurations selected and employed can satisfy the following security and privacy requirements: {{ organization-defined security and privacy requirements }}.\ncontrols SA-15(3) Criticality Analysis\nRequire the developer of the system, system component, or system service to perform a criticality analysis:\n(a) At the following decision points in the system development life cycle: {{ decision points - decision points in the system development life cycle are defined; }} ; and\n(b) At the following level of rigor: {{ organization-defined breadth and depth of criticality analysis }}.", + "guidance": "Development tools include programming languages and computer-aided design systems. Reviews of development processes include the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes facilitates effective supply chain risk assessment and mitigation. Such integrity requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes." + }, + { + "ref": "SA-22", + "title": "Unsupported System Components", + "summary": "Unsupported System Components\na. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or\nb. Provide the following options for alternative sources for continued support for unsupported components {{ one or more: in-house support, {{ support from external providers - support from external providers is defined (if selected); }} }}.", + "guidance": "Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option.\n\nAlternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation." + } + ] + }, + { + "title": "System and Communications Protection", + "controls": [ + { + "ref": "SC-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business-process-level, system-level }} system and communications protection policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls;\nb. Designate an {{ official - an official to manage the system and communications protection policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and\nc. Review and update the current system and communications protection:\n1. Policy at least every 3 years and following {{ events - events that would require the current system and communications protection policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and communications protection policy and procedures address the controls in the SC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and communications protection policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and communications protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SC-2", + "title": "Separation of System and User Functionality", + "summary": "Separation of System and User Functionality\nSeparate user functionality, including user interface services, from system management functionality.", + "guidance": "System management functionality includes functions that are necessary to administer databases, network components, workstations, or servers. These functions typically require privileged user access. The separation of user functions from system management functions is physical or logical. Organizations may separate system management functions from user functions by using different computers, instances of operating systems, central processing units, or network addresses; by employing virtualization techniques; or some combination of these or other methods. Separation of system management functions from user functions includes web administrative interfaces that employ separate authentication methods for users of any other system resources. Separation of system and user functions may include isolating administrative interfaces on different domains and with additional access controls. The separation of system and user functionality can be achieved by applying the systems security engineering design principles in [SA-8] , including [SA-8(1)], [SA-8(3)], [SA-8(4)], [SA-8(10)], [SA-8(12)], [SA-8(13)], [SA-8(14)] , and [SA-8(18)]." + }, + { + "ref": "SC-4", + "title": "Information in Shared System Resources", + "summary": "Information in Shared System Resources\nPrevent unauthorized and unintended information transfer via shared system resources.", + "guidance": "Preventing unauthorized and unintended information transfer via shared system resources stops information produced by the actions of prior users or roles (or the actions of processes acting on behalf of prior users or roles) from being available to current users or roles (or current processes acting on behalf of current users or roles) that obtain access to shared system resources after those resources have been released back to the system. Information in shared system resources also applies to encrypted representations of information. In other contexts, control of information in shared system resources is referred to as object reuse and residual information protection. Information in shared system resources does not address information remanence, which refers to the residual representation of data that has been nominally deleted; covert channels (including storage and timing channels), where shared system resources are manipulated to violate information flow restrictions; or components within systems for which there are only single users or roles." + }, + { + "ref": "SC-5", + "title": "Denial-of-service Protection", + "summary": "Denial-of-service Protection\na. Protect against the effects of the following types of denial-of-service events: at a minimum: ICMP (ping) flood, SYN flood, slowloris, buffer overflow attack, and volume attack ; and\nb. Employ the following controls to achieve the denial-of-service objective: {{ controls by type of denial-of-service event - controls to achieve the denial-of-service objective by type of denial-of-service event are defined; }}.", + "guidance": "Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events." + }, + { + "ref": "SC-7", + "title": "Boundary Protection", + "summary": "Boundary Protection\na. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;\nb. Implement subnetworks for publicly accessible system components that are {{ physically OR logically }} separated from internal organizational networks; and\nc. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.\nSC-7 Additional FedRAMP Requirements and Guidance \ncontrols SC-7(3) Access Points\nLimit the number of external network connections to the system.\nSC-7(4) External Telecommunications Services\n(a) Implement a managed interface for each external telecommunication service;\n(b) Establish a traffic flow policy for each managed interface;\n(c) Protect the confidentiality and integrity of the information being transmitted across each interface;\n(d) Document each exception to the traffic flow policy with a supporting mission or business need and duration of that need;\n(e) Review exceptions to the traffic flow policy at least every 180 days or whenever there is a change in the threat environment that warrants a review of the exceptions and remove exceptions that are no longer supported by an explicit mission or business need;\n(f) Prevent unauthorized exchange of control plane traffic with external networks;\n(g) Publish information to enable remote networks to detect unauthorized control plane traffic from internal networks; and\n(h) Filter unauthorized control plane traffic from external networks.\nSC-7(5) Deny by Default \u2014 Allow by Exception\nDeny network communications traffic by default and allow network communications traffic by exception any systems.\nSC-7 (5) Additional FedRAMP Requirements and Guidance \nSC-7(7) Split Tunneling for Remote Devices\nPrevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using {{ safeguards - safeguards to securely provision split tunneling are defined; }}.\nSC-7(8) Route Traffic to Authenticated Proxy Servers\nRoute {{ internal communications traffic - internal communications traffic to be routed to external networks is defined; }} to any network outside of organizational control and any network outside the authorization boundary through authenticated proxy servers at managed interfaces.\nSC-7(12) Host-based Protection\nImplement Host Intrusion Prevention System (HIPS), Host Intrusion Detection System (HIDS), or minimally a host-based firewall at {{ system components - system components where host-based boundary protection mechanisms are to be implemented are defined; }}.\nSC-7(18) Fail Secure\nPrevent systems from entering unsecure states in the event of an operational failure of a boundary protection device.", + "guidance": "Managed interfaces include gateways, routers, firewalls, guards, network-based malicious code analysis, virtualization systems, or encrypted tunnels implemented within a security architecture. Subnetworks that are physically or logically separated from internal networks are referred to as demilitarized zones or DMZs. Restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. [SP 800-189] provides additional information on source address validation techniques to prevent ingress and egress of traffic with spoofed addresses. Commercial telecommunications services are provided by network components and consolidated management systems shared by customers. These services may also include third party-provided access lines and other service elements. Such services may represent sources of increased risk despite contract security provisions. Boundary protection may be implemented as a common control for all or part of an organizational network such that the boundary to be protected is greater than a system-specific boundary (i.e., an authorization boundary)." + }, + { + "ref": "SC-8", + "title": "Transmission Confidentiality and Integrity", + "summary": "Transmission Confidentiality and Integrity\nProtect the confidentiality AND integrity of transmitted information.\nSC-8 Additional FedRAMP Requirements and Guidance \ncontrols SC-8(1) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure of information AND detect changes to information during transmission.\nSC-8 (1) Additional FedRAMP Requirements and Guidance Requirement: Please ensure SSP Section 10.3 Cryptographic Modules Implemented for Data At Rest (DAR) and Data In Transit (DIT) is fully populated for reference in this control.", + "guidance": "Protecting the confidentiality and integrity of transmitted information applies to internal and external networks as well as any system components that can transmit information, including servers, notebook computers, desktop computers, mobile devices, printers, copiers, scanners, facsimile machines, and radios. Unprotected communication paths are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of information can be accomplished by physical or logical means. Physical protection can be achieved by using protected distribution systems. A protected distribution system is a wireline or fiber-optics telecommunications system that includes terminals and adequate electromagnetic, acoustical, electrical, and physical controls to permit its use for the unencrypted transmission of classified information. Logical protection can be achieved by employing encryption techniques.\n\nOrganizations that rely on commercial providers who offer transmission services as commodity services rather than as fully dedicated services may find it difficult to obtain the necessary assurances regarding the implementation of needed controls for transmission confidentiality and integrity. In such situations, organizations determine what types of confidentiality or integrity services are available in standard, commercial telecommunications service packages. If it is not feasible to obtain the necessary controls and assurances of control effectiveness through appropriate contracting vehicles, organizations can implement appropriate compensating controls." + }, + { + "ref": "SC-10", + "title": "Network Disconnect", + "summary": "Network Disconnect\nTerminate the network connection associated with a communications session at the end of the session or after no longer than ten (10) minutes for privileged sessions and no longer than fifteen (15) minutes for user sessions of inactivity.", + "guidance": "Network disconnect applies to internal and external networks. Terminating network connections associated with specific communications sessions includes de-allocating TCP/IP address or port pairs at the operating system level and de-allocating the networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. Periods of inactivity may be established by organizations and include time periods by type of network access or for specific network accesses." + }, + { + "ref": "SC-12", + "title": "Cryptographic Key Establishment and Management", + "summary": "Cryptographic Key Establishment and Management\nEstablish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: In accordance with Federal requirements.\nSC-12 Additional FedRAMP Requirements and Guidance ", + "guidance": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. Organizations define key management requirements in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and specify appropriate options, parameters, and levels. Organizations manage trust stores to ensure that only approved trust anchors are part of such trust stores. This includes certificates with visibility external to organizational systems and certificates related to the internal operations of systems. [NIST CMVP] and [NIST CAVP] provide additional information on validated cryptographic modules and algorithms that can be used in cryptographic key management and establishment." + }, + { + "ref": "SC-13", + "title": "Cryptographic Protection", + "summary": "Cryptographic Protection\na. Determine the {{ cryptographic uses - cryptographic uses are defined; }} ; and\nb. Implement the following types of cryptography required for each specified cryptographic use: FIPS-validated or NSA-approved cryptography.\nSC-13 Additional FedRAMP Requirements and Guidance ", + "guidance": "Cryptography can be employed to support a variety of security solutions, including the protection of classified information and controlled unclassified information, the provision and implementation of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances but lack the necessary formal access approvals. Cryptography can also be used to support random number and hash generation. Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. For example, organizations that need to protect classified information may specify the use of NSA-approved cryptography. Organizations that need to provision and implement digital signatures may specify the use of FIPS-validated cryptography. Cryptography is implemented in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "SC-15", + "title": "Collaborative Computing Devices and Applications", + "summary": "Collaborative Computing Devices and Applications\na. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: no exceptions for computing devices ; and\nb. Provide an explicit indication of use to users physically present at the devices.\nSC-15 Additional FedRAMP Requirements and Guidance Requirement: The information system provides disablement (instead of physical disconnect) of collaborative computing devices in a manner that supports ease of use.", + "guidance": "Collaborative computing devices and applications include remote meeting devices and applications, networked white boards, cameras, and microphones. The explicit indication of use includes signals to users when collaborative computing devices and applications are activated." + }, + { + "ref": "SC-17", + "title": "Public Key Infrastructure Certificates", + "summary": "Public Key Infrastructure Certificates\na. Issue public key certificates under an {{ certificate policy - a certificate policy for issuing public key certificates is defined; }} or obtain public key certificates from an approved service provider; and\nb. Include only approved trust anchors in trust stores or certificate stores managed by the organization.", + "guidance": "Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates." + }, + { + "ref": "SC-18", + "title": "Mobile Code", + "summary": "Mobile Code\na. Define acceptable and unacceptable mobile code and mobile code technologies; and\nb. Authorize, monitor, and control the use of mobile code within the system.", + "guidance": "Mobile code includes any program, application, or content that can be transmitted across a network (e.g., embedded in an email, document, or website) and executed on a remote system. Decisions regarding the use of mobile code within organizational systems are based on the potential for the code to cause damage to the systems if used maliciously. Mobile code technologies include Java applets, JavaScript, HTML5, WebGL, and VBScript. Usage restrictions and implementation guidelines apply to both the selection and use of mobile code installed on servers and mobile code downloaded and executed on individual workstations and devices, including notebook computers and smart phones. Mobile code policy and procedures address specific actions taken to prevent the development, acquisition, and introduction of unacceptable mobile code within organizational systems, including requiring mobile code to be digitally signed by a trusted source." + }, + { + "ref": "SC-20", + "title": "Secure Name/Address Resolution Service (Authoritative Source)", + "summary": "Secure Name/Address Resolution Service (Authoritative Source)\na. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and\nb. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.\nSC-20 Additional FedRAMP Requirements and Guidance Requirement: Control Description should include how DNSSEC is implemented on authoritative DNS servers to supply valid responses to external DNSSEC requests.", + "guidance": "Providing authoritative source information enables external clients, including remote Internet clients, to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Systems that provide name and address resolution services include domain name system (DNS) servers. Additional artifacts include DNS Security Extensions (DNSSEC) digital signatures and cryptographic keys. Authoritative data includes DNS resource records. The means for indicating the security status of child zones include the use of delegation signer resource records in the DNS. Systems that use technologies other than the DNS to map between host and service names and network addresses provide other means to assure the authenticity and integrity of response data." + }, + { + "ref": "SC-21", + "title": "Secure Name/Address Resolution Service (Recursive or Caching Resolver)", + "summary": "Secure Name/Address Resolution Service (Recursive or Caching Resolver)\nRequest and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.\nSC-21 Additional FedRAMP Requirements and Guidance Requirement: Internal recursive DNS servers must be located inside an authorized environment. It is typically within the boundary, or leveraged from an underlying IaaS/PaaS.", + "guidance": "Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Systems that provide name and address resolution services for local clients include recursive resolving or caching domain name system (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Systems that use technologies other than the DNS to map between host and service names and network addresses provide some other means to enable clients to verify the authenticity and integrity of response data." + }, + { + "ref": "SC-22", + "title": "Architecture and Provisioning for Name/Address Resolution Service", + "summary": "Architecture and Provisioning for Name/Address Resolution Service\nEnsure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.", + "guidance": "Systems that provide name and address resolution services include domain name system (DNS) servers. To eliminate single points of failure in systems and enhance redundancy, organizations employ at least two authoritative domain name system servers\u2014one configured as the primary server and the other configured as the secondary server. Additionally, organizations typically deploy the servers in two geographically separated network subnetworks (i.e., not located in the same physical facility). For role separation, DNS servers with internal roles only process name and address resolution requests from within organizations (i.e., from internal clients). DNS servers with external roles only process name and address resolution information requests from clients external to organizations (i.e., on external networks, including the Internet). Organizations specify clients that can access authoritative DNS servers in certain roles (e.g., by address ranges and explicit lists)." + }, + { + "ref": "SC-23", + "title": "Session Authenticity", + "summary": "Session Authenticity\nProtect the authenticity of communications sessions.", + "guidance": "Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of communications sessions in the ongoing identities of other parties and the validity of transmitted information. Authenticity protection includes protecting against \"man-in-the-middle\" attacks, session hijacking, and the insertion of false information into sessions." + }, + { + "ref": "SC-28", + "title": "Protection of Information at Rest", + "summary": "Protection of Information at Rest\nProtect the confidentiality AND integrity of the following information at rest: {{ information at rest - information at rest requiring protection is defined; }}.\nSC-28 Additional FedRAMP Requirements and Guidance \ncontrols SC-28(1) Cryptographic Protection\nImplement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on all information system components storing Federal data or system data that must be protected at the High or Moderate impact levels: {{ information - information requiring cryptographic protection is defined; }}.\nSC-28 (1) Additional FedRAMP Requirements and Guidance ", + "guidance": "Information at rest refers to the state of information when it is not in process or in transit and is located on system components. Such components include internal or external hard disk drives, storage area network devices, or databases. However, the focus of protecting information at rest is not on the type of storage device or frequency of access but rather on the state of the information. Information at rest addresses the confidentiality and integrity of information and covers user information and system information. System-related information that requires protection includes configurations or rule sets for firewalls, intrusion detection and prevention systems, filtering routers, and authentication information. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing write-once-read-many (WORM) technologies. When adequate protection of information at rest cannot otherwise be achieved, organizations may employ other controls, including frequent scanning to identify malicious code at rest and secure offline storage in lieu of online storage." + }, + { + "ref": "SC-39", + "title": "Process Isolation", + "summary": "Process Isolation\nMaintain a separate execution domain for each executing system process.", + "guidance": "Systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each system process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces. Process isolation technologies, including sandboxing or virtualization, logically separate software and firmware from other software, firmware, and data. Process isolation helps limit the access of potentially untrusted software to other system resources. The capability to maintain separate execution domains is available in commercial operating systems that employ multi-state processor technologies." + }, + { + "ref": "SC-45", + "title": "System Time Synchronization", + "summary": "System Time Synchronization\nSynchronize system clocks within and between systems and system components.\ncontrols SC-45(1) Synchronization with Authoritative Time Source\n(a) Compare the internal system clocks At least hourly with http://tf.nist.gov/tf-cgi/servers.cgi ; and\n(b) Synchronize the internal system clocks to the authoritative time source when the time difference is greater than any difference.\nSC-45(1) Additional FedRAMP Requirements and Guidance Requirement: The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.", + "guidance": "Time synchronization of system clocks is essential for the correct execution of many system services, including identification and authentication processes that involve certificates and time-of-day restrictions as part of access control. Denial of service or failure to deny expired credentials may result without properly synchronized clocks within and between systems and system components. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, such as clocks synchronizing within hundreds of milliseconds or tens of milliseconds. Organizations may define different time granularities for system components. Time service can be critical to other security capabilities\u2014such as access control and identification and authentication\u2014depending on the nature of the mechanisms used to support the capabilities." + } + ] + }, + { + "title": "System and Information Integrity", + "controls": [ + { + "ref": "SI-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to {{ organization-defined personnel or roles }}:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} system and information integrity policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the system and information integrity policy and the associated system and information integrity controls;\nb. Designate an {{ official - an official to manage the system and information integrity policy and procedures is defined; }} to manage the development, documentation, and dissemination of the system and information integrity policy and procedures; and\nc. Review and update the current system and information integrity:\n1. Policy at least every 3 years and following {{ events - events that would require the current system and information integrity policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "System and information integrity policy and procedures address the controls in the SI family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and information integrity policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and information integrity policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SI-2", + "title": "Flaw Remediation", + "summary": "Flaw Remediation\na. Identify, report, and correct system flaws;\nb. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;\nc. Install security-relevant software and firmware updates within within thirty (30) days of release of updates of the release of the updates; and\nd. Incorporate flaw remediation into the organizational configuration management process.\ncontrols SI-2(2) Automated Flaw Remediation Status\nDetermine if system components have applicable security-relevant software and firmware updates installed using {{ automated mechanisms - automated mechanisms to determine if applicable security-relevant software and firmware updates are installed on system components are defined; }} at least monthly.\nSI-2(3) Time to Remediate Flaws and Benchmarks for Corrective Actions\n(a) Measure the time between flaw identification and flaw remediation; and\n(b) Establish the following benchmarks for taking corrective actions: {{ benchmarks - the benchmarks for taking corrective actions are defined; }}.", + "guidance": "The need to remediate system flaws applies to all types of software and firmware. Organizations identify systems affected by software flaws, including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security and privacy responsibilities. Security-relevant updates include patches, service packs, and malicious code signatures. Organizations also address flaws discovered during assessments, continuous monitoring, incident response activities, and system error handling. By incorporating flaw remediation into configuration management processes, required remediation actions can be tracked and verified.\n\nOrganization-defined time periods for updating security-relevant software and firmware may vary based on a variety of risk factors, including the security category of the system, the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw), the organizational risk tolerance, the mission supported by the system, or the threat environment. Some types of flaw remediation may require more testing than other types. Organizations determine the type of testing needed for the specific type of flaw remediation activity under consideration and the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software or firmware updates is not necessary or practical, such as when implementing simple malicious code signature updates. In testing decisions, organizations consider whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures." + }, + { + "ref": "SI-3", + "title": "Malicious Code Protection", + "summary": "Malicious Code Protection\na. Implement signature based and non-signature based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code;\nb. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures;\nc. Configure malicious code protection mechanisms to:\n1. Perform periodic scans of the system at least weekly and real-time scans of files from external sources at to include endpoints and network entry and exit points as the files are downloaded, opened, or executed in accordance with organizational policy; and\n2. to include blocking and quarantining malicious code ; and send alert to {{ personnel or roles - personnel or roles to be alerted when malicious code is detected is/are defined; }} in response to malicious code detection; and\nd. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system.", + "guidance": "System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world-wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code.\n\nMalicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions.\n\nIn situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files." + }, + { + "ref": "SI-4", + "title": "System Monitoring", + "summary": "System Monitoring\na. Monitor the system to detect:\n1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: {{ monitoring objectives - monitoring objectives to detect attacks and indicators of potential attacks on the system are defined; }} ; and\n2. Unauthorized local, network, and remote connections;\nb. Identify unauthorized use of the system through the following techniques and methods: {{ techniques and methods - techniques and methods used to identify unauthorized use of the system are defined; }};\nc. Invoke internal monitoring capabilities or deploy monitoring devices:\n1. Strategically within the system to collect organization-determined essential information; and\n2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;\nd. Analyze detected events and anomalies;\ne. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation;\nf. Obtain legal opinion regarding system monitoring activities; and\ng. Provide {{ system monitoring information - system monitoring information to be provided to personnel or roles is defined; }} to {{ personnel or roles - personnel or roles to whom system monitoring information is to be provided is/are defined; }} {{ one or more: as needed, {{ frequency - a frequency for providing system monitoring to personnel or roles is defined (if selected); }} }}.\nSI-4 Additional FedRAMP Requirements and Guidance \ncontrols SI-4(1) System-wide Intrusion Detection System\nConnect and configure individual intrusion detection tools into a system-wide intrusion detection system.\nSI-4(2) Automated Tools and Mechanisms for Real-time Analysis\nEmploy automated tools and mechanisms to support near real-time analysis of events.\nSI-4(4) Inbound and Outbound Communications Traffic\n(a) Determine criteria for unusual or unauthorized activities or conditions for inbound and outbound communications traffic;\n(b) Monitor inbound and outbound communications traffic continuously for {{ organization-defined unusual or unauthorized activities or conditions }}.\nSI-4(5) System-generated Alerts\nAlert {{ personnel or roles - personnel or roles to be alerted when indications of compromise or potential compromise occur is/are defined; }} when the following system-generated indications of compromise or potential compromise occur: {{ compromise indicators - compromise indicators are defined; }}.\nSI-4 (5) Additional FedRAMP Requirements and Guidance \nSI-4(16) Correlate Monitoring Information\nCorrelate information from monitoring tools and mechanisms employed throughout the system.\nSI-4(18) Analyze Traffic and Covert Exfiltration\nAnalyze outbound communications traffic at external interfaces to the system and at the following interior points to detect covert exfiltration of information: {{ interior points - interior points within the system where communications traffic is to be analyzed are defined; }}.\nSI-4(23) Host-based Devices\nImplement the following host-based monitoring mechanisms at {{ system components - system components where host-based monitoring is to be implemented are defined; }}: {{ host-based monitoring mechanisms - host-based monitoring mechanisms to be implemented on system components are defined; }}.", + "guidance": "System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at external interfaces to the system. Internal monitoring includes the observation of events occurring within the system. Organizations monitor systems by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives guide and inform the determination of the events. System monitoring capabilities are achieved through a variety of tools and techniques, including intrusion detection and prevention systems, malicious code protection software, scanning tools, audit record monitoring software, and network monitoring software.\n\nDepending on the security architecture, the distribution and configuration of monitoring devices may impact throughput at key internal and external boundaries as well as at other locations across a network due to the introduction of network throughput latency. If throughput management is needed, such devices are strategically located and deployed as part of an established organization-wide security architecture. Strategic locations for monitoring devices include selected perimeter locations and near key servers and server farms that support critical applications. Monitoring devices are typically employed at the managed interfaces associated with controls [SC-7] and [AC-17] . The information collected is a function of the organizational monitoring objectives and the capability of systems to support such objectives. Specific types of transactions of interest include Hypertext Transfer Protocol (HTTP) traffic that bypasses HTTP proxies. System monitoring is an integral part of organizational continuous monitoring and incident response programs, and output from system monitoring serves as input to those programs. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other controls (e.g., [AC-2g], [AC-2(7)], [AC-2(12)(a)], [AC-17(1)], [AU-13], [AU-13(1)], [AU-13(2)], [CM-3f], [CM-6d], [MA-3a], [MA-4a], [SC-5(3)(b)], [SC-7a], [SC-7(24)(b)], [SC-18b], [SC-43b] ). Adjustments to levels of system monitoring are based on law enforcement information, intelligence information, or other sources of information. The legality of system monitoring activities is based on applicable laws, executive orders, directives, regulations, policies, standards, and guidelines." + }, + { + "ref": "SI-5", + "title": "Security Alerts, Advisories, and Directives", + "summary": "Security Alerts, Advisories, and Directives\na. Receive system security alerts, advisories, and directives from to include US-CERT and Cybersecurity and Infrastructure Security Agency (CISA) Directives on an ongoing basis;\nb. Generate internal security alerts, advisories, and directives as deemed necessary;\nc. Disseminate security alerts, advisories, and directives to: to include system security personnel and administrators with configuration/patch-management responsibilities ; and\nd. Implement security directives in accordance with established time frames, or notify the issuing organization of the degree of noncompliance.\nRequirement: Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.", + "guidance": "The Cybersecurity and Infrastructure Security Agency (CISA) generates security alerts and advisories to maintain situational awareness throughout the Federal Government. Security directives are issued by OMB or other designated organizations with the responsibility and authority to issue such directives. Compliance with security directives is essential due to the critical nature of many of these directives and the potential (immediate) adverse effects on organizational operations and assets, individuals, other organizations, and the Nation should the directives not be implemented in a timely manner. External organizations include supply chain partners, external mission or business partners, external service providers, and other peer or supporting organizations." + }, + { + "ref": "SI-6", + "title": "Security and Privacy Function Verification", + "summary": "Security and Privacy Function Verification\na. Verify the correct operation of {{ organization-defined security and privacy functions }};\nb. Perform the verification of the functions specified in SI-6a {{ one or more: to include upon system startup and/or restart , upon command by user with appropriate privilege, at least monthly }};\nc. Alert to include system administrators and security personnel to failed security and privacy verification tests; and\nd. {{ one or more: shut the system down, restart the system, {{ alternative action(s) - alternative action(s) to be performed when anomalies are discovered are defined (if selected); }} }} when anomalies are discovered.", + "guidance": "Transitional states for systems include system startup, restart, shutdown, and abort. System notifications include hardware indicator lights, electronic alerts to system administrators, and messages to local computer consoles. In contrast to security function verification, privacy function verification ensures that privacy functions operate as expected and are approved by the senior agency official for privacy or that privacy attributes are applied or used as expected." + }, + { + "ref": "SI-7", + "title": "Software, Firmware, and Information Integrity", + "summary": "Software, Firmware, and Information Integrity\na. Employ integrity verification tools to detect unauthorized changes to the following software, firmware, and information: {{ organization-defined software, firmware, and information }} ; and\nb. Take the following actions when unauthorized changes to the software, firmware, and information are detected: {{ organization-defined actions }}.\ncontrols SI-7(1) Integrity Checks\nPerform an integrity check of {{ organization-defined software, firmware, and information }} {{ one or more: at startup, at selection to include security relevant event , at least monthly }}.\nSI-7(7) Integration of Detection and Response\nIncorporate the detection of the following unauthorized changes into the organizational incident response capability: {{ changes - security-relevant changes to the system are defined; }}.", + "guidance": "Unauthorized changes to software, firmware, and information can occur due to errors or malicious activity. Software includes operating systems (with key internal components, such as kernels or drivers), middleware, and applications. Firmware interfaces include Unified Extensible Firmware Interface (UEFI) and Basic Input/Output System (BIOS). Information includes personally identifiable information and metadata that contains security and privacy attributes associated with information. Integrity-checking mechanisms\u2014including parity checks, cyclical redundancy checks, cryptographic hashes, and associated tools\u2014can automatically monitor the integrity of systems and hosted applications." + }, + { + "ref": "SI-8", + "title": "Spam Protection", + "summary": "Spam Protection\na. Employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages; and\nb. Update spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures.\nSI-8 Additional FedRAMP Requirements and Guidance \ncontrols SI-8(2) Automatic Updates\nAutomatically update spam protection mechanisms {{ frequency - the frequency at which to automatically update spam protection mechanisms is defined; }}.", + "guidance": "System entry and exit points include firewalls, remote-access servers, electronic mail servers, web servers, proxy servers, workstations, notebook computers, and mobile devices. Spam can be transported by different means, including email, email attachments, and web accesses. Spam protection mechanisms include signature definitions." + }, + { + "ref": "SI-10", + "title": "Information Input Validation", + "summary": "Information Input Validation\nCheck the validity of the following information inputs: {{ information inputs - information inputs to the system requiring validity checks are defined; }}.\nSI-10 Additional FedRAMP Requirements and Guidance Requirement: Validate all information inputs and document any exceptions", + "guidance": "Checking the valid syntax and semantics of system inputs\u2014including character set, length, numerical range, and acceptable values\u2014verifies that inputs match specified definitions for format and content. For example, if the organization specifies that numerical values between 1-100 are the only acceptable inputs for a field in a given application, inputs of \"387,\" \"abc,\" or \"%K%\" are invalid inputs and are not accepted as input to the system. Valid inputs are likely to vary from field to field within a software application. Applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the corrupted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing them to interpreters prevents the content from being unintentionally interpreted as commands. Input validation ensures accurate and correct inputs and prevents attacks such as cross-site scripting and a variety of injection attacks." + }, + { + "ref": "SI-11", + "title": "Error Handling", + "summary": "Error Handling\na. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and\nb. Reveal error messages only to to include the ISSO and/or similar role within the organization.", + "guidance": "Organizations consider the structure and content of error messages. The extent to which systems can handle error conditions is guided and informed by organizational policy and operational requirements. Exploitable information includes stack traces and implementation details; erroneous logon attempts with passwords mistakenly entered as the username; mission or business information that can be derived from, if not stated explicitly by, the information recorded; and personally identifiable information, such as account numbers, social security numbers, and credit card numbers. Error messages may also provide a covert channel for transmitting information." + }, + { + "ref": "SI-12", + "title": "Information Management and Retention", + "summary": "Information Management and Retention\nManage and retain information within the system and information output from the system in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements.", + "guidance": "Information management and retention requirements cover the full life cycle of information, in some cases extending beyond system disposal. Information to be retained may also include policies, procedures, plans, reports, data output from control implementation, and other types of administrative information. The National Archives and Records Administration (NARA) provides federal policy and guidance on records retention and schedules. If organizations have a records management office, consider coordinating with records management personnel. Records produced from the output of implemented controls that may require management and retention include, but are not limited to: All XX-1, [AC-6(9)], [AT-4], [AU-12], [CA-2], [CA-3], [CA-5], [CA-6], [CA-7], [CA-8], [CA-9], [CM-2], [CM-3], [CM-4], [CM-6], [CM-8], [CM-9], [CM-12], [CM-13], [CP-2], [IR-6], [IR-8], [MA-2], [MA-4], [PE-2], [PE-8], [PE-16], [PE-17], [PL-2], [PL-4], [PL-7], [PL-8], [PM-5], [PM-8], [PM-9], [PM-18], [PM-21], [PM-27], [PM-28], [PM-30], [PM-31], [PS-2], [PS-6], [PS-7], [PT-2], [PT-3], [PT-7], [RA-2], [RA-3], [RA-5], [RA-8], [SA-4], [SA-5], [SA-8], [SA-10], [SI-4], [SR-2], [SR-4], [SR-8]." + }, + { + "ref": "SI-16", + "title": "Memory Protection", + "summary": "Memory Protection\nImplement the following controls to protect the system memory from unauthorized code execution: {{ controls - controls to be implemented to protect the system memory from unauthorized code execution are defined; }}.", + "guidance": "Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Controls employed to protect memory include data execution prevention and address space layout randomization. Data execution prevention controls can either be hardware-enforced or software-enforced with hardware enforcement providing the greater strength of mechanism." + } + ] + }, + { + "title": "Supply Chain Risk Management", + "controls": [ + { + "ref": "SR-1", + "title": "Policy and Procedures", + "summary": "Policy and Procedures\na. Develop, document, and disseminate to to include chief privacy and ISSO and/or similar role or designees:\n1. {{ one or more: organization-level, mission/business process-level, system-level }} supply chain risk management policy that:\n(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and\n(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and\n2. Procedures to facilitate the implementation of the supply chain risk management policy and the associated supply chain risk management controls;\nb. Designate an {{ official - an official to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures is defined; }} to manage the development, documentation, and dissemination of the supply chain risk management policy and procedures; and\nc. Review and update the current supply chain risk management:\n1. Policy at least every 3 years and following {{ events - events that require the current supply chain risk management policy to be reviewed and updated are defined; }} ; and\n2. Procedures at least annually and following significant changes.", + "guidance": "Supply chain risk management policy and procedures address the controls in the SR family as well as supply chain-related controls in other families that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of supply chain risk management policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to supply chain risk management policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure." + }, + { + "ref": "SR-2", + "title": "Supply Chain Risk Management Plan", + "summary": "Supply Chain Risk Management Plan\na. Develop a plan for managing supply chain risks associated with the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of the following systems, system components or system services: {{ systems, system components, or system services - systems, system components, or system services for which a supply chain risk management plan is developed are defined; }};\nb. Review and update the supply chain risk management plan at least annually or as required, to address threat, organizational or environmental changes; and\nc. Protect the supply chain risk management plan from unauthorized disclosure and modification.\ncontrols SR-2(1) Establish SCRM Team\nEstablish a supply chain risk management team consisting of {{ personnel, roles and responsibilities - the personnel, roles, and responsibilities of the supply chain risk management team are defined; }} to lead and support the following SCRM activities: {{ supply chain risk management activities - supply chain risk management activities are defined; }}.", + "guidance": "The dependence on products, systems, and services from external providers, as well as the nature of the relationships with those providers, present an increasing level of risk to an organization. Threat actions that may increase security or privacy risks include unauthorized production, the insertion or use of counterfeits, tampering, theft, insertion of malicious software and hardware, and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system element or component, a system, an organization, a sector, or the Nation. Managing supply chain risk is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders. Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against plans. The SCRM plan (at the system-level) is implementation specific, providing policy implementation, requirements, constraints and implications. It can either be stand-alone, or incorporated into system security and privacy plans. The SCRM plan addresses managing, implementation, and monitoring of SCRM controls and the development/sustainment of systems across the SDLC to support mission and business functions.\n\nBecause supply chains can differ significantly across and within organizations, SCRM plans are tailored to the individual program, organizational, and operational contexts. Tailored SCRM plans provide the basis for determining whether a technology, service, system component, or system is fit for purpose, and as such, the controls need to be tailored accordingly. Tailored SCRM plans help organizations focus their resources on the most critical mission and business functions based on mission and business requirements and their risk environment. Supply chain risk management plans include an expression of the supply chain risk tolerance for the organization, acceptable supply chain risk mitigation strategies or controls, a process for consistently evaluating and monitoring supply chain risk, approaches for implementing and communicating the plan, a description of and justification for supply chain risk mitigation measures taken, and associated roles and responsibilities. Finally, supply chain risk management plans address requirements for developing trustworthy, secure, privacy-protective, and resilient system components and systems, including the application of the security design principles implemented as part of life cycle-based systems security engineering processes (see [SA-8])." + }, + { + "ref": "SR-3", + "title": "Supply Chain Controls and Processes", + "summary": "Supply Chain Controls and Processes\na. Establish a process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes of {{ system or system component - the system or system component requiring a process or processes to identify and address weaknesses or deficiencies is defined; }} in coordination with {{ supply chain personnel - supply chain personnel with whom to coordinate the process or processes to identify and address weaknesses or deficiencies in the supply chain elements and processes is/are defined; }};\nb. Employ the following controls to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events: {{ supply chain controls - supply chain controls employed to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events are defined; }} ; and\nc. Document the selected and implemented supply chain processes and controls in {{ one or more: security and privacy plans, supply chain risk management plan, {{ document - the document identifying the selected and implemented supply chain processes and controls is defined (if selected); }} }}.\nSR-3 Additional FedRAMP Requirements and Guidance Requirement: CSO must document and maintain the supply chain custody, including replacement devices, to ensure the integrity of the devices before being introduced to the boundary.", + "guidance": "Supply chain elements include organizations, entities, or tools employed for the research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, and disposal of systems and system components. Supply chain processes include hardware, software, and firmware development processes; shipping and handling procedures; personnel security and physical security programs; configuration management tools, techniques, and measures to maintain provenance; or other programs, processes, or procedures associated with the development, acquisition, maintenance and disposal of systems and system components. Supply chain elements and processes may be provided by organizations, system integrators, or external providers. Weaknesses or deficiencies in supply chain elements or processes represent potential vulnerabilities that can be exploited by adversaries to cause harm to the organization and affect its ability to carry out its core missions or business functions. Supply chain personnel are individuals with roles and responsibilities in the supply chain." + }, + { + "ref": "SR-5", + "title": "Acquisition Strategies, Tools, and Methods", + "summary": "Acquisition Strategies, Tools, and Methods\nEmploy the following acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks: {{ strategies, tools, and methods - acquisition strategies, contract tools, and procurement methods to protect against, identify, and mitigate supply chain risks are defined; }}.", + "guidance": "The use of the acquisition process provides an important vehicle to protect the supply chain. There are many useful tools and techniques available, including obscuring the end use of a system or system component, using blind or filtered buys, requiring tamper-evident packaging, or using trusted or controlled distribution. The results from a supply chain risk assessment can guide and inform the strategies, tools, and methods that are most applicable to the situation. Tools and techniques may provide protections against unauthorized production, theft, tampering, insertion of counterfeits, insertion of malicious software or backdoors, and poor development practices throughout the system development life cycle. Organizations also consider providing incentives for suppliers who implement controls, promote transparency into their processes and security and privacy practices, provide contract language that addresses the prohibition of tainted or counterfeit components, and restrict purchases from untrustworthy suppliers. Organizations consider providing training, education, and awareness programs for personnel regarding supply chain risk, available mitigation strategies, and when the programs should be employed. Methods for reviewing and protecting development plans, documentation, and evidence are commensurate with the security and privacy requirements of the organization. Contracts may specify documentation protection requirements." + }, + { + "ref": "SR-6", + "title": "Supplier Assessments and Reviews", + "summary": "Supplier Assessments and Reviews\nAssess and review the supply chain-related risks associated with suppliers or contractors and the system, system component, or system service they provide at least annually.\nSR-6 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure that their supply chain vendors build and test their systems in alignment with NIST SP 800-171 or a commensurate security and compliance framework. CSOs must ensure that vendors are compliant with physical facility access and logical access controls to supplied products.", + "guidance": "An assessment and review of supplier risk includes security and supply chain risk management processes, foreign ownership, control or influence (FOCI), and the ability of the supplier to effectively assess subordinate second-tier and third-tier suppliers and contractors. The reviews may be conducted by the organization or by an independent third party. The reviews consider documented processes, documented controls, all-source intelligence, and publicly available information related to the supplier or contractor. Organizations can use open-source information to monitor for indications of stolen information, poor development and quality control practices, information spillage, or counterfeits. In some cases, it may be appropriate or required to share assessment and review results with other organizations in accordance with any applicable rules, policies, or inter-organizational agreements or contracts." + }, + { + "ref": "SR-8", + "title": "Notification Agreements", + "summary": "Notification Agreements\nEstablish agreements and procedures with entities involved in the supply chain for the system, system component, or system service for the notification of supply chain compromises and results of assessment or audits.\nSR-8 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure and document how they receive notifications from their supply chain vendor of newly discovered vulnerabilities including zero-day vulnerabilities.", + "guidance": "The establishment of agreements and procedures facilitates communications among supply chain entities. Early notification of compromises and potential compromises in the supply chain that can potentially adversely affect or have adversely affected organizational systems or system components is essential for organizations to effectively respond to such incidents. The results of assessments or audits may include open-source information that contributed to a decision or result and could be used to help the supply chain entity resolve a concern or improve its processes." + }, + { + "ref": "SR-10", + "title": "Inspection of Systems or Components", + "summary": "Inspection of Systems or Components\nInspect the following systems or system components {{ one or more: at random, at {{ frequency - frequency at which to inspect systems or system components is defined (if selected); }} , upon {{ indications of need for inspection - indications of the need for an inspection of systems or system components are defined (if selected); }} }} to detect tampering: {{ systems or system components - systems or system components that require inspection are defined; }}.", + "guidance": "The inspection of systems or systems components for tamper resistance and detection addresses physical and logical tampering and is applied to systems and system components removed from organization-controlled areas. Indications of a need for inspection include changes in packaging, specifications, factory location, or entity in which the part is purchased, and when individuals return from travel to high-risk locations." + }, + { + "ref": "SR-11", + "title": "Component Authenticity", + "summary": "Component Authenticity\na. Develop and implement anti-counterfeit policy and procedures that include the means to detect and prevent counterfeit components from entering the system; and\nb. Report counterfeit system components to {{ one or more: source of counterfeit component, {{ external reporting organizations - external reporting organizations to whom counterfeit system components are to be reported is/are defined (if selected); }} , {{ personnel or roles - personnel or roles to whom counterfeit system components are to be reported is/are defined (if selected); }} }}.\nSR-11 Additional FedRAMP Requirements and Guidance Requirement: CSOs must ensure that their supply chain vendors provide authenticity of software and patches and the vendor must have a plan to protect the development pipeline.\ncontrols SR-11(1) Anti-counterfeit Training\nTrain {{ personnel or roles - personnel or roles requiring training to detect counterfeit system components (including hardware, software, and firmware) is/are defined; }} to detect counterfeit system components (including hardware, software, and firmware).\nSR-11(2) Configuration Control for Component Service and Repair\nMaintain configuration control over the following system components awaiting service or repair and serviced or repaired components awaiting return to service: all.", + "guidance": "Sources of counterfeit components include manufacturers, developers, vendors, and contractors. Anti-counterfeiting policies and procedures support tamper resistance and provide a level of protection against the introduction of malicious code. External reporting organizations include CISA." + }, + { + "ref": "SR-12", + "title": "Component Disposal", + "summary": "Component Disposal\nDispose of {{ data, documentation, tools, or system components - data, documentation, tools, or system components to be disposed of are defined; }} using the following techniques and methods: {{ techniques and methods - techniques and methods for disposing of data, documentation, tools, or system components are defined; }}.", + "guidance": "Data, documentation, tools, or system components can be disposed of at any time during the system development life cycle (not only in the disposal or retirement phase of the life cycle). For example, disposal can occur during research and development, design, prototyping, or operations/maintenance and include methods such as disk cleaning, removal of cryptographic keys, partial reuse of components. Opportunities for compromise during disposal affect physical and logical data, including system documentation in paper-based or digital files; shipping and delivery documentation; memory sticks with software code; or complete routers or servers that include permanent media, which contain sensitive or proprietary information. Additionally, proper disposal of system components helps to prevent such components from entering the gray market." + } + ] } - ] - } - ] + ] } \ No newline at end of file