NIST RMF Documentation v2.1 - 20190807

Sherlock
NIST RMF Security Documentation

v2.1 Final
7 August 2019
Sherlock NIST RMF Security Documentation August 7th, 2019
Contents
2019 NIST RMF Security Documentation...................................................................... 5
1.0 Description .......................................................................................................... 5
2.0 Overview ............................................................................................................. 5
3.0 Table of Contents ................................................................................................ 6
Access Control Policy and Procedures .......................................................................... 6
1.0 Identification and Authentication Policy ............................................................ 6
1.1 LDAP ................................................................................................................ 6
1.2 MFA ................................................................................................................. 7
1.3 Linux System Access ........................................................................................ 8
1.4 Auditing ........................................................................................................... 8
2.0 Access Control Policy .......................................................................................... 8
2.1 Roles ................................................................................................................ 9
2.2 VPN Systems ................................................................................................. 10
3.0 Access Control Procedures ........................................................................... 11
4.0 Logon Attempt Restriction ............................................................................ 12
5.0 System Use Banner ....................................................................................... 13
Account Management ................................................................................................ 14
1.0 General .............................................................................................................. 14
2.0 Account Management ...................................................................................... 15
3.0 Group Membership ........................................................................................... 16
Audit Procedures ........................................................................................................ 19
1.0 Audit and Accountability Policy ........................................................................ 19
1.1 Checklist ........................................................................................................ 19
1.2 Collection of Audit Records........................................................................... 19
2.0 Audit and Accountability Procedures ............................................................... 20
2.1 Requirements ................................................................................................ 20
3.0 Information System Auditing and Auditable Events ......................................... 21
3.1 System-Level Auditing ................................................................................... 23
3.2 AWS Auditing ................................................................................................ 33
Configuration Management........................................................................................ 37
1.0 Configuration Management Policy ................................................................... 37
NOTICE: This presentation is supplied for discussion purposes only information contained herein is proprietary and int ended exclusively for the
client or individual(s) to which it was provided. Please treat it accordingly and do not forward, republish or permit unauthorized access or disclosure
without the prior written consent. Details within this presentation may be subject to change for technical, commercial or operational reasons.
1.1 Purpose ......................................................................................................... 38

1.2 Overview ....................................................................................................... 38
1.3 Scope ............................................................................................................. 39
1.4 Operational Policy ......................................................................................... 39
1.5 Roles and Responsibilities ............................................................................. 43
1.6 Review ........................................................................................................... 44
2.0 Configuration Management Procedures .......................................................... 44
2.1 Runbook ........................................................................................................ 44
3.0 Information System Configuration Management ............................................. 45
3.1 Default Restrictions ....................................................................................... 45
Continuous Monitoring ............................................................................................... 46
1.0 Continuous Monitoring Program ...................................................................... 46
1.1 Continuous Monitoring ................................................................................. 46
2.0 Security Status Monitoring ............................................................................... 51
3.0 Information System Monitoring ....................................................................... 51
Incident Response ....................................................................................................... 53
1.0 Incident Response Policy .................................................................................. 53
2.0 Incident Response Procedures and Training .................................................... 54
3.0 Incident Response Testing and Handling .......................................................... 54
4.0 Incident Response Monitoring and Reporting .................................................. 55
5.0 Incident Response Plan ..................................................................................... 56
5.1 Incident Response Monitoring and Reporting .............................................. 56
5.2 Security Incident Checklist ............................................................................ 57
5.3 Communicating During an Incident .............................................................. 61
6.0 Followup Actions for Response Roles ............................................................... 61
6.1 Steps for Incident Commander ..................................................................... 61
6.2 Steps for Deputy ........................................................................................... 62
6.3 Steps for Scribe ............................................................................................. 62
6.4 Steps for Subject Matter Expert ................................................................... 62
6.5 Steps for Customer Liaison ........................................................................... 62
6.6 Steps for Internal Liaison .............................................................................. 62
7.0 Reviewing the Incident ..................................................................................... 62
8.0 Reviewing the Process ...................................................................................... 62

Personnel Security ...................................................................................................... 63
1.0 Separation of Duties ......................................................................................... 63
2.0 Security Awareness and Training Policy ........................................................... 63
3.0 Security Awareness and Training Procedures .................................................. 64
4.0 Security Awareness Training and Role-based Training ..................................... 64
5.0 Security Training Records ................................................................................. 65
6.0 Personnel Security Policy .................................................................................. 65
7.0 Personnel Security Procedures ......................................................................... 66
8.0 Personnel Termination or Transfer ................................................................... 66
Remote Administration ............................................................................................... 68
1.0 Remote Administration ..................................................................................... 68
1.1 Definition ...................................................................................................... 69
1.2 Requirements ................................................................................................ 69
Appendix A - Monthly Tech Checklist ......................................................................... 70
Appendix B - Exit Checklist .......................................................................................... 72
HR/Administrative................................................................................................... 72
General Technology (where applicable) ................................................................. 73
For Developers (where applicable) ......................................................................... 73
Other (where applicable) ........................................................................................ 73
Security ................................................................................................................... 74
2019 NIST RMF Security Documentation

1.0 Description
The Sherlock client has established that the Sherlock system, and ITC, should evaluate,
document, and comply with Security Controls associated to a "High" Confidentiality rating for a
system being evaluated through the Risk Management Framework (RMF) process, which is
governed by the National Institute of Standards and Technology (NIST). The model rates system
using a CIA model, Confidentiality, Integrity, and Availability. This documentation encompasses
the requirements specified as relevant during the Security Documentation meeting held in
Tampa on 26 April 2018.
2.0 Overview
ITC maintains separate Discovery environments for its commercial clients and for the Sherlock
application. These environments are hosted in Amazon AWS and are separate instances which
do not overlap. While each environment is secure and closely monitored, the security
requirements for accessing the Sherlock environment are much stricter and access is restricted
to a select few individuals, as described in Access Control Policy and Procedures. The Sherlock
AWS-hosted installations, Discovery Environment, and Secure Proxy Head Node are all hosted
within a segregated, secure enclave.
Sherlock Discovery Framework - Separation of Environments
3.0 Table of Contents
Access Control Policy and Procedures

1.0 Identification and Authentication Policy
• (CCI-001932) The organization documents an identification and authentication policy
that addresses purpose, scope, roles, responsibilities, management commitment,
coordination among organizational entities, and compliance.
• (CCI-001934) The organization documents procedures to facilitate the implementation
of the identification and authentication policy and associated identification and
authentication controls.
1.1 LDAP
1. All employees are required to authenticate for access. Primary identification and
authentication (for application-level access) occurs via LDAP. Systems using this method
of authentication include, but are not limited to:
1. Wireless network access
2. JIRA
3. Confluence
4. GitLab
5. Monitoring Systems (Sensu, Grafana, ICE)
6. ITC Mail
7. VPN access
2. LDAP uses two primary organization units (OUs) to separate access between
nontechnical and technical staff.
3. Systems are configured to only search OUs for accounts that correlate to the
appropriate level of access. For example, Grafana will only allow developer access. All
LDAP authentication requests are logged.
1.1.1 Creation of LDAP account
1. Create JIRA issue for aproval from the user's manager

2. Forward approved request to operations staff
create_user 'John Smith'

create_dev 'Yancy Fry'
3. This creates a LDIF file in the current working directory. Then execute the following (and
supply LDAP admin creds when prompted)
ldapadd -Y EXTERNAL -H ldapi:/// -f jsmith.ldif

ldapadd -Y EXTERNAL -H ldapi:/// -f yfry.ldif
4. Examine the ldif credentials file for the initial credentials. Ask
the user to change their password using pwm
1.2 MFA
1. In addition to LDAP, several systems also require additional verification of user identity:
1. GitLab requires either
1. Google Auth
2. YubiKey
2. Production VPN access requires both
1. YubiKey
2. Unique VPN Key
3. AWS accounts require
1. Password
2. YubiKey
1.3 Linux System Access
1. Access to Linux servers is granted via SSH public/private keys. SSH access is denied to
username/password credentials.
2. For system access, a JIRA issue is created and assigned to the Director of IT. Once
approved, is forwarded to operations for implementation. Public keys are configured
using salt pillars. User accounts are revoked in the same fashion, with several example
pillars available.
1.4 Auditing
1. The following account types are audited during the monthly review:
1. LDAP Accounts
2. GitLab Accounts
3. Linux User Accounts
4. AWS Accounts
5. JIRA and Confluence
6. VPN keys
2. See also Audit Procedures for more information.
2.0 Access Control Policy

• (CCI-001934) The organization documents procedures to facilitate the implementation
of the identification and authentication policy and associated identification and
authentication controls.
• (CCI-002107) The organization defines the personnel or roles to be recipients of the
access control policy necessary to facilitate the implementation of the access control
policy and associated access controls.
• (CCI-000001) The organization develops and documents an access control policy that
addresses purpose, scope, roles, responsibilities, management commitment,
• (CCI-000002) The organization disseminates the access control policy to organization-
defined personnel or roles.
• (CCI-001545) The organization defines a frequency for reviewing and updating the
access control policy. (ANNUAL)
• (CCI-000003) The organization reviews and updates the access control policy in
accordance with organization-defined frequency. (ANNUAL)
• (CCI-000225) The organization employs the concept of least privilege, allowing only
authorized accesses for users (and processes acting on behalf of users) which are
necessary to accomplish assigned tasks in accordance with organizational missions and

business functions.
• (CCI-001558) The organization defines the security functions (deployed in hardware,
software, and firmware) for which access must be explicitly authorized.
• (CCI-002221) The organization defines the security-relevant information for which
access must be explicitly authorized.
• (CCI-002222) The organization explicitly authorizes access to organization-defined
security functions.
• (CCI-002223) The organization explicitly authorizes access to organization-defined
security-relevant information.
• (CCI-000039) The organization requires that users of information system accounts or
roles, with access to organization-defined security functions or security-relevant
information, use non-privileged accounts, or roles, when accessing non-security
functions.
• (CCI-001419) The organization defines the security functions or security-relevant
information to which users of information system accounts, or roles, have access.
• (CCI-002226) The organization defines the personnel or roles to whom privileged
accounts are to be restricted on the information system.
• (CCI-002227) The organization restricts privileged accounts on the information system
to organization-defined personnel or roles.
• (CCI-002234) The information system audits the execution of privileged functions.
• (CCI-002235) The information system prevents non-privileged users from executing
privileged functions to include disabling, circumventing, or altering implemented
security safeguards/countermeasures.
1. All access controls (VPN, firewall, AWS account, or other) are audited monthly.
2. All access controls require an annual review.
3. For LDAP and Linux system accounts, see above for process and responsibilities.
Production Access
All Sherlock production access requires VPN. Additionally, ssh public/private key pairs must be
generated and distributed for system access
2.1 Roles
The following roles are defined for access to the Production environment:
Role Description Granted to

Read access and software
Application configuration Program Manager
Support (including Application Org Admin and FSR
functions as defined in the User Docs)
Application View database resources and logs for

Lead Developer
Developer debugging purposes
Application Lead Developer and
Deployments and system updates
Administrator FSR
Discovery System Spider debugging access; view spider Collections
Support log data and process information. Engineer
System-level debugging access; query
Discovery System Collections
discovery database and access system
Developer Engineer
diagnostics.
Collections
Discovery System
Deployments and system updates Engineer and
Administrator
Director of IT
2.2 VPN Systems
1. During initial onboarding, limited VPN access is granted to staff and developers for
remote access to common systems such as JIRA, Confluence, GitLab, etc.
2. Additional Access must be approved by the Director of IT
3. Sherlock Production VPN access must be approved by the Program Manager
4. Implementation completed by authorized operations engineer or Director of IT
2.2.1 VPN Systems
Routing has changed for some VPNs. production VPN (for instance, now has JIRA/Confluence
access)
Would be useful to have the common names of these VPNs listed here.
(Lots of VPN changes to come...)
2.3 AWS Account Access
1. General Account Access IAM Configuration

1. The Director of IT has root account access for all ITC Accounts
1. Root account access has 2FA enabled with an email address that is not
configured.
2. The Director of IT has administrator privilege for all ITC Accounts
3. Separate accounts are used for separate business segments; e.g. commercial
bespoke data collection projects and Sherlock collection use separate accounts.
4. Groups are created in each AWS account to grant least level of access. Examples
include:
1. Commercial data collection developers have S3 and SQS access for the
commercial data collection account
2. Sherlock developers have SQS access for the preproduction sherlock
account
5. Any IAM users, groups, or policies that are added or removed will trigger a sensu
alert until such time as the change can be reviewed and added to configuration
management
6. All AWS access must be approved by the technical lead for the project; in the
case of Sherlock, this is the FSR.
7. All IAM accounts audited monthly
2.4 Linux System Account Access
1. General Account Access

1. The FSR and Lead Developer have elevated privileges (see Application
Administrator role) on all systems via configuration management. Example:
jspraggins ALL=(ALL) NOPASSWD:ALL
2. Production Access
2.1. In addition to the above, the Lead Developer (see Application Developer role) has
limited access to analyze and diagnose application level issues.
tmarimon ALL=(ALL) NOPASSWD:/usr/bin/docker
3.0 Access Control Procedures
• (CCI-002108) The organization defines the personnel or roles to be recipients of the

