mirror of
https://github.com/strongdm/comply
synced 2024-11-22 07:34:54 +00:00
Backporting new narrative content to Comply
This commit is contained in:
parent
d43aca58ba
commit
e2281b5fe3
@ -17,6 +17,78 @@ majorRevisions:
|
||||
|
||||
# Control Environment Narrative
|
||||
|
||||
Here we narrate why our control environment satisfies the control keys listed in the YML block
|
||||
The following provides a description of the control structure of {{.Name}}.
|
||||
|
||||
# Template Coming Soon
|
||||
The intent of this description is to enumerate the logical, policy, and procedural controls that serve to monitor {{.Name}}'s application and data security. Changes uncovered by these procedures in the logical, policy, procedural, or customer environment are addressed by remediations specific to the noted change.
|
||||
|
||||
# Logical Controls
|
||||
|
||||
{{.Name}} employs several logical controls to protect confidential data and ensure normal operation of its core product.
|
||||
|
||||
- Mandatory data encryption at rest and in motion
|
||||
- Multi-factor authentication for access to cloud infrastructure
|
||||
- Activity and anomaly monitoring on production systems
|
||||
- Vulnerability management program
|
||||
|
||||
# Policy Controls
|
||||
|
||||
{{.Name}} employs several policy controls to protect confidential data and ensure normal operation of its core product. These policies include, but are not limited to:
|
||||
|
||||
- Access Control Policy
|
||||
- Encryption Policy
|
||||
- Office Security Policy
|
||||
- Password Policy
|
||||
- Policy Training Policy
|
||||
- Vendor Policy
|
||||
- Workstation Policy
|
||||
|
||||
# Procedural Controls
|
||||
|
||||
{{.Name}} has numerous scheduled procedures to monitor and tune the effectiveness of ongoing security controls, and a series of event-driven procedures to respond to security-related events.
|
||||
|
||||
TODO: Finalize these lists
|
||||
|
||||
## Scheduled Security and Audit Procedures
|
||||
|
||||
- Review Access [quarterly]
|
||||
- Review Security Logs [weekly]
|
||||
- Review Cyber Risk Assessment (enumerate possible compromise scenarios) [quarterly]
|
||||
- Review Data Classification [quarterly]
|
||||
- Backup Testing [quarterly]
|
||||
- Disaster Recovery Testing [semi-annual]
|
||||
- Review Devices & Workstations [quarterly]
|
||||
- Review & Clear Low-Priority Alerts [weekly]
|
||||
- Apply OS Patches [monthly]
|
||||
- Verify Data Disposal per Retention Policy [quarterly]
|
||||
- Conduct Security Training [annual]
|
||||
- Review Security Monitoring and Alerting Configuration [quarterly]
|
||||
- Penetration Test [annual]
|
||||
- Whitebox Security Review [annual]
|
||||
- SOC2 Audit [annual]
|
||||
|
||||
## Event-Driven Security and Audit Procedures
|
||||
|
||||
- Onboard Employee
|
||||
- Offboard Employee
|
||||
- Investigate Security Alert
|
||||
- Investigate Security Incident
|
||||
|
||||
# Remediations
|
||||
|
||||
{{.Name}} uses the outcomes of the aforementioned controls and procedures to identify shortcomings in the existing control environment. Once identified, these shortcomes are remediated by improving existing controls and procedures, and creating new controls and procedures as needed.
|
||||
|
||||
# Communications
|
||||
|
||||
{{.Name}} communicates relevant information regarding the functioning of the above controls with internal and external parties on an as-needed basis and according to statutory requirements.
|
||||
|
||||
## Internal
|
||||
|
||||
{{.Name}} communicates control outcomes, anomalies, and remediations internally using the following channels:
|
||||
|
||||
- Slack
|
||||
- Email
|
||||
- Github ticketing
|
||||
|
||||
## External
|
||||
|
||||
{{.Name}} communicates relevant control-related information to external parties including shareholders, customers, contractors, regulators, and government entities as needed according to contractual and regulatory/statutory obligation.
|
@ -9,4 +9,39 @@ majorRevisions:
|
||||
|
||||
Here we describe the key products marketed by our organization
|
||||
|
||||
# Template Coming Soon
|
||||
# Products
|
||||
|
||||
## Product 1
|
||||
|
||||
Overview of product 1
|
||||
|
||||
### Architecture
|
||||
|
||||
Brief architectural discussion of product 1
|
||||
|
||||
### Security Considerations
|
||||
|
||||
Specific security considerations for product 1. Refer to policies, procedures here.
|
||||
|
||||
# References
|
||||
|
||||
## Narratives
|
||||
|
||||
List relevant narratives, probably including
|
||||
Organizational Narrative
|
||||
Security Narrative
|
||||
System Narrative
|
||||
|
||||
## Policies
|
||||
|
||||
List relevant policies, probably including
|
||||
Application Security Policy
|
||||
Datacenter Policy
|
||||
Log Management Policy
|
||||
Password Policy
|
||||
Security Incident Response Policy
|
||||
Risk Assessment Policy
|
||||
|
||||
## Procedures
|
||||
|
||||
List relevant procedures, probably including access review, patching, alert monitoring, log review, pen testing
|
@ -15,4 +15,99 @@ majorRevisions:
|
||||
|
||||
Here we narrate why our org satisfies the control keys listed in the YML block
|
||||
|
||||
# Template Coming Soon
|
||||
# {{.Name}} Product Architecture
|
||||
|
||||
Describe product architecture here, emphasizing security implications
|
||||
|
||||
# {{.Name}} Infrastructure
|
||||
|
||||
## Product Infrastructure
|
||||
|
||||
Describe product infrastructure, emphasizing security measures
|
||||
|
||||
### Authorized Personnel
|
||||
|
||||
- **AWS root account** access is granted only to the CTO and CEO
|
||||
- **AWS IAM** access is granted to to a limited group of **Operators**
|
||||
- **{{.Name}} SSH** access is granted to a limited group of **Operators**
|
||||
- **{{.Name}} DB** access is granted to a limited group of **Data Operators**
|
||||
|
||||
## IT Infrastructure
|
||||
|
||||
{{.Name}} uses the following cloud services for its internal infrastructure:
|
||||
|
||||
- List cloud services
|
||||
|
||||
Access to these cloud services is limited according to the role of the {{.Name}} employee and is reviewed quarterly as well as via regular onboarding/offboarding tasks for new and departing employees.
|
||||
|
||||
# {{.Name}} Workstations
|
||||
|
||||
{{.Name}} workstations are hardened against logical and physical attack by the following measures:
|
||||
|
||||
- operating system must be within one generation of current
|
||||
- full-disk encryption
|
||||
- onboard antivirus/antimalware software
|
||||
- OS and AV automatically updated
|
||||
|
||||
Workstation compliance with these measures is evaluated on a quarterly basis.
|
||||
|
||||
## Remote Access
|
||||
|
||||
Many {{.Name}} employees work remotely on a regular basis and connect to production and internal IT systems via the same methods as those employees connecting from the {{.Name}} physical office, i.e., direct encrypted access to cloud services. It is the employee's responsibility to ensure that only authorized personnel use {{.Name}} resources and access {{.Name}} systems.
|
||||
|
||||
# Access Review
|
||||
|
||||
Access to {{.Name}} infrastructure, both internal and product, is reviewed quarterly and inactive users are removed. Any anomalies are reported to the security team for further investigation. When employees start or depart, an onboarding/offboarding procedure is followed to provision or deprovision appropriate account access.
|
||||
|
||||
# Penetration Testing
|
||||
|
||||
{{.Name}} commissions an external penetration test on an annual basis. All findings are immediately reviewed and addressed to the satisfaction of the CTO/CEO.
|
||||
|
||||
# {{.Name}} Physical Security
|
||||
|
||||
{{.Name}} has one physical location, in San Francisco, CA. Key issuance is tracked by the Office Physical Security Policy Ledger. Office keys are additionally held by the lessor, property management, and custodial staff. These keys are not tracked by the Office Physical Security Policy Ledger. {{.Name}} managers regularly review physical access privileges.
|
||||
|
||||
{{.Name}} infrastructure is located within AWS. {{.Name}} does not have physical access to AWS infrastructure.
|
||||
|
||||
# Risk Assessment
|
||||
|
||||
{{.Name}} updates its Cyber Risk Assessment on an annual basis in order to keep pace with the evolving threat landscape. The following is an inventory of adversarial and non-adversarial threats assessed to be of importance to {{.Name}}.
|
||||
|
||||
## Adversarial Threats
|
||||
|
||||
The following represents the inventory of adversarial threats:
|
||||
|
||||
|Threat|Source|Vector|Target|Likelihood|Severity|
|
||||
|----------------------------+--------------+------------+-----------------+----------+------|
|
||||
| | | | | | |
|
||||
|
||||
## Non-Adversarial Threats
|
||||
|
||||
The following represents the inventory of non-adversarial threats:
|
||||
|
||||
|Threat|Vector|Target|Likelihood|Severity|
|
||||
|----------------------------+--------------+-------------+----------+------|
|
||||
| | | | | |
|
||||
|
||||
# References
|
||||
|
||||
## Narratives
|
||||
|
||||
Products and Services Narrative
|
||||
System Architecture Narrative
|
||||
|
||||
## Policies
|
||||
|
||||
Encryption Policy
|
||||
Log Management Policy
|
||||
Office Security Policy
|
||||
Remote Access Policy
|
||||
Security Incident Response Policy
|
||||
Workstation Policy
|
||||
|
||||
## Procedures
|
||||
|
||||
Apply OS Patches
|
||||
Review & Clear Low-Priority Alerts
|
||||
Review Access
|
||||
Review Devices & Workstations
|
||||
|
Loading…
Reference in New Issue
Block a user