1
0
mirror of https://github.com/strongdm/comply synced 2024-12-23 14:07:34 +00:00

Adding new templates to proper soc2 narratives location

This commit is contained in:
Andy Magnusson 2018-12-06 10:10:18 -05:00
parent e2281b5fe3
commit 7225741a46
3 changed files with 206 additions and 4 deletions

View File

@ -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.

View File

@ -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

View File

@ -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