procedures necessary to facilitate the implementation of the access control policy and
associated access controls.
• (CCI-000004) The organization develops and documents procedures to facilitate the
implementation of the access control policy and associated access controls.
• (CCI-001546) The organization defines a frequency for reviewing and updating the
access control procedures. (ANNUAL)
• (CCI-000006) The organization reviews and updates the access control procedures in
accordance with organization-defined frequency. (ANNUAL)
• (CCI-002360) The organization defines the conditions or trigger events requiring session
disconnect to be employed by the information system when automatically terminating a
user session.
• (CCI-002361) The information system automatically terminates a user session after
organization-defined conditions or trigger events requiring session disconnect.
• (CCI-002362) The organization defines the resources requiring information system
authentication in order to gain access.
• (CCI-000061) The organization identifies and defines organization-defined user actions

that can be performed on the information system without identification or
authentication consistent with organizational missions/business functions.
• (CCI-000232) The organization documents and provides supporting rationale in the
security plan for the information system, user actions not requiring identification and
authentication.
3.1 General Resource Access
1. All systems require credentials

1. At least LDAP or managed credentials
2. There is no anonymous access to systems
3. There is an annual review to verify that all systems require authentication
3.2 Linux System Account Restrictions
1. All systems require public/private key for SSH access

2. Hardening controls are reviewed annually
3. The following SSH configuration has been added to all systems to logout idle clients
/etc/ssh/sshd_config
ClientAliveInterval 600
ClientAliveCountMax 3
4. Username/password authentication is disabled for SSH access

5. The following SSH configuration has been added to all systems to enforce proper cipher
strength and deny password authentication
PasswordAuthentication no
Ciphers [email protected],[email protected],aes128-
[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha1,[email protected],[email protected],umac-128-
[email protected]
KexAlgorithms [email protected],diffie-hellman-groupexchange-sha256,diffie-hellman-
group14-sha1
6. The following shell configuration has been added to all systems for idle users
/etc/bash.bashrc
TMOUT=1800
readonly TMOUT
export TMOUT
4.0 Logon Attempt Restriction
• (CCI-000043) The organization defines the maximum number of consecutive invalid

logon attempts to the information system by a user during an organization-defined time
period.
• (CCI-000044) The information system enforces the organization-defined limit of
consecutive invalid logon attempts by a user during the organization-defined time
period.
• (CCI-001423) The organization defines the time period in which the organization-defined
maximum number of consecutive invalid logon attempts occur.
• (CCI-002236) The organization defines the time period the information system will
automatically lock the account or node when the maximum number of unsuccessful
attempts is exceeded.
• (CCI-002237) The organization defines the delay algorithm to be employed by the
information system to delay the next login prompt when the maximum number of
unsuccessful attempts is exceeded.
• (CCI-002238) The information system automatically locks the account or node for either
an organization-defined time period, until the locked account or node is released by an
administrator, or delays the next login prompt according to the organization-defined
delay algorithm when the maximum number of unsuccessful attempts is exceeded.
4.1 SSH/FTP/Mail Restrictions
1. fail2ban is installed on all systems via SaltStack configuration management and is part of
the common configuration that is installed everywhere during the initial configuration.
2. This service continually monitors log files for failed authentication. The following
parameters are used:
1. The service will ban after 5 failed login attempts during a 600 second window of
time
2. During this ban, a firewall block on the IP address that initiated the request is
erected
3. The firewall block will remain in effect for 600 seconds
4. A Sensu alert is generated for the Director of IT once a ban is triggered for
follow-up if required
5.0 System Use Banner
• (CCI-002247) The organization defines the use notification message or banner the
information system displays to users before granting access to the system.
• (CCI-002244) The organization-defined information system use notification message or
banner is to state that information system usage may be monitored, recorded, and
subject to audit.
banner is to state that unauthorized use of the information system is prohibited and
subject to criminal and civil penalties.

banner is to state that use of the information system indicates consent to monitoring
and recording.
1. A system banner is configured for Sherlock systems (all environments) as follows during
SSH access:
Sherlock System Banner

***************************************************************************
NOTICE TO USERS
This computer system is the private property of its owner, whether
individual, corporate or government. It is for authorized use only.
Users (authorized or unauthorized) have no explicit or implicit
expectation of privacy.
Any or all uses of this system and all files on this system may be
intercepted, monitored, recorded, copied, audited, inspected, and
disclosed to your employer, to authorized site, government, and law
enforcement personnel, as well as authorized officials of government
agencies, both domestic and foreign.
By using this system, the user consents to such interception, monitoring,
recording, copying, auditing, inspection, and disclosure at the
discretion of such personnel or officials. Unauthorized or improper use
of this system may result in civil and criminal penalties and
administrative or disciplinary action, as appropriate. By continuing to
use this system you indicate your awareness of and consent to these terms
and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the
conditions stated in this warning.
****************************************************************************
Account Management
1.0 General
• (CCI-002110) The organization defines the information system account types that
support the organizational missions/business functions.
• (CCI-002111) The organization identifies and selects the organization-defined
information system account types of information system accounts which support
organizational missions/business functions.
• (CCI-002112) The organization assigns account managers for information system
accounts.
• (CCI-002115) The organization specifies authorized users of the information system.
1. All information system access requires accounts.

2. For all information systems, users are grouped into limited or administrative account
types
3. Account management is limited to authorized personnel and is verified via JIRA issues
requesting approval for access level. For more information, see Section 1.0 of Access
Control Policy and Procedures
2.0 Account Management

• (CCI-002118) The organization specifies access authorizations (i.e., privileges) for each
account on the information system.
• (CCI-002119) The organization specifies other attributes for each account on the
information system.
• (CCI-002120) The organization defines the personnel or roles authorized to approve the
creation of information system accounts.
• (CCI-000010) The organization requires approvals by organization-defined personnel or
roles for requests to create information system accounts.
• (CCI-002121) The organization defines the procedures or conditions to be employed
when creating, enabling, modifying, disabling, and removing information system
accounts.
• (CCI-000011) The organization creates, enables, modifies, disables, and removes
information system accounts in accordance with organization-defined procedures or
conditions.
• (CCI-002126) The organization authorizes access to the information system based on a
valid access authorization.
• (CCI-002127) The organization authorizes access to the information system based on
intended system usage.
• (CCI-002128) The organization authorizes access to the information system based on
other attributes as required by the organization or associated missions/business
functions.
• (CCI-000012) The organization reviews information system accounts for compliance with
account management requirements per organization-defined frequency. (MONTHLY)
• (CCI-001547) The organization defines the frequency on which it will review information
system accounts for compliance with account management requirements. (MONTHLY)
• (CCI-000015) The organization employs automated mechanisms to support the
information system account management functions.
• (CCI-000213) The information system enforces approved authorizations for logical
access to information and system resources in accordance with applicable access
control policies.
• (CCI-002219) The organization defines the duties of individuals that are to be separated.
• (CCI-000036) The organization separates organization-defined duties of individuals.
• (CCI-001380) The organization documents separation of duties of individuals.
• (CCI-002220) The organization defines information system access authorizations to
support separation of duties.
1. Primary (or initial) access for most systems is LDAP.
1. A documented onboarding procedure is executed to establish accounts based on

designated roles.
2. SSH access to systems requires VPN access, which in turn also requires current
LDAP credentials.
3. For more information, see section 1.0 of Access Control Policy and Procedures.
2. Ticketing and documentation systems in place have several groups with levels of access
appropriate for the user.
1. JIRA and Confluence each have groups and controls to limit access to projects on
a need-to-know basis.
3. System level (SSH) access is granted with least privilege concepts.
1. Groups are assigned based on roles that only allow limited access to job
functions.
2. User and group accounts and public keys are controlled and dispersed via
configuration management.
3. sudoer rules are defined for non-administrators that only allow for
troubleshooting for applications.
4. A comprehensive exit procedure is executed for account removal.
4. Production-level access must be approved by key project personnel, as defined by the
organization.
1. Individual projects may require client approval for production access.
2. Sherlock production level access must be approved by the Program Manager.
5. For company-developed products and applications, organization members are provided
user-level accounts to only those products and environments that relate to their job
functions.
3.0 Group Membership

• (CCI-000008) The organization establishes conditions for group membership.
• (CCI-002116) The organization specifies authorized group membership on the
information system.
• (CCI-002129) The organization establishes a process for reissuing shared/group account
credentials (if deployed) when individuals are removed from the group.
1. Shared credentials are limited to specific diagnostic utilities. These utilities additionally
require individual credentials for network access. For more information, see section 2.2
of Access Control Policy and Procedures.
1. Shared credentials are rotated out as organization members exit the role or
team.
2. AWS groups are defined based on requirement and membership must be approved
1. Developers
1. The policies within this group define limited access to non-production
SQS queues and S3 bucket access
2. Administrators
1. The policies within allow full administrative access to non-production

configuration
4.0 Role Membership

• (CCI-002115) The organization specifies authorized users of the information system.
• (CCI-002113) The organization establishes conditions for role membership.
• (CCI-002117) The organization specifies authorized role membership on the information
system.
1. For more information regarding Role Membership, see section 2.1 of Access Control
Policy and Procedures.
5.0 Account Automation, Monitoring, and Notification
• (CCI-002122) The organization monitors the use of information system accounts.

• (CCI-002123) The organization notifies account managers when accounts are no longer
required.
• (CCI-002124) The organization notifies account managers when users are terminated or
transferred.
• (CCI-002125) The organization notifies account managers when individual information
system usage or need-to-know changes.
• (CCI-000016) The information system automatically removes or disables temporary
accounts after an organization-defined time period for each type of account.
• (CCI-001361) The organization defines a time period after which temporary accounts are
automatically terminated.
• (CCI-001365) The organization defines a time period after which emergency accounts
are automatically terminated.
• (CCI-001682) The information system automatically removes or disables emergency
accounts after an organization-defined time period for each type of account.
• (CCI-000017) The information system automatically disables inactive accounts after an
organization-defined time period.
• (CCI-000217) The organization defines a time period after which inactive accounts are
automatically disabled.
• (CCI-000018) The information system automatically audits account creation actions.
• (CCI-001403) The information system automatically audits account modification actions.
• (CCI-002130) The information system automatically audits account enabling actions.
• (CCI-001404) The information system automatically audits account disabling actions.
• (CCI-001405) The information system automatically audits account removal actions.
• (CCI-001683) The information system notifies organization-defined personnel or roles
for account creation actions.

for account modification actions.
for account enabling actions.
for account disabling actions.
for account removal actions.
• (CCI-002131) The organization defines the personnel or roles to be notified on account
creation, modification, enabling, disabling, and removal actions.
1. Monitoring of accounts occurs on several levels:

1. On system using auditd
2. For VPN and application access, uses standard logging
3. AWS accounts are monitored via cloudwatch and sensu
1. For each environment, a template has been created that lists all active
user accounts, groups and policies:
1. This template is controlled via configuration management and is
automatically updated
2. If there are any account changes or the template does not agree
with the current configuration, an alert is generated
3. In this way, all account actions will send a notification message to
the Director of IT
4. Human resources generates JIRA issues that are sent to account managers based
upon:
1. Transfer
2. Termination
3. A change in employees job role
4. Any other change that would require account level changes
5. Temporary accounts are generated sparingly, and are tracked via JIRA issue so
that they are removed once the temporary access is no longer required. In
production environments, on-system temporary access is never granted. As it
relates to Sherlock, ITC does not utilize temporary or emergency accounts for
access to the system.
6. All account actions are logged via auditd, including:
1. Creation
2. Modification
3. Enabling/disabling
4. Removal
7. System user account actions are currently configured via SaltStack. When
applying changes, the salt master returns all account changes while
simultaneously logging these changes.
Audit Procedures
1.0 Audit and Accountability Policy
• (CCI-001930) The organization defines the organizational personnel or roles to whom
the audit and accountability policy is to be disseminated.
• (CCI-000117) The organization develops and documents an audit and accountability
policy that addresses purpose, scope, roles, responsibilities, management commitment,
• (CCI-001832) The organization disseminates the audit and accountability policy to
organization-defined personnel or roles.
• (CCI-000119) The organization reviews and updates the audit and accountability policy
on an organization-defined frequency.
• (CCI-001569) The organization defines the frequency on which it will review and update
the audit and accountability policy.
• (CCI-001351) The organization authorizes access to management of audit functionality
to only organization-defined subset of privileged users.
• (CCI-001894) The organization defines the subset of privileged users who will be
authorized access to the management of audit functionality.
• (CCI-001910)The organization defines the personnel or roles allowed select which
auditable events are to be audited by specific components of the information system.
1.1 Checklist
1. Manual system audits and accountability are defined on the monthly checklist
1. Some tasks are defined within as quarterly or annually.
2. Each checklist item defines responsibility and a description where required.
3. Creation of the monthly checklist is simplified using a Confluence template
"Monthly Checklist" where only minor details need to be adjusted.
4. The checklist is reviewed on a semi-annual basis and adjusted accordingly.
5. Reviewing and editing the checklist is restricted to designated. Anonymous
access is prohibited.
1. Auditing of systems is limited to:
1. The Director of IT (All systems)
2. The FSR and Lead Developer (All Sherlock production)
1.2 Collection of Audit Records
1. The Director of IT and FSR coordinate to define the scope and function of the auditing
systems:
1. auditd installed on all servers.
2. Security Monkey collects all configuration changes in AWS.
3. AWS Config is used to track and report changes to a subset of technologies in

AWS:
1. S3 Bucket Access
2. Permissive Security Groups
2.0 Audit and Accountability Procedures

the audit and accountability procedures are to be disseminated.
implementation of the audit and accountability policy and associated audit and
accountability controls.
• (CCI-001834) The organization disseminates to organization-defined personnel or roles
procedures to facilitate the implementation of the audit and accountability policy and
associated audit and accountability controls.
• (CCI-000122) The organization reviews and updates the audit and accountability
procedures on an organization-defined frequency.
• (CCI-001570) The organization defines the frequency on which it will review and update
the audit and accountability procedures.
• (CCI-001848) The organization defines the audit record storage requirements.
• (CCI-000148) The organization reviews and analyzes information system audit records
on an organization defined frequency for indications of organization-defined
inappropriate or unusual activity.
• (CCI-000151) The organization defines the frequency for the review and analysis of
information system audit records for organization-defined inappropriate or unusual
activity.
• (CCI-001862) The organization defines the types of inappropriate or unusual activity to
be reviewed and analyzed in the audit records.
• (CCI-000149) The organization reports any findings to organization-defined personnel or
roles for indications of organization-defined inappropriate or unusual activity.
• (CCI-001863) The organization defines the personnel or roles to receive the reports of
organization-defined inappropriate or unusual activity.
• (CCI-001864) The organization employs automated mechanisms to integrate audit
review and analysis to support organizational processes for investigation of response to
suspicious activities.
• (CCI-001865) The organization employs automated mechanisms to integrate reporting
processes to support organizational investigation of and response to suspicious
activities.
• (CCI-000153) The organization analyzes and correlates audit records across different
repositories to gain organization-wide situational awareness.
2.1 Requirements
1. Personnel are designated (see above) for audit review and dissemination
2. Manual and automated procedures are defined in this document to enforce the audit
policy within the organization.
3. All audit policies are reviewed at least on an annual basis.
4. Audit records are stored for a minimum of 365 days for all events.
1. Some audit record types (e.g. AWS security groups) are stored for 5 years.
5. Audit records are reviewed monthly (at a minimum), and suspicious activity is alerted
and reviewed immediately (within an hour).
1. Suspicious activity detections includes, but is not limited to, the following:
1. Banned IPs
2. Port probes
3. Unusual/failed logins
4. Unusual DNS requests
5. Unusual mail volume
6. CBL (Composite Block List) changes related to the organization
6. Any unusual findings that are not explainable or possibly malicious are reported to the
Director of IT.
7. Automated systems are in place that track unusual or suspicious activity.
1. These systems are typically referred to as IDS (Intrusion Detection Systems)
1. Systems are monitored at the filesystem and network level.
2. Any unusual activity generates a notification.
3.0 Information System Auditing and Auditable Events
• (CCI-000123) The organization determines the information system must be capable of

auditing an organization-defined list of auditable events.
• (CCI-001571) The organization defines the information system auditable events.
• (CCI-000124) The organization 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.
• (CCI-000125) The organization provides a rationale for why the list of auditable events is
deemed to be adequate to support after-the-fact investigations of security incidents.
• (CCI-001485) The organization defines the events which are to be audited on the
information system on an organization-defined frequency of (or situation requiring)
auditing for each identified event.
• (CCI-001484) The organization defines frequency of (or situation requiring) auditing for
each identified event.
• (CCI-000126) The organization determines that the organization-defined subset of the
auditable events defined in AU-2 are to be audited within the information system.
• (CCI-000127) The organization reviews and updates the list of organization-defined
audited events on an organization-defined frequency.
• (CCI-001486) The organization defines a frequency for reviewing and updating the list of
organization-defined auditable events.
• (CCI-000130) The information system generates audit records containing information
that establishes what type of event occurred.
that establishes when an event occurred.
that establishes where the event occurred.
that establishes the source of the event.
that establishes the outcome of the event.
that establishes the identity of any individuals or subjects associated with the event.
• (CCI-001488) The organization defines additional, more detailed information to be
included in the audit records.
• (CCI-000135) The information system generates audit records containing the
organization-defined additional, more detailed information that is to be included in the
audit records.
• (CCI-001875) The information system provides an audit reduction capability that
supports on-demand audit review and analysis.
supports on-demand reporting requirements.
supports after-the-fact investigations of security incidents.
• (CCI-001878) The information system provides a report generation capability that
supports on-demand audit review and analysis.
supports on-demand reporting requirements.
supports after-the-fact investigations of security incidents.
• (CCI-001881) The information system provides an audit reduction capability that does
not alter original content or time ordering of audit records.
• (CCI-001882) The information system provides a report generation capability that does
not alter original content or time ordering of audit records.
• (CCI-000158) The information system provides the capability to process audit records
for events of interest based on organization-defined audit fields within audit records.
• (CCI-001883) The organization defines the audit fields within audit records to be
processed for events of interest by the information system.
• (CCI-000159) The information system uses internal system clocks to generate time
stamps for audit records.
• (CCI-001888) The organization defines the granularity of time measurement for time
stamps generated for audit records.
• (CCI-001889) The information system records time stamps for audit records that meets
organization-defined granularity of time measurement.
• (CCI-001890) The information system records time stamps for audit records that can be
mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).
• (CCI-000162) The information system protects audit information from unauthorized
access.
modification.
deletion.
• (CCI-001493) The information system protects audit tools from unauthorized access.
• (CCI-001494) The information system protects audit tools from unauthorized
modification.
• (CCI-001495) The information system protects audit tools from unauthorized deletion.
• (CCI-000169) The information system provides audit record generation capability for the
auditable events defined in AU-2-a (CCI-000123, CCI-001571) at organization defined
information system components.
• (CCI-001459) The organization defines information system components that provide
audit record generation capability.
• (CCI-000171) The information system allows organization-defined personnel or roles to
select which auditable events are to be audited by specific components of the
information system.
• (CCI-000172) The information system generates audit records for the events defined in
AU-2 d with the content defined in AU-3.
3.1 System-Level Auditing
3.1.2 auditd
1. Deployed to all systems during inception using SaltStack configuration

