1. The security categorizations for the system are {confidentiality: moderate, integrity: low, availability: moderate}, resulting in a system categorization of moderate. This assessment is done by listing each information type and individually determining the highest categorization for confidentiality, integrity, and availability. Once the confidentiality, integrity, and availability factors have been categorized, the system’s overall categorization is determined by identifying the highest category of the three. This becomes the system’s categorization, as illustrated in the table below.
2. The following items should be included in the system’s description:
• Full descriptive name of the information system, including associated acronym
• Unique information system identifier (typically a number or code)
• Information system owner and authorizing official, including contact information
• Parent or governing organization that manages, owns, and/or controls the information system
• Location of the information system and environment in which the system operates
• Version or release number of the information system
• Purpose, functions, and capabilities of the information system and missions/business processes supported
• Integration of the information system into the enterprise architecture and information security architecture
• Status of the information system with respect to acquisition and/or system development life cycle
• Results of the security categorization process for the information and information system
• Types of information processed, stored, and transmitted by the information system
• Boundary of the information system for risk management and security authorization purposes
• Applicable laws, directives, policies, regulations, or standards affecting the security of the information system
• Architectural description of the information system, including network topology
• Hardware and firmware devices included within the information system
• System and applications software resident on the information system
• Hardware, software, and system interfaces (internal and external)
• Subsystems (static and dynamic) associated with the information system
• Information flows and paths (including inputs and outputs) within the information system
• Cross domain devices/requirements
• Network connection rules for communicating with external information systems
• Interconnected information systems and identifiers for those systems
• Encryption techniques used for information processing, transmission, and storage
• Cryptographic key management information (public key infrastructures, certificate authorities, etc.)
• Information system users (including organizational affiliations, access rights, privileges, and citizenship, if applicable)
• Ownership/operation of information system (e.g., government-owned, government-operated; government-owned, contractor-operated; contractor-owned, contractor-operated; nonfederal [state and local governments, grantees])
• Security authorization date and authorization termination date
• Incident response points of contact
• Other information as required by the organization
3. The following, at a minimum, should be included in the system’s registration with the organization’s portfolio management office:
• The existence of the system
• The system’s key characteristics
• The security implications to the organization
• Any other organizationally defined requirements
1. Only the common controls from the physical security group should be used for the development of this system. The common controls from the personnel group expire too soon to be used on the system; additionally, the providers have not followed the approved continuous monitoring plan, suggesting that the controls will need additional time to be reapproved. The training department does not have any documentation proving their common controls have been approved; therefore, these controls can’t be inherited.
2. The following 256 controls make up the system’s security control baseline:
3. There are several ways that a continuous monitoring strategy could be developed for this control. One way is illustrated here; however, any plan should identify how the vulnerability scanning capability could be updated. RA-5(1) The system will use a commercial automated vulnerability scanning application. The vendor selected offers automatic updating of the application based on emerging threats and discovered vulnerabilities. The organization’s vulnerability scanner will connect to the commercial vendor’s site several times a day to determine whether an update to the application is available. If an update is available, the administrator of the system will determine if the update should be implemented, and log the decision. To monitor this action, the ISSO will evaluate the vendor’s website twice a month to determine the current update. The ISSO will then inspect the scanning application and the administrator’s log to determine the current update. The system’s log should be within two weeks of the update on the vendor’s site. The application should be updated as often as is administratively possible.
4. The authorizing official (AO) or the AO’s designated representative.
There are several resources that the development team could turn to. They could use NSA standards from the NSA website at http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml, or use the DoD standards from the DISA ISE website at http://iase.disa.mil/stigs/os/windows/seven.html, as just two examples of many resources. This system would benefit from using, and will likely be required to use, the United States Government Configuration Baseline (USGCB) developed by NIST and available at http://usgcb.nist.gov/usgcb/microsoft_content.html. It is important for the developers to ensure that organizational requirements are addressed, as well.
The developers could inherit the controls and enhance them, thereby creating hybrid controls. These enhancements must be fully documented in the system’s SSP. The common control provider is responsible for maintaining the portion of the control they have been authorized to provide and the system owner is responsible for maintaining the enhancements.
1. MP-3, media marking, should be evaluated using “examine” and “interview” methods. SP 800-53A recommends the following potential assessment objectives and methods:
Examine: [SELECT FROM: Information system media protection policy; procedures addressing media labeling; physical and environmental protection policy and procedures; security plan; removable storage media and information system output; other relevant documents or records].
Interview: [SELECT FROM: Organizational personnel with information system media protection and marking responsibilities].
2. The control would be noted as not compliant with the “interview” portion of the control. In some organizations, this would be documented as a failure for the control, while others would document this as a partial failure. In either case, the SAR should define the control’s shortcomings as well as make recommendations for correction and assessor comments.
3. No. Once a finding is reported in the SAR, it must remain there. The SCA can, however, update the findings and indicate that the “interview” portion of this control is now compliant. The entire control would then be compliant as long as the “examine” portion was still acceptable.
1. The OMB requires the following items in the POA&M:
• Column 1, which identifies the type of weakness
• Column 2, which identifies the office or organization responsible for resolving the weakness
• Column 3, which defines the required funding and the source of the funding
• Column 4, which details the scheduled completion data
• Column 5, which lists key milestones and milestone completion dates
• Column 6, which lists changes to milestone dates
• Column 7, which indicates the source of the weakness
• Column 8, which indicates the status of the finding
2. NIST requires the authorization package to contain the systems security plan (SSP), the security assessment report (SAR), and the plan of action and milestones (POA&M).
3. The AO is assisted by the risk executive (function), and the senior information security officer (SISO), when making the risk-based decisions in tasks 5-3 and 5-4.
1. When deficiencies are discovered in the system, there are a number of actions that must be conducted, including beginning remediation, updating the system’s security documentation (including the SSP), and notifying the AO of the possible security implications that could impact the system’s ATO.
2. The organization’s portfolio management office should remove the information system from the organization’s portfolio management system. The system owner must take exceptional care when dealing with the information system’s media while decommissioning the system. Many organizations require media to be sanitized, destroyed, or retained when decommissioning the system. In some cases, the hardware from decommissioned systems can be reused by other organizations, including educational organizations. For this reason, donating decommissioned equipment may be part of an organization’s decommissioning plan.