Professional Documents
Culture Documents
NIST RMF Documentation v2.1 - 20190807
NIST RMF Documentation v2.1 - 20190807
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
3. This creates a LDIF file in the current working directory. Then execute the following (and
supply LDAP admin creds when prompted)
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
2. YubiKey
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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:
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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. 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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
/etc/ssh/sshd_config
ClientAliveInterval 600
ClientAliveCountMax 3
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
• (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.
• (CCI-002245) The organization-defined information system use notification message or
banner is to state that unauthorized use of the information system is prohibited and
subject to criminal and civil penalties.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
1. A system banner is configured for Sherlock systems (all environments) as follows during
SSH access:
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
1. For more information regarding Role Membership, see section 2.1 of Access Control
Policy and Procedures.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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,
coordination among organizational entities, and compliance.
• (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. 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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
2.1 Requirements
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
• (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.
• (CCI-000131) The information system generates audit records containing information
that establishes when an event occurred.
• (CCI-000132) The information system generates audit records containing information
that establishes where the event occurred.
• (CCI-000133) The information system generates audit records containing information
that establishes the source of the event.
• (CCI-000134) The information system generates audit records containing information
that establishes the outcome of the event.
• (CCI-001487) The information system generates audit records containing information
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.
• (CCI-001876) The information system provides an audit reduction capability that
supports on-demand reporting requirements.
• (CCI-001877) The information system provides an audit reduction capability that
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.
• (CCI-001879) The information system provides a report generation capability that
supports on-demand reporting requirements.
• (CCI-001880) The information system provides a report generation capability that
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
• (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.
• (CCI-000163) The information system protects audit information from unauthorized
modification.
• (CCI-000164) The information system protects audit information from unauthorized
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.2 auditd
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
audit.rules
# 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
## Auditd configuration
### Modifications to audit configuration that occur while the audit collection functions are operating
-w /etc/audit/ -p wa -k auditconfig
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig
# Filters ---------------------------------------------------------------------
### We put these early because audit is a first match wins system.
## 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
-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 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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
# Rules -----------------------------------------------------------------------
## Kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl
## 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
## 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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
## Passwd
-w /usr/bin/passwd -p x -k passwd_modification
## 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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
-w /etc/issue.net -p wa -k etcissue
## 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
## 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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
## 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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
-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
## 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
# 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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
## CHEF https://www.chef.io/chef/
-w /etc/chef -p wa -k soft_chef
## 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
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F
exit=-EPERM -F auid>=500 -F auid!=4294967295 -k file_access
-a always,exit -F arch=b64 -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
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F
exit=-EPERM -F auid>=500 -F auid!=4294967295 -k file_access
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
# 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
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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
# Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts
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
cat /var/log/audit/audit.log
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
4. Example Ruleset
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
2. In addition, the tool includes auditing tools that we utilize monthly (at
minimum):
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
Configuration Management
1.0 Configuration Management Policy
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
• (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
addresses purpose, scope, roles, responsibilities, management commitment,
coordination among organizational entities, and compliance.
• (CCI-001822) The organization disseminates the configuration management policy to organization
defined personnel or roles.
• (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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
Example:
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
1.6 Review
2.1 Runbook
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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).
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.1.5 osquery
1.1.6 auditd
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
• (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.
• (CCI-002643) The organization monitors the information system to detect unauthorized
network connections.
• (CCI-002644) The organization monitors the information system to detect unauthorized
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.
• (CCI-002648) The organization protects information obtained from intrusion-monitoring
tools from unauthorized modification.
• (CCI-002649) The organization protects information obtained from intrusion-monitoring
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
• (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.
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
addresses purpose, scope, roles, responsibilities, management commitment,
coordination among organizational entities, and compliance.
• (CCI-000806) The organization disseminates an incident response policy to organization-
defined personnel or roles.
• (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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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
1. Identify the likely attack vectors and path; fix them so they cannot be re-exploited
immediately after stopping the attack.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
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".
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).
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
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.
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
1. There are no additional steps after an incident is resolved. However, the IC may ask for
your help with their steps.
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.
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.).
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
• (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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
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.
Sherlock NIST RMF Security Documentation August 7th, 2019
Security
1. Disable and recover HID access card.
2. Security Clearance Release Forms Signed.
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.