2. Review of auditd configuration to be completed annually at a minimum.
3. Current monitors:
1. Root command executions
1. Excludes sensu (which has a limited sudoer allowance to inspect docker
containers)
2. Excludes those executed by cron jobs (for which modification is audited)
2. Unsuccessful file events
3. Software Management
4. Privilege Abuse
5. Injection
6. Suspicious activity
7. Reconnaissance
8. Discretionary Access Control (DAC) modifications
9. Session initiation information

10. Power state
11. Process ID change (switching accounts) applications
12. Critical elements access failures
13. Systemd
14. SSH configuration
15. Postfix configuration
16. Pam configuration
17. System startup scripts
18. Network Environment
19. Login configuration and information
20. Critical account files related to security
21. Cron configuration & scheduled jobs
22. Time
23. Mount Operation
24. Kernel module loading and unloading
25. Kernel parameters
26. Itself (Audit logs and process)
4. Current running configuration (5/1/2018):
Audit.rules
audit.rules
# Remove any existing rules

-D
# Buffer Size
## Feel free to increase this if the machine panic's
-b 8192
# Failure Mode
## Possible values: 0 (silent), 1 (printk, print a failure message), 2 (panic, halt the system)
-f 1
# Ignore errors
## e.g. caused by users or files not found in the local environment
-i
# Self Auditing ---------------------------------------------------------------
## Audit the audit logs

### Successful and unsuccessful attempts to read information from the audit records
-w /var/log/audit/ -k auditlog
## Auditd configuration
### Modifications to audit configuration that occur while the audit collection functions are operating
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig
## Monitor for use of audit management tools

-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools
# Filters ---------------------------------------------------------------------
### We put these early because audit is a first match wins system.
## Ignore SELinux AVC records

-a always,exclude -F msgtype=AVC
## Ignore current working directory records

-a always,exclude -F msgtype=CWD
## Ignore EOE records (End Of Event, not needed)

-a always,exclude -F msgtype=EOE
## Cron jobs fill the logs with stuff we normally don't want (works with SELinux)
-a never,user -F subj_type=crond_t
-a exit,never -F subj_type=crond_t
# sensu and cron rules

-a exit,never -F path=/usr/bin/docker
-a exit,never -F path=/usr/sbin/rabbitmqctl
-a exit,never -F path=/usr/sbin/cron
-a exit,never -F path=/usr/sbin/dmidecode
-a never,user -F uid=sensu
-a exit,never -F uid=sensu
-a never,user -F gid=sensu
-a exit,never -F gid=sensu
-a never,user -F auid=4294967295
-a exit,never -F auid=4294967295
-a never,user -F auid=rabbitmq
-a exit,never -F auid=rabbitmq
-a never,user -F uid=rabbitmq
-a exit,never -F uid=rabbitmq
## This prevents chrony from overwhelming the logs

-a never,exit -F arch=b64 -S adjtimex -F auid=unset -F uid=root -F subj_type=chronyd_t
-a never,exit -F arch=b64 -S adjtimex -F auid=unset -Fuid=chrony -F subj_type=chronyd_t
-a never,exit -F arch=b32 -S adjtimex -F auid=unset -Fuid=chrony -F subj_type=chronyd_t
## This is not very interesting and wastes a lot of space if the server is public facing
-a always,exclude -F msgtype=CRYPTO_KEY_USER
## VMWare tools
-a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-

2
-a exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-
2
### High Volume Event Filter (especially on Linux Workstations)

-a exit,never -F arch=b32 -F dir=/dev/shm -k sharedmemaccess
-a exit,never -F arch=b64 -F dir=/dev/shm -k sharedmemaccess
#-a exit,never -F arch=b32 -F dir=/var/lock/lvm -k locklvm
#-a exit,never -F arch=b64 -F dir=/var/lock/lvm -k locklvm
## More information on how to filter events

### https://access.redhat.com/solutions/2482221
# Rules -----------------------------------------------------------------------
## Kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl
## Kernel module loading and unloading

-a always,exit -F perm=x -F auid!=-1 -F path=/sbin/insmod -k modules
-a always,exit -F perm=x -F auid!=-1 -F path=/sbin/modprobe -k modules
-a always,exit -F perm=x -F auid!=-1 -F path=/sbin/rmmod -k modules
-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules
-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules
## Modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe
## KExec usage (all actions)

-a always,exit -F arch=b64 -S kexec_load -k KEXEC
-a always,exit -F arch=b32 -S sys_kexec_load -k KEXEC
## Special files
-a exit,always -F arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F arch=b64 -S mknod -S mknodat -k specialfiles
## Mount operations (only attributable)

-a always,exit -F arch=b64 -S mount -S umount2 -F auid!=-1 -k mount
-a always,exit -F arch=b32 -S mount -S umount -S umount2 -F auid!=-1 -k mount
# Change swap (only attributable)

-a always,exit -F arch=b64 -S swapon -S swapoff -F auid!=-1 -k swap
-a always,exit -F arch=b32 -S swapon -S swapoff -F auid!=-1 -k swap
## Time
-a exit,always -F arch=b32 -S adjtimex -S settimeofday -S clock_settime -k time
-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time
### Local time zone
-w /etc/localtime -p wa -k localtime
## Stunnel
-w /usr/sbin/stunnel -p x -k stunnel
## Cron configuration & scheduled jobs

-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron
## User, group, password databases

-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd
## Sudoers file changes

-w /etc/sudoers -p wa -k actions
## Passwd
-w /usr/bin/passwd -p x -k passwd_modification
## Tools to change group identifiers

-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification
## Login configuration and information

-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login
## Network Environment
### Changes to hostname
-a always,exit -F arch=b32 -S sethostname -S setdomainname -k network_modifications
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network_modifications
### Changes to other files
-w /etc/hosts -p wa -k network_modifications
#-w /etc/sysconfig/network -p wa -k network_modifications
-w /etc/network/ -p wa -k network
#-a always,exit -F dir=/etc/NetworkManager/ -F perm=wa -k network_modifications
#-w /etc/sysconfig/network -p wa -k network_modifications
### Changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue
## System startup scripts

-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init
## Library search paths

-w /etc/ld.so.conf -p wa -k libpath
## Pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam
## Postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail
## SSH configuration
-w /etc/ssh/sshd_config -k sshd
# Systemd
-w /bin/systemctl -p x -k systemd
-w /etc/systemd/ -p wa -k systemd
## SELinux events that modify the system's Mandatory Access Controls (MAC)
-w /etc/selinux/ -p wa -k mac_policy
## Critical elements access failures

-a exit,always -F arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileaccess
-a exit,always -F arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileaccess
## Process ID change (switching accounts) applications

-w /bin/su -p x -k priv_esc -F uid!=sensu -F auid!=sensu
-w /usr/bin/sudo -p x -k priv_esc -F uid!=sensu -F uid!=rabbitmq -F auid!=sensu -F auid!=rabbitmq
-w /etc/sudoers -p rw -k priv_esc
## Power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power
## Session initiation information

-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
## Discretionary Access Control (DAC) modifications

-a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 -F uid!=sensu -k perm_mod
# Special Rules ---------------------------------------------------------------
## 32bit API Exploitation

### If you are on a 64 bit platform, everything _should_ be running
### in 64 bit mode. This rule will detect any use of the 32 bit syscalls
### because this might be a sign of someone exploiting a hole in the 32
### bit API.
-a always,exit -F arch=b32 -S all -k 32bit_api
## Reconnaissance
-w /usr/bin/whoami -p x -k recon
-w /etc/issue -p r -k recon
-w /etc/hostname -p r -k recon
## Suspicious activity
-w /usr/bin/wget -p x -k susp_activity
-w /usr/bin/curl -p x -k susp_activity
-w /usr/bin/base64 -p x -k susp_activity
-w /bin/nc -p x -k susp_activity
-w /bin/netcat -p x -k susp_activity
-w /usr/bin/ncat -p x -k susp_activity
-w /usr/bin/ssh -p x -k susp_activity
-w /usr/bin/socat -p x -k susp_activity
-w /usr/bin/wireshark -p x -k susp_activity
-w /usr/bin/rawshark -p x -k susp_activity
-w /usr/bin/rdesktop -p x -k sbin_susp
## Sbin suspicious activity

