removed duplicate control

Signed-off-by: Frank Suits <[email protected]>

ssp_author_demo/README.md

@@ -34,12 +34,12 @@ Profiles from NIST do not insert parameter values by default so the profile need
 
 - First the response documents must be generated using:
   - cd to the project root directory
-  - `trestle author ssp-generate -p 800-53-low --output test_system -s 'guidance:Control Guidance'`
+  - `trestle author ssp-generate -p 800-53-low --output test_system -s 'guidance:Guidance'`
   - `--output` puts the markdown directory tree into `./test_system`
   - `-s` maps named parts names to sections in catalog to the markdown document
 - Content for the implemented requirements can now be entered into the markdown for controls
 
-### Creating the OSCAL catalog
+### Creating the OSCAL System Security Plan
 
 - Run
   - `trestle author ssp-assemble -m test_system -o acme-test-system`

ssp_author_demo/test_system/ac/ac-1.md

@@ -1,12 +1,12 @@
 ---
 sort-id: ac-01
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
-# ac-1 - Access Control Policy and Procedures
+# ac-1 - \[Access Control\] Policy and Procedures
 
-## Control Description
+## Control Statement
 
 - \[a.\] Develop, document, and disseminate to All employees:
 
@@ -24,26 +24,32 @@ x-trestle-sections:
   - \[1.\] Policy Every year and following Any IT system breach involving inappropriate access management; and
   - \[2.\] Procedures every quarter and following any IT system breach or known near miss.
 
+## Control 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.
+
 ______________________________________________________________________
 
-## ac-1 What is the solution and how is it implemented?
+## What is the solution and how is it implemented?
+
+<!-- Please leave this section blank and enter implementation details in the parts below. -->
 
 ______________________________________________________________________
 
-### Part a.
+## Implementation a.
 
 ACME CISO is responsible for setting the organisation access control policies, and in The access control policies at a global level are reviewed on an annual cycle. ACME CISO also review access control policy whenever ACME legal and/or Compliance teams identify access control obligations.
 
 ______________________________________________________________________
 
-### Part b.
+## Implementation b.
 
-Add control implementation description here for statement ac-1_smt.b
+Add control implementation description here for item ac-1_smt.b
 
 ______________________________________________________________________
 
-### Part c.
+## Implementation c.
 
-Add control implementation description here for statement ac-1_smt.c
+Add control implementation description here for item ac-1_smt.c
 
 ______________________________________________________________________

ssp_author_demo/test_system/ac/ac-14.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-14
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-14 - \[Access Control\] Permitted Actions Without Identification or Authentication
@@ -12,7 +12,7 @@ x-trestle-sections:
 
 - \[b.\] Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.
 
-## Control Control Guidance
+## Control 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."
 

ssp_author_demo/test_system/ac/ac-17.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-17
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-17 - \[Access Control\] Remote Access
@@ -12,7 +12,7 @@ x-trestle-sections:
 
 - \[b.\] Authorize each type of remote access to the system prior to allowing such connections.
 
-## Control Control Guidance
+## Control 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](#ca-3). Enforcing access restrictions for remote access is addressed via [AC-3](#ac-3).
 

ssp_author_demo/test_system/ac/ac-18.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-18
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-18 - \[Access Control\] Wireless Access
@@ -12,7 +12,7 @@ x-trestle-sections:
 
 - \[b.\] Authorize each type of wireless access to the system prior to allowing such connections.
 
-## Control Control Guidance
+## Control 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.
 

ssp_author_demo/test_system/ac/ac-19.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-19
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-19 - \[Access Control\] Access Control for Mobile Devices
@@ -12,7 +12,7 @@ x-trestle-sections:
 
 - \[b.\] Authorize the connection of mobile devices to organizational systems.
 
-## Control Control Guidance
+## Control 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.
 

ssp_author_demo/test_system/ac/ac-2.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-02
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-2 - \[Access Control\] Account Management
@@ -44,7 +44,7 @@ x-trestle-sections:
 
 - \[l.\] Align account management processes with personnel termination and transfer processes.
 
-## Control Control Guidance
+## Control 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.
 

ssp_author_demo/test_system/ac/ac-20.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-20
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-20 - \[Access Control\] Use of External Systems
@@ -15,7 +15,7 @@ x-trestle-sections:
 
 - \[b.\] Prohibit the use of organizationally-defined types of external systems.
 
-## Control Control Guidance
+## Control 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).
 

ssp_author_demo/test_system/ac/ac-22.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-22
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-22 - \[Access Control\] Publicly Accessible Content
@@ -16,7 +16,7 @@ x-trestle-sections:
 
 - \[d.\] Review the content on the publicly accessible system for nonpublic information organization-defined frequency and remove such information, if discovered.
 
-## Control Control Guidance
+## Control 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](#18e71fec-c6fd-475a-925a-5d8495cf8455) 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.
 

ssp_author_demo/test_system/ac/ac-3.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-03
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-3 - \[Access Control\] Access Enforcement
@@ -10,7 +10,7 @@ x-trestle-sections:
 
 Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
 
-## Control Control Guidance
+## Control 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](#pe)) family.
 

ssp_author_demo/test_system/ac/ac-7.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-07
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-7 - \[Access Control\] Unsuccessful Logon Attempts
@@ -12,7 +12,7 @@ x-trestle-sections:
 
 - \[b.\] Automatically lock the account or node for an {{ insert: param, ac-7_prm_4 }} ; lock the account or node until released by an administrator; delay next logon prompt per {{ insert: param, ac-7_prm_5 }} ; notify system administrator; take other {{ insert: param, ac-7_prm_6 }}  when the maximum number of unsuccessful attempts is exceeded.
 
-## Control Control Guidance
+## Control 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.
 

ssp_author_demo/test_system/ac/ac-8.md

@@ -1,7 +1,7 @@
 ---
 sort-id: ac-08
 x-trestle-sections:
-  guidance: Control Guidance
+  guidance: Guidance
 ---
 
 # ac-8 - \[Access Control\] System Use Notification
@@ -23,7 +23,7 @@ x-trestle-sections:
   - \[2.\] Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and
   - \[3.\] Include a description of the authorized uses of the system.
 
-## Control Control Guidance
+## Control 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.