-w /sbin/iptables -p x -k sbin_susp
-w /sbin/ifconfig -p x -k sbin_susp
-w /usr/sbin/tcpdump -p x -k sbin_susp
-w /usr/sbin/traceroute -p x -k sbin_susp
## Injection
### These rules watch for code injection by the ptrace facility.
### This could indicate someone trying to do something bad or just debugging
-a always,exit -F arch=b32 -S ptrace -k tracing
-a always,exit -F arch=b64 -S ptrace -k tracing
-a always,exit -F arch=b32 -S ptrace -F a0=0x4 -k code_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k code_injection
-a always,exit -F arch=b32 -S ptrace -F a0=0x5 -k data_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k data_injection
-a always,exit -F arch=b32 -S ptrace -F a0=0x6 -k register_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k register_injection
## Privilege Abuse
### The purpose of this rule is to detect when an admin may be abusing power by looking in user's home
dir.
-a always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=4294967295 -C auid!=obj_uid -k power_abuse
# Software Management ---------------------------------------------------------
# RPM (Redhat/CentOS)
-w /usr/bin/rpm -p x -k software_mgmt
-w /usr/bin/yum -p x -k software_mgmt
# YAST (SuSE)
-w /sbin/yast -p x -k yast
-w /sbin/yast2 -p x -k yast
# DPKG / APT-GET (Debian/Ubuntu)

-w /usr/bin/dpkg -p x -k software_mgmt
-w /usr/bin/apt-add-repository -p x -k software_mgmt
-w /usr/bin/apt-get -p x -k software_mgmt
-w /usr/bin/aptitude -p x -k software_mgmt
# Special Software ------------------------------------------------------------
## GDS specific secrets

#-w /etc/puppet/ssl -p wa -k puppet_ssl
## IBM Bigfix BESClient

#-a exit,always -F arch=b64 -S open -F dir=/opt/BESClient -F success=0 -k soft_besclient
#-w /var/opt/BESClient/ -p wa -k soft_besclient
## CHEF https://www.chef.io/chef/
-w /etc/chef -p wa -k soft_chef
# High volume events ----------------------------------------------------------
## Remove them if the cause to much volumen in your einvironment
## Root command executions

-a exit,always -F arch=b64 -F euid=0 -S execve -F uid!=sensu -F gid!=sensu -F auid!=sensu -F
auid!=4294967295 -k rootcmd
-a exit,always -F arch=b32 -F euid=0 -S execve -F uid!=sensu -F gid!=sensu -F auid!=sensu -F
auid!=4294967295 -k rootcmd
## File Deletion Events by User

-a always,exit -F arch=b32 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F
auid!=4294967295 -k delete
-a always,exit -F arch=b64 -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F
auid!=4294967295 -k delete
## File Access
### Unauthorized Access (unsuccessful)
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F
exit=-EACCES -F auid>=500 -F auid!=4294967295 -k file_access
exit=-EPERM -F auid>=500 -F auid!=4294967295 -k file_access
exit=-EACCES -F auid>=500 -F auid!=4294967295 -k file_access
exit=-EPERM -F auid>=500 -F auid!=4294967295 -k file_access
### Unsuccessful Creation

#-a always,exit -F arch=b32 -S creat,link,mknod,mkdir,symlink,mknodat,linkat,symlinkat -F exit=-EACCES -k
file_creation
#-a always,exit -F arch=b64 -S mkdir,creat,link,symlink,mknod,mknodat,linkat,symlinkat -F exit=-EACCES -k
file_creation
#-a always,exit -F arch=b32 -S link,mkdir,symlink,mkdirat -F exit=-EPERM -k file_creation
#-a always,exit -F arch=b64 -S mkdir,link,symlink,mkdirat -F exit=-EPERM -k file_creation
### Unsuccessful Modification

-a always,exit -F arch=b32 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S
removexattr -S lremovexattr -F exit=-EACCES -k file_modification
removexattr -S lremovexattr -F exit=-EACCES -k file_modification
removexattr -S lremovexattr -F exit=-EPERM -k file_modification
removexattr -S lremovexattr -F exit=-EPERM -k file_modification
# https://confluence.vkportal.com/display/IO/PAI+Assessment Rules
# Configure the audit system to generate an audit event for any successful/unsuccessful use of the
"chcon" command.
-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
# Verify that an audit event is generated for any successful/unsuccessful use of the
"pam_timestamp_check" command.
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k
privileged-pam_timestamp_check
# Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command.
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-
crontab
# Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command.
-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage
# Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command.
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-
gpasswd
# Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update"
command.
-a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-
unix-update
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
to use the "chacl" command occur.
-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
to use the "setfacl" command occur.
-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
to use the "apparmor_parser" command occur.
-a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k
perm_chng
to use the "newgrp" command occur.
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
to use the "chsh" command occur.
-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
to use the "sudoedit" command occur.
-a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
# Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command.
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
to use the "ssh-keysign" command occur.
-a always,exit -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k
privileged-ssh
to use the "ssh-agent" command occur.
-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh
# Verify that an audit event is generated for any successful/unsuccessful use of the "chfn" command.
-a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd
5. Audit log files on system are only accessible by root (rw).

6. The auditd process is monitored by sensu and will alert if not running
7. Each audit event captures at least the following information:
1. Type of event
2. Time
3. Outcome
4. Source
5. Identity
8. Example of an audit event. In this case, a privileged user (auid=1050) assumes root and
executes a command.
Command Executed
cat /var/log/audit/audit.log
1. The log entries for the action are as follows:

auditd logs
type=SYSCALL msg=audit(1525280975.629:859): arch=c000003e syscall=59 success=yes exit=0

a0=17a2c08 a1=15a3348 a2=1596008 a3=7ffd4ad37720 items=2 ppid=15730 pid=15777
auid=1050 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=77 comm="cat"
exe="/bin/cat" key="rootcmd" type=EXECVE msg=audit(1525280975.629:859): argc=2 a0="cat"
a1="/var/log/audit/audit.log" type=PATH msg=audit(1525280975.629:859): item=0
name="/bin/cat" inode=262273 dev=ca:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
nametype=NORMAL type=PATH msg=audit(1525280975.629:859): item=1 name="/lib64/ldlinux-
x86-64.so.2" inode=405256 dev=ca:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
nametype=NORMAL type=SYSCALL msg=audit(1525280975.629:860): arch=c000003e syscall=2
success=yes exit=3 a0=7ffdd7904945 a1=0 a2=1fffffffffff0000 a3=7ffdd79024e0 items=1
ppid=15730 pid=15777 auid=1050 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=77 comm="cat" exe="/bin/cat" key="auditlog" type=PATH
msg=audit(1525280975.629:860): item=0 name="/var/log/audit/audit.log" inode=300319
dev=ca:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
3.2 AWS Auditing
3.2.1 AWS Auditing
1. Auditing of Amazon Web Services (as it relates to our organization) is coordinated with
the following technologies:
1. IAM (Identity and Access Management)
2. Cloudtrail Logs
1. Parsed by AWS Config
3. Security Monkey
3.2.2 IAM
1. AWS Identity and Access Management (IAM) is a web service used to securely control
access to AWS resources. IAM is used to control who is authenticated (signed in) and
authorized (has permissions) to use resources.
2. Monthly review of all IAM resources is initiated to verify:
1. Current user accounts
2. Proper group membership
3. Role permissions
4. Policies
5. Root account uses MFA token
6. All user accounts with console access to AWS resources uses MFA token.
3.2.3 AWS Config
1. AWS Config provides a detailed view of the resources associated with an AWS account,
including how they are configured, how they are related to one another, and how the
configurations and their relationships have changed over time.
2. Each account utilizes AWS Config to verify a subset of controls that require a routine
audit:
1. Permissive security group access
1. 0.0.0.0/0
1. Port 20 TCP
2. Port 21 TCP
3. Port 22 TCP
4. Port 3306 TCP
5. Port 3389 TCP
6. Port 4333 TCP
2. S3 Bucket Public Read Access
1. Includes AWS and anonymous access
3. S3 Bucket Public Write Access
1. Includes AWS and anonymous access
3. Example Dashboard
4. Example Ruleset
3.2.4 Security Monkey
1. Security Monkey monitors AWS and/or GCP accounts for policy changes and alerts on
insecure configurations. It provides a single UI to browse and search through accounts,
regions, and cloud services. The monkey remembers previous states and can show you
exactly what changed, and when.
2. Our organization scans all AWS accounts using this tool for a comprehensive view of our
cloud infrastructure.
3. The following AWS technologies are tracked and audited using this tool:
Technology
iamgroup iamssl elasticsearchservice networkacl flowlog
subnet s3 rdssecuritygroup sqs lambda
iamrole acm cloudtrail kms config
iamuser elb sns configrecorder routetable

vpc route53 ses subnet rdssubnetgroup
ec2instance dhcp rdsdbinstance endpoint route53domains
networkinterface ec2image rdsdbcluster alb ebssnapshot
ebsvolume keypair peering rdssnapshot natgateway
rdsclustersnapshot elasticip
1. Every configuration change is traced and can be readily audited:

Example Security Group State
{ "arn": "arn:aws:ec2:us-east-1:xxxxxxxxx:security-group/sg-axxxxxxxx", "assigned_to": [ {

"instance_id": "i-xxxxxxxx", "Name": "xxxxxxx" } ], "description": "allow xxx openvpn", "id": "sg-
xxxxxxxx", "name": "xxxxxxxx", "owner_id": "xxxxxxxx", "region": "us-east-1", "rules": [ {
"rule_type": "ingress", "from_port": 1194, "ip_protocol": "udp", "to_port": 1194, "owner_id":
null, "group_id": null, "cidr_ip": "xxxxxxxx/32", "name": null }, { "rule_type": "ingress",
"from_port": 1194, "ip_protocol": "udp", "to_port": 1194, "owner_id": null, "group_id": null,
"cidr_ip": "xxxxxxxx/32", "name": null }, { "rule_type": "ingress", "from_port": 1194,
"ip_protocol": "udp", "to_port": 1194, "owner_id": null, "group_id": null, "cidr_ip":
"xxxxxxxx/32", "name": null }, { "rule_type": "ingress", "from_port": 1194, "ip_protocol": "udp",
"to_port": 1194, "owner_id": null,
"group_id": null, "cidr_ip": "xxxxxxxx/32", "name": null }, { "rule_type": "ingress", "from_port":
1194, "ip_protocol": "udp", "to_port": 1194, "owner_id": null, "group_id": null, "cidr_ip":
"xxxxxxxx/32", "name": null }, { "rule_type": "ingress", "from_port": 1194, "ip_protocol": "udp",
"to_port": 1194, "owner_id": null, "group_id": null, "cidr_ip": "xxxxxxxx/32", "name": null } ],
"vpc_id": "vpc-xxxxxxxx"}
2. In addition, the tool includes auditing tools that we utilize monthly (at
minimum):
Configuration Management
1.0 Configuration Management Policy
• (CCI-001821) The organization defines the organizational personnel or roles to whom the
configuration management policy is to be disseminated.
• (CCI-000287) The organization develops and documents a configuration management policy that
• (CCI-001822) The organization disseminates the configuration management policy to organization
• (CCI-000289) The organization reviews and updates, on an organization defined frequency,
the configuration management policy.
• (CCI-000286) The organization defines a frequency to review and update the configuration
management policies.
Note: The ITC Configuration Management Policy is derived from the CMS Policy for
Configuration Management document, April 2012
1.1 Purpose
1. Configuration Management (CM) is a discipline to ensure that the configuration of an item (and its
components) is known and documented, and that all subsequent changes to it are
controlled and tracked. The goals of using CM are to ensure the integrity of a product
and to make its evolution more manageable. Effective CM imposes control over the
activities that require the updating and using of multiple versions of project artifacts.
1.2 Overview
1. IEEE standard 729-1983 for Configuration Management and the Information

Technology Infrastructure Library (ITIL) Framework both highlight four classic operational
aspects of CM:
1. Identification: An identification scheme is needed to reflect the structure of the
product. This involves identifying the structure and kinds of components, making
them unique and accessible in some form by giving each component a name,
version identification, and configuration identification.
2. Control: Control the release of a product and changes to it throughout the
life cycle by having controls in place that ensure consistent software via the
creation of a baseline product, an approval mechanism for changing baselines,
and access control mechanisms that ensures changes are only made by
authorized personnel/processes. This often involves implementing policies and
processes to manage change both internally within the performing organization
as well as change requests coming from external sources such as client requests
and regulatory changes.
3. Status: Record and report the status of components and change requests
and gathering vital statistics about the product.
4. Audit/Review: Validate the completeness of a product and maintain consistency

throughout the entire project life cycle to ensure that the product is maintained
as a well-defined collection of components.
1.3 Scope
1. This policy applies to all IT activities and IT assets owned or controlled by ITC, including
those of ITC's agents, contractors or other business partners when acquired or supported by ITC
funding. As such, this policy applies to all hardware, software, supporting infrastructure (e.g.,
equipment, networks, and operating systems), services, and associated documentation regardless of
origin, nature, or location (e.g., contractor, in-house, development, operations, all hosting data
centers, internal and external systems) unless otherwise specified.
1.4 Operational Policy
1. CM Planning & Management

1. All tasks necessary to implement CM principles and to conduct configuration
activities shall be planned, coordinated, and managed throughout all lifecycle
phases of a project, product, or automated system.
1. ITC incorporates Configuration Management tasks as part of the normal
daily workflow, utilizing several tools which automate the CM process
throughout the lifecycle of the program.
2. The CM Planning process shall be fully documented, and the documentation
readily available to all levels of development, implementation, and operations
management to formalize involvement and ensure continuity of CM practices.
1. The CM planning process is documented within this document.
2. Configuration Identification - Configuration identification is the process of identifying
and documenting the functional and physical characteristics of items that are to be
placed under configuration control.
1. Configuration identification includes the selection of CIs, determination of the
types of configuration documentation required for each CI, the assignment of
unique identifiers to eac CI and the technical documentation describing its
configuration, and the establishment of configuration baselines.
1. All system-level configuration changes shall be managed using SaltStack
1. Documentation is available
at https://docs.saltstack.com/en/latest/ref/states/all/
2. A hierarchical structure shall be established that identifies and summarizes the
CIs comprising a given project, product, or automated system. Configuration
identification shall be maintained and readily available to all CMS decision
makers.
1. The hierarchical structure for CIs exists as part of the SaltStack and GitLab
implementation.
3. Configuration Control / Change Management - Configuration control consists of the
evaluation, coordination, approval or disapproval, and implementation of changes to CIs
after formal establishment of their configuration identification. Effective configuration

control depends on placing products under control and on establishing mechanisms for
controlling changes to the products.
1. A systematic and measurable change process and procedures shall be
implemented that is consistent with industry best practices and CMS' CM policy,
CMSRs, and standards.
1. All changes are tracked through a dedicated, organization-managed
installation of GitLab.
2. Repositories for system-level configuration are available as follows:
1. Primary SaltStack configuration, including "common" states
deployed to all systems is contained in infrastructure/salt-states
2. Sherlock-specific configuration is contained in sherlock/sherlock-
formula
3. Sensu-specific configuration is contained in sensu-salt
3. Repository access and access level are only granted on an as-needed
basis.
1. Global repository owner permissions are only granted for the
following users:
1. Lead Developer
2. Director of IT
3. FSR
4. VP of Technology
2. Guest and reporter roles (i.e. read-only) are granted to project
stakeholders within the organization.
3. Developer and master roles are granted to developers and
operations team roles as required.
2. The implemented change process and procedures shall ensure proposed changes
are properly identified, prioritized, documented, coordinated, evaluated, and
adjudicated.
1. A JIRA integration has been configured within GitLab which will link JIRA
issues back to configuration changes within GitLab.
Example:
3. Approved changes shall be properly documented, implemented, verified and

tracked to ensure incorporation in all applicable system and/or products.
1. Once changes have been approved and merged into GitLab, the changes
are rolled out in the following manner:
1. Whether changes are limited to a single role or the entire farm,
stepping the changes through the environments in the following
manner is a requirement:
1. The development (dev) environment is changed first only.
2. Following proper verification of development, the stage
environment is updated.
3. For Sherlock, following verification on stage, the alpha
4. For Sherlock, following verification on alpha, the preview
5. Following verification of stage, the production
environment(s) is/are finally changed
6. For any global configuration changes, all affected
personnel will be notified when changes are occurring and
in what environment.
1. A brief description of the change shall be given,
and the corresponding JIRA issue shall be noted.
2. For any changes that affect all systems, a reasonable delay shall
be build in when moving from the environment.
1. For a change that is fixing a production issue affecting
clients, the change will be shortened to a small windows in
which testing shall occur.
2. In general, we target a minimum of two days between

environments as a precaution in the event of any
unintended consequence of changes.
4. Changes identified during ongoing maintenance of products/systems operating
in production are cycled forward into new business needs for appropriate
analysis and consideration prior to modification of existing, or development of
new, products/systems in response to requested changes. These changes are
tracked in a Trouble Ticket System coordinated between ITC FSRs and the end
users.
5. The Sherlock program also leverages a Configuration Change Control Board (CCB)
at the client level for requirements changes.
4. Configuration Status Accounting - Configuration status accounting focuses on recording
and reporting information needed to maintain integrity and traceability of a controlled
CI and its associated documentation throughout its life cycle. This includes monitoring
the status of proposed changes and the implementation status of approved
changes. Status accounting information includes developing and maintaining site
configuration data and the incorporation of modification data on products and CIs.
1. Configuration status accounting information shall be developed and maintained
for CIs in a systematic and disciplined manner in accordance with this policy,
CMSRs, and CMS' CM standards, processes and procedures.
2. This configuration information must be available for use by CMS decision makers
over the life cycle of a project, product, or automated system and its identified
CIs.
1. Configuration Status accounting is persisted through the tools described
earlier (SaltStack, Terraform, Gitlab).
5. Configuration Audits
1. Configuration audits shall be performed to verify that a product's requirements
have been met and that the product design meeting those requirements has
been accurately documented before a product configuration is baselined or is
migrated to the production environment.
1. ITC undertakes a final Developmental Testing phase with JITC and a
subsequent Acceptance Test phase with the client to ensure the
application successfully meets the requirements and intent. Once the
application is accepted, the final Release Candidate is deployed to the
production environment(s).
2. In addition, developmental and operation systems shall be periodically
reconciled against their documentation to ensure consistency between a
product and its current baseline documentation.
1. Each Release Candidate includes an updated version of the user
documentation. This is validated during the Developmental and
Acceptance testing.
3. Verification of the incorporation of modifications is a critical function of this
activity. Periodic audits of software and hardware configuration baselines in the
production environment shall be performed to ascertain that no unauthorized

changes have been made without proper approval.
1. Several common states are currently automated and deploy at the
following intervals:
1. Sensu (updated daily)
2. Common scripts (updated hourly)
3. Any failures of the automated scripts is logged and reported on
the sendu dashboard. Example:
2. During routine or out-of-band system patching for security or reliability

issues, the patching script will automatically run the common state
before patching, to verify that the baseline system configuration is up to
date.
1. The patching script will fail if the baseline is not brought in line
with the current configuration. Since the system will not be
patched at this point, other Sensu monitoring will flag this as so,
and it can be investigated and rectified. Example:
1.5 Roles and Responsibilities
1. The following entities have responsibilities related to the implementation of this policy:
1. Chief Technology Officer (CTO) - The CTO is responsible for the following
activities:
1. Providing leadership and direction regarding establishment,
implementation, and administration of a viable CM Program for the ITC
enterprise; and
2. Assisting ITC System Owners/Managers in understanding their CM
responsibilities and ensuring that they incorporate an acceptable level of
configuration control into their projects, products, tools, and automated
systems.
2. System Developers and the Operations team are responsible for the following
activities:
1. Configuring the information system to provide only essential capabilities
and specifically disabling, prohibiting, or restricting the use of system
services, ports, network protocols, and capabilities that are not explicitly
requires for system or application functionality. A list of specifically

needed system services, ports, network protocols, and capabilities that
are not explicitly required for system or application functionality. A list of
specifically needed system services, port, and network protocols will be
maintained and documented in the Information System Description of
the Security Plan (SP); all others will be disabled. For more information
on this, reference the Access Control Policy and Procedures section.
2. Ensuring that CM activities are planned, coordinated, implemented, and
managed for IT projects, products, or automated systems under their
control in accordance with ITC CM policy, processes, procedures, and
standards established within the ITC Expedited Life Cycle (XLC);
3. Contributing to the identification and control of CIs associated with their
IT projects, products, or automated systems;
4. Ensuring baseline configurations are adequately documented and
maintained;
5. Classifying and analyzing change requests and problem reports;
6. Providing configuration status accounting reports to the appropriate
personnel to report up-to-date status of baselined deliverables; and
7. Participating in configuration audits.
1.6 Review
1. All policies will be reviewed and adjusted if applicable on an annual basis.
2.0 Configuration Management Procedures

the configuration management procedures are to be disseminated.
implementation of the configuration management policy and associated configuration
management controls.
• (CCI-001825) The organization disseminates to organization defined personnel or roles
the procedures to facilitate the implementation of the configuration management policy
and associated configuration management controls.
• (CCI-000292) The organization reviews and updates, on an organization defined
frequency, the procedures to facilitate the implementation of the configuration
management policy and associated configuration management controls.
• (CCI-001584) The organization defines the frequency to review and update
configuration management procedures.
2.1 Runbook
1. Documentation has been created for the operations team covering all of the
information systems. This documentation contains stub pages, detailing the roles and
procedures, including configuration management, for ITC's information systems.
1. This documentation shall be disseminated to system and application engineers.
2. The documentation is to be reviewed and updated (at a minimum) annually.
3.0 Information System Configuration Management

• (CCI-000380) The organization defines for the information system prohibited or
restricted functions, ports, protocols, and/or services.
• (CCI-000381) The organization configures the information system to provide only
essential capabilities.
• (CCI-000382) The organization configures the information system to prohibit or restrict
the use of organization-defined functions, ports, protocols, and/or services.
• (CCI-000384) The organization reviews the information system per organization defined
frequency to identify unnecessary and nonsecure functions, ports, protocols, and
services.
• (CCI-001760) The organization defines the frequency of information system reviews to
identify unnecessary and/or nonsecure functions, ports, protocols, and services.
• (CCI-001761) The organization defines the functions, ports, protocols and services
within the information system that are to be disabled when deemed unnecessary
and/or nonsecure.
• (CCI-001762) The organization disables organization-defined functions, ports, protocols,
and services within the information system deemed to be unnecessary and/or
nonsecure.
• (CCI-001592) The organization defines the rules authorizing the terms and conditions of
software program usage on the information system.
3.1 Default Restrictions
1. Accounts - For all systems, system accounts that have no use are removed. These
include, but are not limited to:
1. games
2. news
3. irc
2. System Packages - For all systems, system packages that have no use are
removed. These include, but are not limited to:
1. ftp
2. telnet
3. postfix
4. xinetd
5. inetd
6. tftp-server
7. ypserv
8. rsh-serv
3. Networking - Using Terraform, AWS security groups are configured as follows:
1. All ingress and egress ports are restricted by default
2. Only ports and protocols required for system and application functionality are
allowed to ingress and egress via AWS security groups (i.e. firewall)
1. Ingress and egress rules are limited to:
1. Private CIDR ranges whenever possible
2. Associated security groups (that define exact target systems to
allow access)
4. Review - Monthly audits are conducted to access any unnecessary access
Continuous Monitoring
1.0 Continuous Monitoring Program
• (CCI-000274) The organization develops a continuous monitoring strategy.
• (CCI-002087) The organization establishes and defines the metrics to be monitored for
the continuous monitoring program.
• (CCI-002088) The organization establishes and defines the frequencies for continuous
monitoring.
• (CCI-002089) The organization establishes and defines the frequencies for assessments
supporting continuous monitoring.
• (CCI-000279) The organization implements a continuous monitoring program that
includes ongoing security control assessments in accordance with the organizational
continuous monitoring strategy.
1. (CCI-002091) The organization implements a continuous monitoring program that

includes correlation and analysis of security-related information generated by
assessments and monitoring.

includes response actions to address results of the analysis of security-related
information.
includes reporting the security status of organization and the information system to
organization-defined personnel or roles on an organization-defined frequency.
1.1 Continuous Monitoring
1. Continuous monitoring is deployed and implemented using as many available tools on

system via Amazon Web Services (AWS). On-system and AWS monitoring utilizes the
tools described in this section
1.1.1 Sensu Monitoring Framework
1. Verifies essential security-related processed (e.g. auditd) are running, in addition to

application and availability checks
2. All configuration related to Sensu alerts are contained within the sensu-
salt/tree/master/salt/sensu/etc/master
1. Example check configuration:
auditd watcher
2. "auditd-process": {
3. "command": "/etc/sensu/vkplugins/plugins/processes/checkprocs.
4. rb -p sbin/auditd -W 1",
5. "subscribers": [
6. "fw1.sherlocksecure",
7. "sherlock",
8. "salt.master",
9. "vpn.sherlock",
10. "vpn.vkgreenbottle"
11. ],
12. "handlers": ["sensu-alerts"],
13. "interval": 500,
14. "refresh": 7200,
15. "occurrences": 2
}
3. Sensu updates are automatically deployed to the senu server every 10 minutes after
commiting to git.
4. Sensu plugin updates are deployed automatically to all systems daily
1. Configuration includes:
1. Plugins from public sources, available here: sensu-
salt/tree/master/salt/sensu/vkplugins/plugins
2. Plugins privately developed within ITC, available here: sensu-
salt/tree/master/salt/sensu/vkplugins
3. The following privately-developed script to verify running kernel is
approved (and current):
4. #!/bin/bash
5. # Check if uptime and approved kernels are OK
6. ApprovedKernels="
7. 4.4.0-124-generic
8. 4.4.0-125-generic
9. 4.4.0-1055-aws
10. 4.4.17-v7+
11. "
12. UPTIME=`uptime | cut -d ',' -f 1 | cut -d ' ' -f 4 | sed
13. 's/:.*//'`
14. if [ -z "$UPTIME" ]
15. then
16. UPTIME=0
17. fi
18. if [ $UPTIME -gt 180 ]
19. then
20. echo "Uptime: $UPTIME"
21. exit 1
22. fi
23. RunningKernel=$(uname -r)
24. if grep -q $RunningKernel <<<$ApprovedKernels
25. then
26. echo "Kernel: $RunningKernel -- Uptime: $UPTIME"
27. else
28. echo "$RunningKernel is out of date"
29. exit 1
30. fi
exit 0
5. All critical alerts are stored in ELK for 365 days.

6. Essential system-related metrics are forwarded to Graphite.
7. Log files are monitored for keywords indicating security-related events:
1. fail2ban triggers
2. Authentication failures
3. AIDE changes
https://access.redhat.com/documentation/enus/red_hat_enterprise_linux/7/ht
ml/security_guide/sec-using-aide
4. ClamAV events
5. Application stack traces (that could indicate compromise)
8. System health checks are also monitored, as follows:
1. Verifies kernel (patching) is current, and that uptime isn't beyond a
preconfigured threshold
2. Verified user accounts do not contain passwords (unless authorized)
3. Verifies cron jobs have not failed
4. Verifies root uid
5. Verifies that there are no empty passwords set
System health script, run by cron hourly and returned to sensu
6. #!/bin/bash
7. # Return syshealth info to sensu (passive checks)
8. # Check status of croncheck output. Return results to sensu
9. results=$(mktemp)
10. for croncheckdir in `ls /var/spool/cron/crontabs`
11. do
12. scandirectory=$(eval echo ~$croncheckdir/croncheck)

13. for croncheckfile in `test -d $scandirectory && find
14. $scandirectory -type f`
15. do
16. if [ -s $croncheckfile ]
17. then
18. cat $croncheckfile >> $results
19. fi
20. done
21. done
22. rootuidcheck=$(awk -F: '($3=="0"){print}' /etc/passwd)
23. if [[ "$rootuidcheck" == "root:x:0:0:root:/root:/bin/bash" ]]
24. then
25. :
26. else
27. echo "$rootuidcheck :Root UID Check" >> $results
28. fi
29. #check for empty passwords
30. emptypasscheck=$(cat /etc/shadow | awk -F: '($2==""){print $1}')
31. if [[ ! -z $emptypasscheck ]]
32. then
33. echo "$emptypasscheck : Empty Password" >> $results
34. fi
35. #check for existing passwords
36. userpasswords=$(awk -F":" '($2 != "!" && $2 != "*") {print $1}'
37. /etc/shadow)
38. if [[ ! -z $userpasswords ]]
39. then
40. echo "$userpasswords : User has Password" >> $results
41. fi
42. #report to sensu - listens on 3030
43. if [ -s $results ]
44. then
45. echo '{"name": "syshealth", "ttl": 86400, "output": "'"`cat
46. $results`"'", "status": 1}' > /dev/tcp/localhost/3030
47. cat $results
48. else
49. echo '{"name": "syshealth", "ttl": 86400, "output": "OK", "status":
50. 0}' > /dev/tcp/localhost/3030
51. fi
rm $results
52. The system is configured to send notification and has a dashboard available for
analysis. Security-related events are sent to a private channel with limited
access.
53. Any security-related issues are reported to the lead technical stakeholder, in
addition to creation of JIRA issue for tracking and review.
1. For Sherlock, the lead technical manager.
9. There are currently over 400 unique checks deployed across all systems. Depending on
the role, 15-50 checks are used each individual server.
10. Example of events monitored for an application server:
11. In addition, several types of security events are coordinated and monitored within AWS,
including but not limited to:
1. Overly permissive security groups and/or S3 buckets,
2. AWS Config
1. AWS Config provides a detailed view of the resources associated with
your AWS account, including how they are configured, how they are
related to one another, and how the configurations and their
relationships have changed over time.
3. Any AWS account, group, or policy changes
1.1.2 fail2ban
1. Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the
malicious signs – too many password failures, seeking for exploits, etc. Typically,
Fail2ban is used to update firewall rules to reject the IP addresses for a specified
amount of time; however, any arbitrary other action (e.g. sending an email) could also
be configured. Fail2ban includes build-in filters for various services (apache, courier,
ssh, etc).
1.1.3 ClamAV
1. ClamAV is an open source antivirus engine for detecting trojans, viruses, malware &
other malicious threats.
1.1.4 AIDE
1. AIDE (Advanced Intrusion Detection Environment) is a file and directory integrity

checker.
1.1.5 osquery
1. Osquery uses basic SQL commands to leverage a relational data-model to describe a

device.
1.1.6 auditd
1. Continuous logging of all system calls and classification of important events.

1. Configuration available: See Audit Procedures Section 3.1.2
2. The auditd process is watched via sensu and will alert if not running
1.1.7 AWS GuardDuty
1. Amazon GuardDuty is a managed threat detection service that continuously monitors

for malicious or unauthorized behavior to help protect AWS accounts and workloads. It
monitors for activity such as unusual API calls or potentially unauthorized deployments
that indicate a possible account compromise. GuardDuty also detects potentially
compromised instances or reconnaissance by attackers.
2.0 Security Status Monitoring

includes ongoing security status monitoring of organization-defined metrics in
accordance with the organizational continuous monitoring strategy.
• (CCI-000281) The organization defines the frequency to report the security status of
organization and the information system to organization-defined personnel or roles.
• (CCI-001581) The organization defines personnel or roles to whom the security status of
organization and the information system should be reported.
See part 1.0 of the section.
3.0 Information System Monitoring
• (CCI-001253) The organization defines the objectives of monitoring for attacks and
indicators of potential attacks on the information system.
• (CCI-002641) The organization monitors the information system to detect attacks and
indicators of potential attacks in accordance with organization-defined monitoring
objectives.
• (CCI-002642) The organization monitors the information system to detect unauthorized
local connections.
network connections.
remote connections.
• (CCI-002645) The organization defines the techniques and methods to be used to
identify unauthorized use of the information system.
• (CCI-002646) The organization identifies unauthorized use of the information system
through organization-defined techniques and methods.
• (CCI-001255) The organization deploys monitoring devices strategically within the
information system to collect organization determined essential information.
• (CCI-001256) The organization deploys monitoring devices at ad hoc locations within the
system to track specific types of transactions of interest to the organization.
• (CCI-002647) The organization protects information obtained from intrusion-monitoring
tools from unauthorized access.
tools from unauthorized modification.
tools from unauthorized deletion.
• (CCI-001257) The organization 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.
• (CCI-002650) The organization defines the information system monitoring information
that is to be provided the organization-defined personnel or roles.
• (CCI-002651) The organization defines the personnel or roles that are to be provided
organization-defined information system monitoring information.
• (CCI-002652) The organization defines the frequency at which the organization will
provide the organization-defined information system monitoring information to
organization-defined personnel or roles
• (CCI-002654) The organization provides organization-defined information system
monitoring information to organization-defined personnel or roles as needed or per
organization-defined frequency.
• (CCI-002655) The organization connects individual intrusion detection tools into an
information system-wide intrusion detection system.
• (CCI-001260) The organization employs automated tools to support near real-time
analysis of events.
• (CCI-002659) The organization defines the frequency on which it will monitor inbound
communications for unusual or unauthorized activities or conditions.
• (CCI-002660) The organization defines the frequency on which it will monitor outbound
communications for unusual or unauthorized activities or conditions.
• (CCI-002661) The information system monitors inbound communications traffic per
organization-defined frequency for unusual or unauthorized activities or conditions.
• (CCI-002662) The information system monitors outbound communications traffic per
organization-defined frequency for unusual or unauthorized activities or conditions.
• (CCI-001264) The organization defines indicators of compromise or potential
compromise to the security of the information system which will result in information
system alerts being provided to organization-defined personnel or roles.
• (CCI-002663) The organization defines the personnel or roles to receive information
system alerts when organization-defined indicators of compromise or potential
compromise occur.
• (CCI-002664) The information system alerts organization-defined personnel or roles
when organization-defined compromise indicators reflect the occurrence of a
compromise or a potential compromise.
See part 1.0 of this section
Incident Response
1.0 Incident Response Policy
• (CCI-002776) The organization defines the personnel or roles to whom the incident
response policy is disseminated.
• (CCI-000805) The organization develops and documents an incident response policy that
• (CCI-000806) The organization disseminates an incident response policy to organization-
• (CCI-000808) The organization defines the frequency to review and update the current
incident response policy.
• (CCI-000807) The organization reviews and updates the current incident response policy
in accordance with organization-defined frequency.
1. The Incident Response policy is defined within this page.

2. This policy will be disseminated to the following roles:
1. CTO
2. Vice President of Engineering
3. Lead Systems Engineer
4. Facility Security Officer
5. Limited Project-defined Stakeholders
2.0 Incident Response Procedures and Training

• (CCI-002777) The organization defines the personnel or roles to whom the incident
response procedures are disseminated.
implementation of the incident response policy and associated incident response
controls.
• (CCI-000810) The organization disseminates incident response procedures to
incident response procedures.
• (CCI-000811) The organization reviews and updates the current incident response
procedures in accordance with organization-defined frequency.
• (CCI-002778) The organization defines the time period in which information system
users whom assume an incident response role or responsibility receive incident
response training.
1. The procedures defined within this page.

2. This set of procedures will be disseminated to the following roles:
1. CTO
3.0 Incident Response Testing and Handling

• (CCI-000818) The organization tests the incident response capability for the information
system on an organization-defined frequency using organization-defined tests to
determine the incident response effectiveness.
• (CCI-000819) The organization defines a frequency for incident response tests.
• (CCI-000820) The organization defines tests for incident response.
• (CCI-001624) The organization documents the results of incident response tests.
• (CCI-002780) The organization coordinates incident response testing with organizational
elements responsible for related plans.
• (CCI-000822) The organization implements an incident handling capability for security
incidents that includes preparation, detection and analysis, containment, eradication,
and recovery.
• (CCI-000824) The organization incorporates lessons learned from ongoing incident
handling activities into incident response procedures, training, and testing/exercises.
• (CCI-001625) The organization implements the resulting incident handling activity

changes to incident response procedures, training and testing/exercise accordingly.
• (CCI-000825) The organization employs automated mechanisms to support the incident
handling process.
1. ITC employs automated mechanisms to support the incident handling process, which
are defined within the documentation (e.g. Audit Procedures)
2. ITC will conduct Incident Response tests on an annual basis.
3. Incident response tests include, but are not limited to:
1. VPN penetration
2. SSH / privileged access training
3. Container escapes
4. Results of incident response tests will be logged as a JIRA issue within the restricted-
access SECURITY project in the same manner as an actual test.
4.0 Incident Response Monitoring and Reporting

• (CCI-000832) The organization tracks and documents information system security
incidents.
• (CCI-000834) The organization defines a time period for personnel to report suspected
security incidents to the organizational incident response capability.
• (CCI-000835) The organization requires personnel to report suspected security incidents
to the organizational incident response capability within the organization-defined time
period.
• (CCI-000836) The organization reports security incident information to organization-
defined authorities.
• (CCI-002791) The organization defines authorities to whom security incident
information is reported.
• (CCI-000837) The organization employs automated mechanisms to assist in the
reporting of security incidents.
• (CCI-000839) 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.
• (CCI-000840) The organization employs automated mechanisms to increase the
availability of incident response-related information and support.
1. ITC reports incidents to:

1. CEO
2. CTO
5.0 Incident Response Plan

• (CCI-002794) The organization develops an incident response plan.
• (CCI-002795) The organization's incident response plan provides the organization with a
roadmap for implementing its incident response capability.
• (CCI-002796) The organization's incident response plan describes the structure and
organization of the incident response capability.
• (CCI-002797) The organization's incident response plan provides a high-level approach
for how the incident response capability fits into the overall organization.
• (CCI-002798) The organization's incident response plan meets the unique requirements
of the organization, which relate to mission, size, structure, and functions.
• (CCI-002799) The organization's incident response plan defines reportable incidents.
• (CCI-002800) The organization's incident response plan provides metrics for measuring
the incident response capability within the organization.
• (CCI-002801) The organization's incident response plan defines the resources and
management support needed to effectively maintain and mature an incident response
capability.
• (CCI-002802) The organization defines personnel or roles to review and approve the
incident response plan.
• (CCI-000844) The organization develops an incident response plan that is reviewed and
approved by organization-defined personnel or roles.CCI-000845 The organization
defines incident response personnel (identified by name and/or by role) and
organizational elements to whom copies of the incident response plan is distributed.
• (CCI-000846) The organization distributes copies of the incident response plan to
organization-defined incident response personnel (identified by name and/or by role)
and organizational elements.
• (CCI-000847) The organization defines the frequency for reviewing the incident
response plan.
• (CCI-000848) The organization reviews the incident response plan on an organization-
defined frequency.
• (CCI-000849) The organization updates the incident response plan to address
system/organizational changes or problems encountered during plan implementation,
execution, or testing.
• (CCI-002803) The organization defines incident response personnel (identified by name
and/or by role) and organizational elements to whom the incident response plan
changes will be communicated.
• (CCI-000850) The organization communicates incident response plan changes to
organization-defined incident response personnel (identified by name and/or by role)
and organizational elements.
• (CCI-002804) The organization protects the incident response plan from unauthorized
disclosure and modification.
5.1 Incident Response Monitoring and Reporting
1. Suspected security incidents are to be reported from operations to the incident

commander within 30 minutes of discovery.
5.2 Security Incident Checklist
1. Details for each of these items are available in the next section.
1. Attack Mitigation: Stop the attack in progress.
2. Cut off the attack vector.
3. Create JIRA issue for documentation.
4. Assemble the response team.
5. Isolate affected instances.
6. Identify timeline of attack.
7. Identify compromised data.
8. Access risk to other systems.
9. Assess risk of re-attack.
10. Apply additional mitigations, additions to monitoring, etc.
11. Forensic analysis of compromised systems.
12. Internal communication.
13. Involve law enforcement.
14. Reach out to external parties that may have been used as vector for attack.
15. External communication.
2. This checklist is to be reviewed annually.
5.2.1 Attack Mitigation
1. Stop the attack as quickly as you can, via any means necessary. Shut down servers,
network isolate them, and turn off a data center if necessary.
2. Some common things to try include:
1. Shutdown the instance from the provider console (avoid detection or
termination unless necessary, as we'll need to do forensics).
2. If access to the affected box is still possible, attempt the following:
1. Re-instate our default iptables rules to restrict traffic.
2. kill any active session you suspect is an attacker using the following:
1. kill -9
3. Change root password, and update /etc/shadow to lock out all other
users.
4. sudo shutdown now
5.2.2 Cut Off Attack Vector
1. Identify the likely attack vectors and path; fix them so they cannot be re-exploited
immediately after stopping the attack.
2. If you suspect a third-party provider is compromised, delete all accounts except your
own (and those of others who are physically present) and immediately rotate your
password and MFA tokens.
3. If you suspect a service application was an attack vector, disable any relevant code
paths, or shut down the service entirely.
5.2.3 Create JIRA Issue
1. This documentation should be severely limited in access, so verify that you use the
SECURITY project when creating the issue.
2. Communicate the JIRA issue ID to the response team.
3. Assign predefined watchers to the issue so they receive real-time updates.
5.2.4 Assemble Response Team
1. Identify key responders for the security incident, and keep them all in the loop. Set up a
secure method of communicating all information associated with the incident. Details
on the incident (or the fact that an incident has occurred) should be kept private to the
responders until you are confident the attack is not being triggered internally.
2. Page an Incident Commander if not already done so. They will also appoint the usual
incident command roles. The incident command team will be responsible for keeping
documentation of actions taken, and for notifying internal stakeholders as appropriate.
3. Give the project an innocuous codename that can be used for chats/documents so if
anyone overhears they don't realize it's an security incident (.e.g. sapphire-unicorn).
4. Start the voice call if not already in progress.
5. Set up chat room using the codename of the incident.
6. Invite all responders to the voice call and chat room.
1. The security team should always be included.
2. A representative for any affected services should be included.
3. Executive stakeholders and legal counsel should be invited at earliest possible
opportunity, but prioritize operational responders first.
7. Do not communicate with anyone not on the response team about the incident until
forensics has been performed. The attack could be happening internally.
8. Prefix all emails, and chat topics with "Attorney Work Project".
5.2.5 Isolate Affected Instances
1. Any instances that were affected by the attack should be immediately isolated from any
other instances. As soon as possible, an image of the system should be taken and put
into a read-only cold storage for later forensic analysis.
2. Blacklist the IP addresses for any affected instances from all other hosts.
3. Turn off and shutdown the instances immediately (if not already done to cease the
attack).
4. Take a disk image for any disk attached to the instances, and ship them to an off-site
cold storage location. Make sure these images are read-only and cannot be tampered
with.
5.2.6 Identify Timeline of Attack
1. Work with all tools at your disposal to identify the timeline of the attack, along with
exactly what the attacker did:
1. Any reconnaissance the attacker performed on the system before the attack
started.
2. When the attacker gained access to the system.
3. What actions the attacker performed on the system, and when.
4. Identify how long the attacker had access to the system before they were
detected, and before they were kicked out.
5. Identify any queries the attacker ran on databases.
6. Try to identify if the attacker still has access to the system via another back
door. Monitor logs for unusual activity.
5.2.7 Compromised Data
1. Using forensic analysis of log files, time-series graphs, and any other information/tools
at your disposal, attempt to identify what information was compromised (if any).
2. Identify what data was compromised during the attack
1. Was any data exfiltrated from a database?
2. What keys were on the system that are not considered compromised?
3. Was the attacker able to identify other components of the system (map out the
network, etc)?
3. Find exactly what customer data has been compromised, if any.
5.2.8 Assess Risk
1. Based on the data that was compromised, assess the risk to other systems:
1. Does the attacker have enough information to find another way in?
2. Were any password or keys stored on the host? If so, should they be considered
compromised, regardless of how they were stored?
3. Any user accounts that were used in the initial attack should rotate all of their
keys and passwords on every other system they have an account.
5.2.9 Apply Additional Mitigations
1. Start applying mitigations to other parts of your system:

1. Rotate any compromised data.
2. Identify any new alerting which is needed to notify of a similar breach.
3. Block any IP addresses associated with the attack.

4. Identify any keys/credentials that are compromised and revoke their access
immediately.
5.2.10 Forensic Analysis
1. Once you are confident the systems are secured, and enough monitoring is in place to
detect another attack, you can move onto the forensic analysis stage.
1. Take any read-only images you created, any access logs you have, and comb
through them for more information about the attack.
2. Identify exactly what happened, how it happened, and how to prevent it in the
future.
3. Keep track of all IP Addresses involved in the attack.
4. Monitor logs for any attempt to regain access to the system by the attacker.
5.2.11 Internal Communication
1. Delegate to: CTO or VP of Engineering

2. Communicate internally once you are confident (via forensic analysis) that the attack
was not sourced internally:
1. Don't go into too much detail.
2. Overview the timeline.
3. Discuss mitigation steps taken.
4. Follow up with more information once it is known.
5.2.12 Liaise With Law Enforcement / External Actors
1. Delegate to: CTO or VP of Engineering

2. Work with law enforcement to identify the source of the attack, letting any system
owners know that systems under their control may be compromised, etc.
1. Contact local law enforcement.
2. Contact FBI.
3. Contact operators for any systems used in the attack, their systems may also
have been compromised.
4. Contact security companies to help in assessing risk and any PR next steps.
5. Contact cyber insurance provider.
5.2.13 External Communication
1. ITC communicates incidents to designated external stakeholders on a project-specific

basis.
2. Once you have validated all of the information you have is accurate, have a timeline of
events, and know exactly what information was compromised, how it was
compromised, and sure that it won't happen again. Only then should you prepare and
release a statement to customers informing them of the compromised information and
any steps they need to take.
1. Include the date in the title of any announcement, so that it's never confused for
a potential new breach.
2. Don't say "We take security very seriously"; It makes everyone cringe when they
read it.
3. Be honest, accept responsibility, and present the facts, along with exactly how
we plan to prevent such things in the future.
4. Be as detailed as possible with the timeline.
5. Be as detailed as possible in what information was compromised, and how it
affects customers. If we were storing something we shouldn't have been, be
honest about it; It'll come out later and it'll be much worse.
6. Don't name and shame any external parties that might have caused the
compromise; It's bad form (unless they've already publicly disclosed, in which
case we can link to their disclosure).
7. Release the external communication as soon as possible, preferably within a few
days of the compromise. The longer we wait, the worse it will be.
8. If possible, get in touch with customers' internal security teams before the
general notice is sent.
5.3 Communicating During an Incident
1. Prefer voice call and private chat system over any other methods.
2. Avoid email, but if you absolutely need to for some reason:
1. Subject of emails should be "Attorney Work Project" and nothing else.
2. If email chain has ANY contacts not with the @itc-data domain, make sure your
emails are encrypted.
3. Do not use SMS to communicate about the incident.
1. The only exception is to tell someone to move to a more secure channel (e.g.
"Please join the private chat ASAP").
4. Do not disseminate anything about the incident to those outside the response team
until you have the approval to do so.
6.0 Followup Actions for Response Roles

1. In addition to any direct follow-up items generated from an incident, each of our
response roles will have a few standard follow-up tasks. These are generally actions to
ensure we organize information and follow-up with customers appropriately.
6.1 Steps for Incident Commander
1. Update the incident in JIRA.
1. Group any related incidents under the primary incident.

2. Set the final severity of the incident.
3. Resolve the incident
2. Create the post-mortem, and assign an owner to the post-mortem for the incident.
3. Send out an internal email to the relevant stakeholders explaining that we had an
incident, provide a link to the post-mortem.
4. Occasionally check on the progress of the post-mortem to ensure that it is completed
within the desired time frame.
6.2 Steps for Deputy
1. There are no additional steps after an incident is resolved. However, the IC may ask for
your help with their steps.
6.3 Steps for Scribe
1. Review the chat communications and extract any relevant items from key events.
2. Collect all "TODO" items and add them to the post-mortem.
6.4 Steps for Subject Matter Expert
1. Add any notes you deem relevant to the post-mortem.
6.5 Steps for Customer Liaison
1. Reply to any customer enquiries received about the incident.

2. Follow the post-mortem progress, and update the external message once it is available.
6.6 Steps for Internal Liaison
1. There are no additional steps after an incident is resolved. However, the IC may ask for
your help with answering questions from internal stakeholders.
7.0 Reviewing the Incident

1. It's important that we review the incident in detail to determine exactly what went
wrong, why it went wrong, and what we can do to make sure it doesn't happen again.
These take many names; after-action reviews, incident review, follow-up review, etc.
We use the term post-mortem.
8.0 Reviewing the Process
1. As well as reviewing the incident, it's important to review our process. Did we handle
the incident well, or are there things we could have done better?
Personnel Security
1.0 Separation of Duties
• (CCI-002219) The organization defines the duties of individuals that are to be separated.
• (CCI-000036) The organization separates organization-defined duties of individuals.
• (CCI-001380) The organization documents separation of duties of individuals.
• (CCI-002220) The organization defines information system access authorizations to
support separation of duties.
Documentation for separation of duties, roles, and requirements are defined within Exit
Procedure.
2.0 Security Awareness and Training Policy

• (CCI-002048) The organization defines the personnel or roles to whom the security
awareness and training policy is disseminated.
• (CCI-000100) The organization develops and documents a security awareness and
training policy that addresses purpose, scope, roles, responsibilities, management
commitment, coordination among organizational entities, and compliance.
• (CCI-000101) The organization disseminates a security awareness and training policy to
• (CCI-000102) The organization reviews and updates the current security awareness and
training policy in accordance with organization-defined frequency.
• (CCI-001564) The organization defines the frequency of security awareness and training
policy reviews and updates.
1. ITC defines ALL company personnel as receivers of the Security Awareness and Training
policy and procedures.
2. On an annual basis, each individual is required to complete the Operational Security and
Insider Threat Awareness courses.
3. Roles are defined as members of ITC or not.
4. The Opsec/Insider Threat courses are Online Courses created by DSS (Defense Security
Service). These courses are updated according to DSS' scheduled updates.
5. ITC also provides an internal training PowerPoint, which is updated on an as-needed
basis (minimum annually in coordination with online courses.).
6. DSS Security Audits hold ITC accountable as an organization for keeping up with the
security training. ITC submits an internal vulnerability analysis to DSS on an as-needed
basis, following DSS-mandated procedures.
3.0 Security Awareness and Training Procedures

• (CCI-002049) The organization defines the personnel or roles to whom the security
awareness and training procedures are disseminated.
implementation of the security awareness and training policy and associated security
awareness and training controls.
• (CCI-000104) The organization disseminates security awareness and training procedures
to organization-defined personnel or roles.
• (CCI-000105) The organization reviews and updates the current security awareness and
training procedures in accordance with organization-defined frequency.
• (CCI-001565) The organization defines the frequency of security awareness and training
procedure reviews and updates.
See section 1.0 of this section.
4.0 Security Awareness Training and Role-based Training

• (CCI-001480) The organization defines the frequency for providing refresher security
awareness training to all information system users (including managers, senior
executives, and contractors).
• (CCI-000106) The organization provides basic security awareness training to information
system users (including managers, senior executives, and contractors) as part of initial
training for new users.
• (CCI-000112) The organization provides basic security awareness training to information
system users (including managers, senior executives, and contractors) when required by
information system changes.
• (CCI-001479) The organization provides refresher security awareness training to all
information system users (including managers, senior executives, and contractors) in
accordance with the organization-defined frequency.
• (CCI-002055) The organization includes security awareness training on recognizing and
reporting potential indicators of insider threat.
• (CCI-000108) The organization provides role-based security training to personnel with
assigned security roles and responsibilities before authorizing access to the information
system or performing assigned duties
• (CCI-000109) The organization provides role-based security training to personnel with
assigned security roles and responsibilities when required by information system
changes.
• (CCI-000110) The organization provides refresher role-based security training to

personnel with assigned security roles and responsibilities in accordance with
organization-defined frequency.
• (CCI-000111) The organization defines a frequency for providing refresher role-based
security training.
1. ITC provides refresher security awareness and role-based training yearly in accordance
with DSS policies.
2. Security training is provided to all employees during the onboarding process.
5.0 Security Training Records

• (CCI-000113) The organization documents individual information system security
training activities, including basic security awareness training and specific information
system security training.
• (CCI-000114) The organization monitors individual information system security training
activities, including basic security awareness training and specific information system
security training.
• (CCI-001336) The organization retains individual training records for an organization-
defined time period.
• (CCI-001337) The organization defines a time period for retaining individual training
records.
1. ITC conducts and monitors security awareness training and specific information system
security training to relevant roles/individuals with access to the information system.
2. ITC maintains training records of the OpSec/Insider Threat Awareness training for 5
years.
6.0 Personnel Security Policy

• (CCI-003017) The organization defines the personnel or roles to whom a personnel
security policy is disseminated.
• (CCI-001504) The organization develops and documents a personnel security policy that
• (CCI-001505) The organization disseminates a personnel security policy to organization-
personnel security policy.
• (CCI-001506) The organization reviews and updates the current personnel security
policy in accordance with organization-defined frequency.
1. ITC provides employment agreements, policies, and NDAs to ensure personnel security
is maintained.
2. All employees of ITC sign the employment agreement and policies.
3. The personnel security policy is updated on an annual basis.
7.0 Personnel Security Procedures

• CCI-003018 The organization defines the personnel or roles to whom the personnel
security procedures are disseminated.
• CCI-001509 The organization develops and documents procedures to facilitate the
implementation of the personnel security policy and associated personnel security
controls.
• CCI-001510 The organization disseminates personnel security procedures to
• CCI-001508 The organization defines the frequency to review and update the current
personnel security procedures.
• CCI-001511 The organization reviews and updates the current personnel security
procedures in accordance with organization-defined frequency.
1. ITC provides employment agreements, policies, and NDAs to ensure personnel

security is maintained.
2. All employees of ITC sign the employment agreement and policies.
3. The personnel security policy is updated on an annual basis.
8.0 Personnel Termination or Transfer

• (CCI-003022) The organization defines the time period to disable information system
access upon termination of individual employment.
• (CCI-001522) The organization, upon termination of individual employment, disables
information system access within organization-defined time period.
• (CCI-003023) The organization, upon termination of individual employment,
terminates/revokes any authenticators/credentials associated with the individual.
• (CCI-003024) The organization defines information security topics to be discussed while
conducting exit interviews.
• (CCI-001523) The organization, upon termination of individual employment, conducts
exit interviews that include a discussion of organization-defined information security
topics.
• (CCI-001524) The organization, upon termination of individual employment, retrieves all
security-related organizational information systems-related property.
• (CCI-001525) The organization, upon termination of individual employment, retains
access to organizational information formerly controlled by terminated individual.
• (CCI-001526) The organization, upon termination of individual employment, retains

access to organizational information systems formerly controlled by terminated
individual.
• (CCI-003025) The organization defines personnel or roles to notify upon termination of
individual employment.
• (CCI-003026) The organization defines the time period in which to notify organization-
defined personnel or roles upon termination of individual employment.
• CCI-003016) The organization, upon termination of individual employment, notifies
organization-defined personnel or roles within an organization-defined time period.
• (CCI-001527) The organization 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.
• (CCI-001528) The organization initiates organization-defined transfer or reassignment
actions within an organization-defined time period following the formal personnel
transfer action.
• (CCI-001529) The organization defines transfer or reassignment actions to initiate within
an organization-defined time period following the formal personnel transfer action.
• (CCI-001530) The organization defines the time period within which the organization
initiates organization-defined transfer or reassignment actions, following the formal
personnel transfer action.
• (CCI-003031) The organization modifies access authorization as needed to correspond
with any changes in operational need due to reassignment or transfer.
• (CCI-003032) The organization notifies organization-defined personnel or roles within an
organization-defined time period when individuals are transferred or reassigned to
other positions within the organization.
• (CCI-003033) The organization defines personnel or roles to be notified when individuals
are transferred or reassigned to other positions within the organization.
• (CCI-003034) The organization defines the time period within which organization-
defined personnel or roles are to be notified when individuals are transferred or
reassigned to other positions within the organization.
1. Documentation for personnel termination, roles, and requirements are defined with
ITC's Exit Procedure.
2. The following personnel are notified in termination within 1 day prior to termination
notice:
1. CEO
2. CTO
3. CFO
4. HR Director
5. Facilities Security Officer
6. Direct supervisor of employee
3. Exit interviews are performed by the HR director and the employee's supervisor.
4. Any employees who held DoD clearance status are required to undergo SF-312
debriefing.
5. ITC repossesses employee laptops and organizational accounts immediately; email
accounts are forwarded to a designated receiver for continuous monitoring after the
termination completes.
6. ITC removes access to all information systems at or prior to the time of termination.
7. ITC actively monitors and permits physical area access based on the need of the
individual and their role, and reviews this on a yearly basis. Upon termination, these
accesses are revoked.
8. ITC does not perform personnel transfers (e.g., transferring one person from one
classified area to another) and is not creating or maintaining classified material.
Remote Administration
1.0 Remote Administration
• (CCI-000063) The organization defines allowed methods of remote access to the
information system.
• (CCI-002310) The organization establishes and documents usage restrictions for each
type of remote access allowed.
• (CCI-002311) The organization establishes and documents configuration/connection
requirements for each type of remote access allowed.
• (CCI-002312) The organization establishes and documents implementation guidance for
each type of remote access allowed.
• (CCI-000065) The organization authorizes remote access to the information system prior
to allowing such connections
• (CCI-000067) The information system monitors remote access methods.
• (CCI-002314) The information system controls remote access methods.
• (CCI-000068) The information system implements cryptographic mechanisms to protect
the confidentiality of remote access sessions.
• (CCI-001453) The information system implements cryptographic mechanisms to protect
the integrity of remote access sessions.
• (CCI-001561) The organization defines managed access control points for remote access
to the information system.
• (CCI-002315) The organization defines the number of managed network access control
points through which the information system routes all remote access.
• (CCI-000069) The information system routes all remote accesses through organization-
defined number managed network access control points.
• (CCI-000070) The organization authorizes the execution of privileged commands via
remote access only for organization-defined needs.
• (CCI-002316) The organization authorizes the access to security-relevant information via
remote access only for organization-defined needs.
• (CCI-002317) The organization defines the operational needs when the execution of
privileged commands via remote access is to be authorized.
• (CCI-002318) The organization defines the operational needs when access to security-
relevant information via remote access is to be authorized.
• (CCI-002319) The organization documents in the security plan for the information
system the rationale for authorization of the execution of privilege commands via
remote access.
• (CCI-002320) The organization documents in the security plan for the information
system the rationale for authorization of access to security-relevant information via
remote access.
1.1 Definition
For the purposes of this document, Remote Administration is defined as: access by users (or
information systems) communicating external to an information system security perimeter.
1.2 Requirements
1. Remote access connections shall be established exclusively via encrypted

communications.
1. openvpn is required for all environments for any and all remote administration.
1. Modern ciphers are required (i.e. AES-256) for transports.
2. VPN configuration is to be reviewed annually.
3. An 8-hour limit is enforced.
4. Security configuration is defined in the VPN Systems section of Access
Control Policy and Procedures.
5. Implementation guidance is documented in VPN Ops.
2. SSH is required for system access.
1. A 30-minute idle timeout has been configured on all systems.
2. A 4096-bit key length is required for RSA key pairs.
3. Telnet access is forbidden.
2. Remote access connections shall be established via two-factor authentication where
one of the factors is provided by a hardware device separate from the computer gaining
access.
3. Documentation for security-relevant information can only be accessed via VPN or within
the office.
Appendix A - Monthly Tech Checklist

Item Description
Update projects for new
Projects
month
ITC-Controlled Sites Update ITC-controlled sites
Update Budget Alarms All in FW1 Account
Check active accounts, ssh keys. Remove accounts as
appropriate
Linux Accounts
pwck -r, 'grep sshd.\*Failed /var/log/auth.log', etc.
find . -name "PCF*.pem"
Jenkins Accounts
appropriate
Gitlab Accounts
appropriate
Linux Logs Check system log files for any security-related issues
EBS Snapshots Verify EBS Snapshots, add new systems as appropriate
Examine the retention date and creation of the RDS
RDS Snapshots
snapshots
Security Groups Audit security groups
Review employee access is appropriate in each
Account Access
environment
AWS Accounts Audit AWS accounts / review access keys
LDAP Remove LDAP accounts
Review security patches. Action to be taken on any
Patching
critical-rated vulnerabilities
IDS Review IDS logs
Verify route53 zone file backups are working
Route53 Backup On salt master:

salt 'util*' cmd.run 'ls -lt /opt/bin/route53/exports/ |
head'
JIRA / Confluence Verify incoming/outgoing mail is functional

DNS Verify DNS config on minions until integrated into salt
GitLab Backup Verify gitlab backup on system and S3 bucket
Verify elasticsearch backups are functioning for stage,
Hothand ES Backup
RND, and production
AWS Reserved Instance Review utilization report in hothand, sherlock, and FW1
Utilization accounts
Inspector Security Audit Run AWS inspector on public webs
Update AMI Verify the Owner is 099720109477
Audit no inappropriate public buckets (create / use audit
S3 bucket permissions
tool)
Scan internal network, locate any system without
firewall enabled
Must scan from 43 and 200 VLANs at minimum
Internal Scan Create JIRA issue if any open ports 22, or any network
equipment is open
where it should not be. This is to be done before any
other checklist item
Software Audit Review software installed on users’ laptops
ARP Entries Check observium for arp error messages
Observium errors Check observium for errors
Dropped packets Check smokeping for packet loss
Switches Review switch configuration, error counts
Dump config and copy to filer for switches, wireless,
Config Dump firewall.
Keep old configs for historical purposes.
Firewall Review firewall configuration, logs
Firewall Apply latest firewall config to backup firewall
AWS Windows Servers Review windows logs, firewall configuration.
(BSCC Environment) Quarterly updates (coordinate with George).
Create JIRA issue and assign before making any changes.
AP
Rotate guest Wi-Fi password (if needed).
AP Review wifi configuration, logs

AP Rotate RADIUS Shared Secret
Review Microsoft, Apple, application security patches
Software Update
Action to be taken on any critical-rated vulnerabilities
Review all UPS devices - verify no battery replacements
Battery Backups
are required
Battery Backups Clear events from UPS
Ping the NTP servers from WLC to verify they are
NTP Servers
available
Test failover of our internet connection (early AM -
Failover
announce)
Audit JIRA and
Review all active users on JIRA and Confluence
Confluence users
Test WIN MAC filtering (verify unapproved device cannot
AP
login)
Appendix B - Exit Checklist

Standard procedure for anyone leaving the company.
HR/Administrative
1. Exit Interview
2. Remove from United's Health & Vision Plan
3. Remove from Delta Dental
4. Remove from Life Insurance
5. Send Cobra
6. Provide information for 401k rollover
7. Notify finance, remove from payroll
8. Collect any outstanding expense reimbursements needed
9. Update last day in master census
10. Send helpdesk request to remove tech access
All IT systems must be revoked in a timely manner
Major authentication systems are to be disabled within 15 minutes of employee termination
General Technology (where applicable)

1. Disable JIRA Access
2. Disable Confluence Access
3. Office 365 License
4. Revoke access to OwnCloud; Share files with: _________
5. Disable Slack Access
6. ITC Email (archive mailbox and place in backups folder, delete account, create distro
forwarder) Forward emails to: _______
7. Remove User from the GAL (Intermedia > Users > username > Advanced Settings > Hide
from Address Book and uncheck)
8. Remove account from distribution lists.
9. Delete LDAP Entry (disabled within 15 minutes of employee termination)
10. Remove VPN (disabled within 15 minutes of employee termination)
11. Remove VPN access to datacenter (disabled within 15 minutes of employee
termination)
12. Remove database access (pristine, etc.) (disabled within 15 minutes of employee
termination)
13. Disable SSO (disabled within 15 minutes of employee termination)
14. Remove access to designated internal products/applications.
15. Remove DB Access
16. Recover laptop and equipment
For Developers (where applicable)

1. Remove JetBrains Pycharm license
2. Remove entry from npm (devpi:/home/sinopia/sinopia/config.yaml)
3. Remove from Gitlab groups, move to guest role
4. Block Gitlab account
5. Delete IAM account from all AWS accounts (if applicable)
6. Review allow-ssh and security groups
7. Disable user access in databases as appropriate
8. Update any shared DB passwords
9. git-crypt gpg-user removal
10. Purge ssh keys
11. Check users pillar
12. Check ubuntu user
Other (where applicable)

1. Salesforce license
2. LinkedIn account
3. Zoom Info account

4. Verizon phone account
5. LucidChart account
Security
1. Disable and recover HID access card.
2. Security Clearance Release Forms Signed.

NIST RMF Documentation v2.1 - 20190807

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NIST RMF Documentation v2.1 - 20190807

Uploaded by

Copyright:

Available Formats

Sherlock

NIST RMF Security Documentation

1.1 Purpose ......................................................................................................... 38

8.0 Reviewing the Process ...................................................................................... 62

2019 NIST RMF Security Documentation

Sherlock Discovery Framework - Separation of Environments

3.0 Table of Contents

Access Control Policy and Procedures

1.1.1 Creation of LDAP account

1. Create JIRA issue for aproval from the user's manager

create_user 'John Smith'

ldapadd -Y EXTERNAL -H ldapi:/// -f jsmith.ldif

1.3 Linux System Access

2.0 Access Control Policy

necessary to accomplish assigned tasks in accordance with organizational missions and

Role Description Granted to

Application View database resources and logs for

2.2 VPN Systems

2.2.1 VPN Systems

(Lots of VPN changes to come...)

2.3 AWS Account Access

1. General Account Access IAM Configuration

2.4 Linux System Account Access

1. General Account Access

jspraggins ALL=(ALL) NOPASSWD:ALL

tmarimon ALL=(ALL) NOPASSWD:/usr/bin/docker

3.0 Access Control Procedures

• (CCI-002108) The organization defines the personnel or roles to be recipients of the

• (CCI-000061) The organization identifies and defines organization-defined user actions

3.1 General Resource Access

1. All systems require credentials

3.2 Linux System Account Restrictions

1. All systems require public/private key for SSH access

4. Username/password authentication is disabled for SSH access

4.0 Logon Attempt Restriction

• (CCI-000043) The organization defines the maximum number of consecutive invalid

4.1 SSH/FTP/Mail Restrictions

5.0 System Use Banner

• (CCI-002246) The organization-defined information system use notification message or

Sherlock System Banner

1. All information system access requires accounts.

2.0 Account Management

1. Primary (or initial) access for most systems is LDAP.

1. A documented onboarding procedure is executed to establish accounts based on

3.0 Group Membership

1. The policies within allow full administrative access to non-production

4.0 Role Membership

5.0 Account Automation, Monitoring, and Notification

• (CCI-002122) The organization monitors the use of information system accounts.

• (CCI-001684) The information system notifies organization-defined personnel or roles

1. Monitoring of accounts occurs on several levels:

1.2 Collection of Audit Records

3. AWS Config is used to track and report changes to a subset of technologies in

2.0 Audit and Accountability Procedures

3.0 Information System Auditing and Auditable Events

• (CCI-000123) The organization determines the information system must be capable of

3.1 System-Level Auditing

1. Deployed to all systems during inception using SaltStack configuration

9. Session initiation information

# Remove any existing rules

# Self Auditing ---------------------------------------------------------------

## Audit the audit logs