├── .github └── workflows │ └── build.yml ├── .gitignore ├── CODEOWNERS ├── Jenkinsfile ├── LICENSE ├── README.md ├── cortex.yaml ├── deploy ├── Dockerfile ├── hooks.js ├── package.json └── terraform │ ├── outputs.tf │ └── s3.tf ├── package.json ├── project.name ├── summary.md ├── templates ├── assessments │ ├── compliance-report.md.tmpl │ └── hipaa.md.tmpl ├── config.json ├── index.md.tmpl ├── mkdocs │ └── mkdocs.yml.tmpl ├── policies │ ├── access.md.tmpl │ ├── asset-mgmt.md.tmpl │ ├── bcdr.md.tmpl │ ├── breach.md.tmpl │ ├── ccm.md.tmpl │ ├── compliance-audit.md.tmpl │ ├── corp-gov.md.tmpl │ ├── data-mgmt.md.tmpl │ ├── data-protection.md.tmpl │ ├── facility.md.tmpl │ ├── hr.md.tmpl │ ├── ir.md.tmpl │ ├── mdm.md.tmpl │ ├── model.md.tmpl │ ├── policy-mgmt.md.tmpl │ ├── privacy.md.tmpl │ ├── program.md.tmpl │ ├── rar.md.tmpl │ ├── ref.md.tmpl │ ├── risk-mgmt.md.tmpl │ ├── sdlc.md.tmpl │ ├── system-audit.md.tmpl │ ├── threat.md.tmpl │ ├── vendor.md.tmpl │ └── vuln-mgmt.md.tmpl ├── procedures │ ├── cp-access-aws.md.tmpl │ ├── cp-access-change.md.tmpl │ ├── cp-access-customer.md.tmpl │ ├── cp-access-endpoints.md.tmpl │ ├── cp-access-mfa.md.tmpl │ ├── cp-access-password.md.tmpl │ ├── cp-access-phi.md.tmpl │ ├── cp-access-privileged.md.tmpl │ ├── cp-access-prod-data.md.tmpl │ ├── cp-access-prod.md.tmpl │ ├── cp-access-rbac.md.tmpl │ ├── cp-access-reset.md.tmpl │ ├── cp-access-review.md.tmpl │ ├── cp-access-service.md.tmpl │ ├── cp-access-sso.md.tmpl │ ├── cp-access-standards.md.tmpl │ ├── cp-access-vpn.md.tmpl │ ├── cp-access-wifi.md.tmpl │ ├── cp-asset-digital.md.tmpl │ ├── cp-asset-paper.md.tmpl │ ├── cp-asset-physical.md.tmpl │ ├── cp-audit-control-deficiency.md.tmpl │ ├── cp-audit-customers.md.tmpl │ ├── cp-audit-internal.md.tmpl │ ├── cp-audit-request.md.tmpl │ ├── cp-audit-review.md.tmpl │ ├── cp-audit-tools.md.tmpl │ ├── cp-audit-trails-integrity.md.tmpl │ ├── cp-audit-trails.md.tmpl │ ├── cp-audit-training.md.tmpl │ ├── cp-audit-types.md.tmpl │ ├── cp-bcdr-app.md.tmpl │ ├── cp-bcdr-data.md.tmpl │ ├── cp-bcdr-recovery.md.tmpl │ ├── cp-bcdr-site.md.tmpl │ ├── cp-bcdr-test.md.tmpl │ ├── cp-bcdr.md.tmpl │ ├── cp-breach-authorities.md.tmpl │ ├── cp-breach-customer.md.tmpl │ ├── cp-breach-investigate.md.tmpl │ ├── cp-breach-letter.md.tmpl │ ├── cp-ccm-aws-deploy.md.tmpl │ ├── cp-ccm-aws.md.tmpl │ ├── cp-ccm-config.md.tmpl │ ├── cp-ccm-emergency.md.tmpl │ ├── cp-ccm-monitor.md.tmpl │ ├── cp-ccm-network.md.tmpl │ ├── cp-ccm-patch.md.tmpl │ ├── cp-ccm-prodcm.md.tmpl │ ├── cp-ccm-provision-endpoint.md.tmpl │ ├── cp-ccm-provision-mgmt.md.tmpl │ ├── cp-ccm-provision-prod.md.tmpl │ ├── cp-ccm-provision-server.md.tmpl │ ├── cp-compliance-mgmt.md.tmpl │ ├── cp-compliance-monitor.md.tmpl │ ├── cp-compliance-requests.md.tmpl │ ├── cp-data-backup.md.tmpl │ ├── cp-data-classification.md.tmpl │ ├── cp-data-deletion.md.tmpl │ ├── cp-data-handling.md.tmpl │ ├── cp-data-lifecycle.md.tmpl │ ├── cp-data-protection-at-rest.md.tmpl │ ├── cp-data-protection-cert.md.tmpl │ ├── cp-data-protection-in-transit.md.tmpl │ ├── cp-data-protection-in-use.md.tmpl │ ├── cp-data-protection-integrity.md.tmpl │ ├── cp-data-protection-kms.md.tmpl │ ├── cp-data-protection.md.tmpl │ ├── cp-employee-acceptable-use.md.tmpl │ ├── cp-employee-development.md.tmpl │ ├── cp-employee-escalation.md.tmpl │ ├── cp-employee-exiting.md.tmpl │ ├── cp-employee-onboarding.md.tmpl │ ├── cp-employee-performance.md.tmpl │ ├── cp-employee-recognition.md.tmpl │ ├── cp-employee-screening.md.tmpl │ ├── cp-employee-whistleblower.md.tmpl │ ├── cp-events-analysis.md.tmpl │ ├── cp-gov-bod.md.tmpl │ ├── cp-hr-mgmt.md.tmpl │ ├── cp-internal-comms.md.tmpl │ ├── cp-ir-emergency.md.tmpl │ ├── cp-ir-playbook.md.tmpl │ ├── cp-ir-process.md.tmpl │ ├── cp-ir-records.md.tmpl │ ├── cp-ir-sirt.md.tmpl │ ├── cp-ir-tabletop.md.tmpl │ ├── cp-ism-policies.md.tmpl │ ├── cp-ism-reporting.md.tmpl │ ├── cp-ism-scope.md.tmpl │ ├── cp-mdm-byod.md.tmpl │ ├── cp-mdm-disposal.md.tmpl │ ├── cp-mdm-usb.md.tmpl │ ├── cp-model-architecture.md.tmpl │ ├── cp-model-metrics.md.tmpl │ ├── cp-model-principles.md.tmpl │ ├── cp-model-quality.md.tmpl │ ├── cp-physical-cleandesk.md.tmpl │ ├── cp-physical-datacenter.md.tmpl │ ├── cp-physical.md.tmpl │ ├── cp-policy-framework.md.tmpl │ ├── cp-policy-mgmt.md.tmpl │ ├── cp-privacy-notices.md.tmpl │ ├── cp-risk-assess.md.tmpl │ ├── cp-risk-fraud.md.tmpl │ ├── cp-risk-insurance.md.tmpl │ ├── cp-risk-mgmt-objectives.md.tmpl │ ├── cp-risk-mgmt.md.tmpl │ ├── cp-risk-mitigation.md.tmpl │ ├── cp-risk-registry.md.tmpl │ ├── cp-role-assignment.md.tmpl │ ├── cp-sanctions.md.tmpl │ ├── cp-sdlc-appsec-req.md.tmpl │ ├── cp-sdlc-bugbounty.md.tmpl │ ├── cp-sdlc-dast.md.tmpl │ ├── cp-sdlc-design.md.tmpl │ ├── cp-sdlc-dev.md.tmpl │ ├── cp-sdlc-foss.md.tmpl │ ├── cp-sdlc-hipaa.md.tmpl │ ├── cp-sdlc-iaaa.md.tmpl │ ├── cp-sdlc-monitor.md.tmpl │ ├── cp-sdlc-outsourcing.md.tmpl │ ├── cp-sdlc-pentest.md.tmpl │ ├── cp-sdlc-sast.md.tmpl │ ├── cp-sdlc-scm.md.tmpl │ ├── cp-threat-firewall.md.tmpl │ ├── cp-threat-hids.md.tmpl │ ├── cp-threat-intel.md.tmpl │ ├── cp-threat-malware.md.tmpl │ ├── cp-threat-nids.md.tmpl │ ├── cp-threat-siem.md.tmpl │ ├── cp-threat-webapp.md.tmpl │ ├── cp-training-awareness.md.tmpl │ ├── cp-training-hipaa.md.tmpl │ ├── cp-training-policy.md.tmpl │ ├── cp-vendor-contracts.md.tmpl │ ├── cp-vendor-monitor.md.tmpl │ ├── cp-vendor-ssa.md.tmpl │ ├── cp-vendor-vtr.md.tmpl │ ├── cp-vuln-remediation.md.tmpl │ └── cp-vuln-scan.md.tmpl ├── ref │ ├── approved-software.md.tmpl │ ├── approved-vendors.md.tmpl │ ├── cookie-policy.md.tmpl │ ├── definitions.md.tmpl │ ├── employee-handbook.md.tmpl │ ├── gdpr-dpa.md.tmpl │ ├── hipaa-baa.md.tmpl │ ├── hipaa-mapping.md.tmpl │ ├── nist-mapping.md.tmpl │ ├── privacy-policy.md.tmpl │ └── sanction-notice.pdf └── standards │ ├── aws │ └── startup-security-baseline.json │ ├── cis-aws-foundations │ ├── v1.2.0.json │ ├── v1.3.0.json │ ├── v1.4.0.json │ └── v2.0.0.json │ ├── cis-azure-foundations │ ├── v1.1.0.json │ └── v1.3.0.json │ ├── cis-controls │ ├── v7.json │ └── v8.json │ ├── cis-gcp-foundations │ ├── v1.1.0.json │ ├── v1.3.0.json │ └── v2.0.0.json │ ├── cis-oci-foundations │ └── v2.0.0.json │ ├── cmmc-level1.json │ ├── cmmc-ml1.json │ ├── controls-mapping.json │ ├── csa-ccm.json │ ├── fedramp │ ├── fedramp-high.json │ ├── fedramp-low.json │ ├── fedramp-moderate.json │ ├── v4 │ │ ├── fedramp-high.json │ │ ├── fedramp-low.json │ │ └── fedramp-moderate.json │ └── v5 │ │ ├── fedramp-high.json │ │ ├── fedramp-low.json │ │ └── fedramp-moderate.json │ ├── gdpr-example.json │ ├── hipaa.json │ ├── hipaa │ └── 2013.json │ ├── iso-27002-2022.json │ ├── iso-iec-27001-2013.json │ ├── iso-iec-27001-2022.json │ ├── iso-iec-27002-2005.json │ ├── iso-iec-27002-2013.json │ ├── nist-800-53 │ └── rev4.json │ ├── nist-csf │ ├── v1.1.json │ └── v2.0.0.json │ ├── pci-dss-japanese.json │ ├── pci-dss-saq-a.json │ ├── pci-dss.json │ ├── pci-dss │ ├── pci-dss-japanese.json │ ├── pci-dss-saq-a.json │ └── pci-dss.json │ ├── scf.json │ ├── security-program.json │ ├── security-questionnaire-example-template.json │ ├── soc2 │ ├── soc2-availability.json │ ├── soc2-confidentiality.json │ ├── soc2-security-availability-confidentiality.json │ └── soc2-security.json │ ├── sunstone-merged-moderate.json │ ├── template.csv │ ├── template.json │ ├── thsa.json │ └── thsa │ └── 2019-1.json ├── util ├── COMPLIANCE-SEARCH-TOOL-README.md ├── build-summary.js ├── compliance.py ├── control-req-mapper.js ├── internal-standard.js ├── parser-fedramp.js ├── parser-soc2.js ├── parser-thsa.js └── setup-compliance-script.py └── yarn.lock /.github/workflows/build.yml: -------------------------------------------------------------------------------- 1 | name: Build 2 | on: [push, pull_request] 3 | 4 | jobs: 5 | test: 6 | runs-on: ${{ matrix.os }} 7 | strategy: 8 | fail-fast: false 9 | matrix: 10 | node-version: [12.x] 11 | os: [ubuntu-latest] 12 | 13 | steps: 14 | - id: setup-node 15 | name: Setup Node 16 | uses: actions/setup-node@v1 17 | with: 18 | node-version: ${{ matrix.node-version }} 19 | 20 | - name: Check out code repository source code 21 | uses: actions/checkout@v2 22 | 23 | - name: Install dependencies 24 | env: 25 | NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }} 26 | run: | 27 | echo "//registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}" > .npmrc 28 | yarn 29 | 30 | # Publishing is done in a separate job to allow 31 | # for all matrix builds to complete. 32 | release: 33 | needs: test 34 | runs-on: ubuntu-latest 35 | if: github.ref == 'refs/heads/master' 36 | strategy: 37 | fail-fast: false 38 | matrix: 39 | node: [12] 40 | 41 | steps: 42 | - name: Setup Node 43 | uses: actions/setup-node@v1 44 | with: 45 | node-version: 12.x 46 | 47 | - name: Check out repo 48 | uses: actions/checkout@v2 49 | with: 50 | fetch-depth: 2 51 | 52 | # Fetch tags and describe the commit before the merge commit 53 | # to see if it's a version publish 54 | - name: Fetch tags 55 | run: | 56 | git fetch --tags 57 | if git describe --exact-match --match "v*.*.*" HEAD^2 58 | then 59 | echo "Found version commit tag. Publishing." 60 | echo "publish=true" >> $GITHUB_ENV 61 | else 62 | echo "Version commit tag not found. Not publishing." 63 | fi 64 | 65 | - name: Install dependencies 66 | env: 67 | NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }} 68 | run: | 69 | echo "//registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}" > .npmrc 70 | yarn 71 | 72 | - name: Publish 73 | if: env.publish == 'true' 74 | env: 75 | NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }} 76 | run: | 77 | echo "//registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}" > .npmrc 78 | npm publish --access public 79 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | 8 | # Runtime data 9 | pids 10 | *.pid 11 | *.seed 12 | *.pid.lock 13 | 14 | # Directory for instrumented libs generated by jscoverage/JSCover 15 | lib-cov 16 | 17 | # Coverage directory used by tools like istanbul 18 | coverage 19 | 20 | # nyc test coverage 21 | .nyc_output 22 | 23 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 24 | .grunt 25 | 26 | # Bower dependency directory (https://bower.io/) 27 | bower_components 28 | 29 | # node-waf configuration 30 | .lock-wscript 31 | 32 | # Compiled binary addons (https://nodejs.org/api/addons.html) 33 | build/Release 34 | 35 | # Dependency directories 36 | node_modules/ 37 | jspm_packages/ 38 | 39 | # TypeScript v1 declaration files 40 | typings/ 41 | 42 | # Optional npm cache directory 43 | .npm 44 | 45 | # Optional eslint cache 46 | .eslintcache 47 | 48 | # Optional REPL history 49 | .node_repl_history 50 | 51 | # Output of 'npm pack' 52 | *.tgz 53 | 54 | # Yarn Integrity file 55 | .yarn-integrity 56 | 57 | # dotenv environment variables file 58 | .env 59 | 60 | # next.js build output 61 | .next 62 | 63 | # other 64 | .work 65 | .DS_Store 66 | partials/ 67 | docs/ 68 | 69 | /deploy/templates/ 70 | work/ 71 | .npmrc -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @jupiterone/apps 2 | 3 | CODEOWNERS @jupiterone/security -------------------------------------------------------------------------------- /Jenkinsfile: -------------------------------------------------------------------------------- 1 | #!groovy 2 | 3 | pipeline { 4 | agent none 5 | 6 | stages { 7 | stage('build') { 8 | when { branch 'main' } 9 | agent { label 'ecs-builder-node14' } 10 | steps { 11 | initBuild() 12 | sh 'cp -r templates ./deploy' 13 | sh 'jupiterone-build' 14 | sh 'jupiterone-publish' 15 | } 16 | } 17 | stage('deploy') { 18 | when { branch 'main' } 19 | agent { label 'ecs-builder-node14' } 20 | steps { 21 | deployToJupiterEnvironments ( 22 | autoPopulateCM: [jiraComponent: 'Cloud Platform'] 23 | ) 24 | } 25 | } 26 | 27 | } 28 | } 29 | -------------------------------------------------------------------------------- /cortex.yaml: -------------------------------------------------------------------------------- 1 | openapi: 3.0.1 2 | info: 3 | title: '@jupiterone/security-policy-templates' 4 | description: >- 5 | JupiterOne security policies and procedures. For use with 6 | jupiter-policy-builder. 7 | x-cortex-git: 8 | github: 9 | repository: JupiterOne/security-policy-templates 10 | x-cortex-owners: 11 | - type: group 12 | name: JupiterOne/Apps 13 | x-cortex-tag: '@jupiterone/security-policy-templates' 14 | x-cortex-service-groups: 15 | - tier-4 16 | -------------------------------------------------------------------------------- /deploy/Dockerfile: -------------------------------------------------------------------------------- 1 | FROM 081157560428.dkr.ecr.us-east-1.amazonaws.com/base-deploy-terraform-v1.0:11 2 | 3 | COPY . /opt/jupiterone/deploy 4 | WORKDIR /opt/jupiterone/deploy 5 | RUN yarn install 6 | -------------------------------------------------------------------------------- /deploy/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "dependencies": { 3 | "bytes": "^3.1.0", 4 | "mime-types": "^2.1.26", 5 | "p-all": "^2.1.0" 6 | } 7 | } 8 | -------------------------------------------------------------------------------- /deploy/terraform/outputs.tf: -------------------------------------------------------------------------------- 1 | output "s3_bucket_name" { 2 | value = aws_s3_bucket.security_policy_templates.id 3 | } 4 | 5 | output "s3_bucket_arn" { 6 | value = aws_s3_bucket.security_policy_templates.arn 7 | } 8 | -------------------------------------------------------------------------------- /deploy/terraform/s3.tf: -------------------------------------------------------------------------------- 1 | resource "aws_s3_bucket" "security_policy_templates" { 2 | bucket = "${var.deploy_config.environment}-security-policy-templates" 3 | acl = "private" 4 | tags = { 5 | Project = var.deploy_config.project 6 | Classification = "internal" 7 | Description = "bucket that copies the source from security-policy-templates in GitHub" 8 | } 9 | 10 | server_side_encryption_configuration { 11 | rule { 12 | apply_server_side_encryption_by_default { 13 | sse_algorithm = "AES256" 14 | } 15 | } 16 | } 17 | } 18 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "@jupiterone/security-policy-templates", 3 | "version": "2.13.0", 4 | "description": "JupiterOne security policies and procedures. For use with jupiter-policy-builder.", 5 | "repository": { 6 | "type": "git", 7 | "url": "https://github.com/JupiterOne/security-policy-templates" 8 | }, 9 | "license": "CC-BY-SA-4.0", 10 | "author": "JupiterOne ", 11 | "scripts": { 12 | "build:summary": "cd util; node build-summary.js", 13 | "parse:fedramp": "cd util; node fedramp-parser.js", 14 | "parse:soc2": "cd util; node soc2-parser.js", 15 | "publish:j1": "./node_modules/@jupiterone/security-policy-builder/bin/psp publish -c config.json -t templates -a $J1_ACCOUNT_ID -k $J1_API_TOKEN -n", 16 | "deploy": "jupiterone-manual-deploy -t jupiterone-dev -a apply", 17 | "destroy": "jupiterone-manual-deploy -t jupiterone-dev -a destroy", 18 | "plan": "jupiterone-manual-deploy -t jupiterone-dev -a plan" 19 | }, 20 | "devDependencies": { 21 | "@jupiterone/dev-tools": "^8.1.1", 22 | "csvtojson": "^2.0.10", 23 | "lodash.capitalize": "^4.2.1", 24 | "lodash.startcase": "^4.4.0" 25 | } 26 | } 27 | -------------------------------------------------------------------------------- /project.name: -------------------------------------------------------------------------------- 1 | security-policy-templates -------------------------------------------------------------------------------- /templates/index.md.tmpl: -------------------------------------------------------------------------------- 1 | # {{ companyShortName }} Security Policies, Standards, and Procedures 2 | 3 | Contents of this file will be dynamically generated by the policy builder -------------------------------------------------------------------------------- /templates/mkdocs/mkdocs.yml.tmpl: -------------------------------------------------------------------------------- 1 | site_name: '{{ companyShortName }} Security PSP' 2 | site_description: '{{ companyShortName }} Security Policies, Standards, and Procedures' 3 | site_url: '{{& securityPolicyURL }}' 4 | 5 | theme: 6 | name: material 7 | theme_dir: 'custom_theme' 8 | include_sidebar: false 9 | palette: 10 | primary: '{{ mkdocsThemeColorPrimary }}' 11 | accent: '{{ mkdocsThemeColorAccent }}' 12 | favicon: 'assets/images/favicon.ico' 13 | logo: '{{& mkdocsLogoFile }}' 14 | 15 | # Enable custom.css 16 | extra_css: 17 | - 'assets/css/custom.css' 18 | 19 | markdown_extensions: 20 | - smarty 21 | - toc: 22 | permalink: true 23 | - sane_lists 24 | - admonition 25 | - codehilite: 26 | guess_lang: false 27 | -------------------------------------------------------------------------------- /templates/policies/asset-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | # Asset Inventory Management 2 | 3 | `{{defaultRevision}}` 4 | 5 | You can't protect what you can't see. Therefore, it is imperative for {{companyShortName}} 6 | to maintain an accurate and up-to-date inventory of both its physical and 7 | digital assets. 8 | 9 | More details on data inventory and data lifecycle management is documented 10 | separately in [Data Management](data-mgmt.md). 11 | 12 | ## Policy Statements 13 | 14 | {{companyShortName}} policy requires that: 15 | 16 | (a) IT and/or Security must maintain an inventory of all critical company 17 | assets, both physical and logical. 18 | 19 | (b) All assets should have identified owners and be tagged with a risk/data 20 | classification. 21 | 22 | (c) All physical assets must be labeled with a company property tag. 23 | -------------------------------------------------------------------------------- /templates/policies/bcdr.md.tmpl: -------------------------------------------------------------------------------- 1 | # Business Continuity and Disaster Recovery 2 | 3 | `{{defaultRevision}}` 4 | 5 | The {{companyShortName}} Contingency Plan establishes procedures to recover {{companyShortName}} 6 | following a disruption resulting from a disaster. This Disaster Recovery Policy 7 | is maintained by the {{companyShortName}} Security Officer and Privacy Officer. 8 | 9 | {{#needStandardHIPAA}} 10 | **HIPAA:** This {{companyShortName}} Contingency Plan has been developed as 11 | required under the Office of Management and Budget (OMB) Circular A-130, 12 | Management of Federal Information Resources, Appendix III, November 2000, and 13 | the Health Insurance Portability and Accountability Act (HIPAA) Final Security 14 | Rule, Section §164.308(a)(7), which requires the establishment and 15 | implementation of procedures for responding to events that damage systems 16 | containing electronic protected health information. 17 | {{/needStandardHIPAA}} 18 | 19 | {{#needStandardNIST}} 20 | **NIST:** This {{companyShortName}} Contingency Plan is created under the 21 | legislative requirements set forth in the Federal Information Security 22 | Management Act (FISMA) of 2002 and the guidelines established by the National 23 | Institute of Standards and Technology (NIST) Special Publication (SP) 800-34, 24 | titled "Contingency Planning Guide for Information Technology Systems" dated 25 | June 2002. 26 | {{/needStandardNIST}} 27 | 28 | ## Policy Statements 29 | 30 | {{companyShortName}} policy requires that: 31 | 32 | (a) A plan and process for business continuity and disaster recovery (BCDR), 33 | including the backup and recovery of systems and data, must be defined and 34 | documented. 35 | 36 | (b) BCDR shall be simulated and tested at least once a year. Metrics shall be 37 | measured and identified recovery enhancements shall be filed to improve the BCDR 38 | process. 39 | 40 | (c) Security controls and requirements must be maintained during all BCDR 41 | activities. -------------------------------------------------------------------------------- /templates/policies/breach.md.tmpl: -------------------------------------------------------------------------------- 1 | # Breach Investigation and Notification 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{#needStandardHIPAA}} 6 | To provide guidance for breach notification when impressive or unauthorized 7 | access, acquisition, use and/or disclosure of the ePHI occurs. Breach 8 | notification will be carried out in compliance with the American Recovery and 9 | Reinvestment Act (ARRA)/Health Information Technology for Economic and Clinical 10 | Health Act (HITECH) as well as any other federal or state notification law. 11 | 12 | The Federal Trade Commission (FTC) has published breach notification rules for 13 | vendors of personal health records as required by ARRA/HITECH. The FTC rule 14 | applies to entities not covered by HIPAA, primarily vendors of personal health 15 | records. The rule is effective September 24, 2009 with full compliance required 16 | by February 22, 2010. 17 | 18 | The American Recovery and Reinvestment Act of 2009 (ARRA) was signed into law on 19 | February 17, 2009. Title XIII of ARRA is the Health Information Technology for 20 | Economic and Clinical Health Act (HITECH). HITECH significantly impacts the 21 | Health Insurance Portability and Accountability (HIPAA) Privacy and Security 22 | Rules. While HIPAA did not require notification when patient protected health 23 | information (PHI) was inappropriately disclosed, covered entities and business 24 | associates may have chosen to include notification as part of the mitigation 25 | process. HITECH does require notification of certain breaches of unsecured PHI 26 | to the following: individuals, Department of Health and Human Services (HHS), 27 | and the media. The effective implementation for this provision is September 23, 28 | 2009 (pending publication HHS regulations). 29 | {{/needStandardHIPAA}} 30 | 31 | In the case of a breach, {{companyShortName}} shall notify all affected 32 | Customers. It is the responsibility of the Customers to notify affected 33 | individuals. 34 | 35 | ## Policy Statements 36 | 37 | {{companyShortName}} policy requires that: 38 | 39 | (a) Breach notification procedures are invoked upon confirmation of security 40 | breach that results in unauthorized disclosure of unprotected/unencrypted 41 | sensitive data. 42 | 43 | (b) Individuals impacted by a confirmed data breach must be notified within a predefined, required timeframe 44 | of discovery of such breach. 45 | 46 | {{#needStandardHIPAA}} 47 | (c) In the event of a data breach that involves unencrypted ePHI, 48 | {{companyShortName}} must report the breach to individuals impacted following 49 | the HIPAA Breach Notification requirements (45 CFR Part 164, Subpart D). 50 | {{/needStandardHIPAA}} 51 | -------------------------------------------------------------------------------- /templates/policies/ccm.md.tmpl: -------------------------------------------------------------------------------- 1 | # Configuration and Change Management 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} standardizes and automates configuration management through the use of 6 | automation scripts as well as documentation of all changes to production systems 7 | and networks. Automation tools (examples of which include Chef, Salt, and Terraform) automatically 8 | configure all {{companyShortName}} systems according to established and tested policies, and 9 | are used as part of our Disaster Recovery plan and process. 10 | 11 | ## Policy Statements 12 | 13 | {{companyShortName}} policy requires that: 14 | 15 | (a) All production changes, including but not limited to software deployment, 16 | feature toggle enablement, network infrastructure changes, and access control 17 | authorization updates, must be invoked through approved change management 18 | process. 19 | 20 | (b) Each production change must maintain complete traceability to fully document 21 | the request, including requestor, date/time of change, actions taken and 22 | results. 23 | 24 | (c) Each production change must be fully tested prior to implementation. 25 | 26 | (d) Each production change must include a rollback plan to back out the change 27 | in the event of failure. 28 | 29 | (e) Each production change must include proper approval. 30 | 31 | * The approvers are determined based on the type of change. 32 | * Approvers must be someone other than the author/executor of the change. 33 | * Approvals may be automatically granted if certain criteria is met. 34 | The auto-approval criteria must be pre-approved by the Security Officer and 35 | fully documented and validated for each request. 36 | -------------------------------------------------------------------------------- /templates/policies/compliance-audit.md.tmpl: -------------------------------------------------------------------------------- 1 | # Compliance Audits and External Communications 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} may be requested occasionally to share additional details regarding its 6 | compliance, privacy and security program by an external entity such as a 7 | customer, media, legal or law enforcement. Such external communication, beyond 8 | what is already publicly published, needs to comply with the following policies 9 | and procedures. 10 | 11 | ## Policy Statements 12 | 13 | {{companyShortName}} policy requires that: 14 | 15 | (a) {{companyShortName}} operations must comply with all applicable laws, 16 | regulations, security standards and frameworks. External audits shall be 17 | conducted accordingly to each applicable compliance requirement. 18 | 19 | {{#needStandardHIPAA}} 20 | - HIPAA/HITECH. {{companyShortName}} must comply with all requirements listed 21 | in the HIPAA (Health Insurance Portability and Accountability Act of 1996) 22 | and the Health Information Technology for Economic and Clinical Health 23 | (HITECH) Act. 24 | {{/needStandardHIPAA}} 25 | 26 | {{#needStandardHITRUST}} 27 | - HITRUST. {{companyShortName}} security program and controls are aligned with 28 | the HITRUST Common Security Framework (CSF). 29 | {{/needStandardHITRUST}} 30 | 31 | {{#needStandardGDPR}} 32 | - GDPR. {{companyShortName}} must protect the personal data and privacy of EU 33 | citizens according to the regulatory requirements set forth in the European 34 | Union General Data Protection Regulation (GDPR). 35 | {{/needStandardGDPR}} 36 | 37 | {{#needStandardNIST}} 38 | - NIST. {{companyShortName}} security shall implement the applicable controls 39 | outlined in NIST Special Publication 800-53. 40 | {{/needStandardNIST}} 41 | 42 | {{#needStandardPCI}} 43 | - PCI. {{companyShortName}} must protect the payment card data processed 44 | and/or stored according to the requirements in the latest Payment Card 45 | Industry Data Security Standard (PCI DSS). 46 | {{/needStandardPCI}} 47 | 48 | (b) All external communications related to compliance and customer/employee 49 | privacy must follow pre-established procedures and handled by approved 50 | personnel. This includes but is not limited to distribution of audit reports, 51 | assessment results, incidents and breach notification. 52 | 53 | (c) Audit and compliance reports may be shared with an external party only when 54 | under signed NDA and approved by {{companyShortName}} Security and/or Privacy Officer. 55 | -------------------------------------------------------------------------------- /templates/policies/corp-gov.md.tmpl: -------------------------------------------------------------------------------- 1 | # Corporate Governance 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} believes in transparent and ethical business practices, and 6 | the protection of long-term interests of its employees, customers, shareholders 7 | and other stakeholders. 8 | 9 | {{companyShortName}} has established a Board of Directors (Bod) and appointed 10 | qualified members and directors, such that: 11 | 12 | * A corporate bylaws and BoD charters are in place that describe board members 13 | responsibilities. 14 | 15 | * The BoD identifies and accepts its oversight responsibilities in relation to 16 | established requirements and expectations. 17 | 18 | * Board members are evaluated on a periodic basis to help ensure their skills 19 | and expertise are suited to lead senior management and take commensurate 20 | action. 21 | 22 | * The BoD has sufficient members who are independent from management and are 23 | objective in evaluations and decision making. 24 | 25 | * The expectations of the BoD and/or senior management are defined and 26 | understood at all levels of the organization and its service providers and 27 | business partners. 28 | -------------------------------------------------------------------------------- /templates/policies/data-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | # Data Management Policy 2 | 3 | `{{defaultRevision}}` 4 | 5 | This policy outlines the requirements and controls/procedures {{companyShortName}} has 6 | implemented to manage the end-to-end data lifecycle, from data 7 | creation/acquisition to retention and deletion. 8 | 9 | Additionally, this policy outlines requirements and procedures to create and 10 | maintain retrievable exact copies of 11 | {{#needStandardHIPAA}}electronic protected health information(ePHI),{{/needStandardHIPAA}} 12 | PII and other critical customer/business data. 13 | 14 | Data backup is an important part of the day-to-day operations of {{companyShortName}}. To 15 | protect the confidentiality, integrity, and availability of sensitive and critical data, both for 16 | {{companyShortName}} and {{companyShortName}} Customers, complete backups are done daily to assure that 17 | data remains available when it needed and in case of a disaster. 18 | 19 | ## Policy Statements 20 | 21 | {{companyShortName}} policy requires that 22 | 23 | (a) Data should be classified at time of creation or acquisition according to 24 | the [{{companyShortName}} data classification model](data-mgmt.md#data-classification-model), 25 | by labeling or tagging the data. 26 | 27 | (b) Maintain an up-to-date inventory and data flows mapping of all critical 28 | data. 29 | 30 | (c) All business data should be stored or replicated to a company controlled 31 | repository, including data on end-user computing systems. 32 | 33 | (d) Data must be backed up according to its level defined in {{companyShortName}} data 34 | classification. 35 | 36 | (e) Data backup must be validated for integrity. 37 | 38 | (f) Data retention period must be defined and comply with any and all applicable 39 | regulatory and contractual requirements. More specifically, 40 | 41 | * Data and records belonging to {{companyShortName}} platform customer must be retained 42 | per {{companyShortName}} product terms and conditions and/or specific contractual 43 | agreements. 44 | 45 | (g) By default, all security documentation and audit trails are kept for a 46 | minimum of seven years, unless otherwise specified by {{companyShortName}} data 47 | classification, specific regulations or contractual agreement. 48 | -------------------------------------------------------------------------------- /templates/policies/data-protection.md.tmpl: -------------------------------------------------------------------------------- 1 | # Data Protection 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} takes the confidentiality and integrity of its customer data very 6 | seriously. As stewards and partners of {{companyShortName}} Customers, we strive to assure 7 | data is protected from unauthorized access and that it is available when needed. 8 | The following policies drive many of our procedures and technical controls in 9 | support of the {{companyShortName}} mission of data protection. 10 | 11 | Production systems that create, receive, store, or transmit Customer data 12 | (hereafter "Production Systems") must follow the requirements and guidelines 13 | described in this section. 14 | 15 | ## Policy Statements 16 | 17 | {{companyShortName}} policy requires that: 18 | 19 | (a) Data must be handled and protected according to its classification 20 | requirements and following approved encryption standards, if applicable. 21 | 22 | (b) Whenever possible, store data of the same classification in a given data 23 | repository and avoid mixing sensitive and non-sensitive data in the same 24 | repository. Security controls, including authentication, authorization, data 25 | encryption, and auditing, should be applied according to the highest 26 | classification of data in a given repository. 27 | 28 | (c) Workforce members shall not have direct administrative access to production 29 | data during normal business operations. Exceptions include emergency operations 30 | such as forensic analysis and manual disaster recovery. 31 | 32 | (d) All Production Systems must disable services that are not required to 33 | achieve the business purpose or function of the system. 34 | 35 | (e) All access to Production Systems must be logged, following the {{companyShortName}} 36 | Auditing Policy. 37 | 38 | (f) All Production Systems must have security monitoring enabled, including 39 | activity and file integrity monitoring, vulnerability scanning, and/or malware 40 | detection, as applicable. 41 | -------------------------------------------------------------------------------- /templates/policies/facility.md.tmpl: -------------------------------------------------------------------------------- 1 | # Facility Access and Physical Security 2 | 3 | `{{defaultRevision}}` 4 | 5 | It is the goal of {{companyShortName}} to provide a safe and secure environment 6 | for all employees. Access to the {{companyShortName}} facilities is limited to 7 | authorized individuals only. 8 | 9 | {{companyShortName}} works with Subcontractors (e.g. property management 10 | companies and facilities management) to assure restriction of physical access to 11 | systems used as part of the {{companyShortName}} Platform. 12 | 13 | Physical Access to all of {{companyShortName}} facilities is limited to only 14 | those authorized in this policy. All workforce members are 15 | responsible for reporting an incident of unauthorized visitor and/or 16 | unauthorized access to {{companyShortName}}'s facility. 17 | 18 | {{#needStandardHIPAA}} 19 | {{companyShortName}} and its Subcontractors control access to the physical 20 | buildings/facilities that house these systems/applications, or in which 21 | {{companyShortName}} workforce members operate, in accordance to the HIPAA 22 | Security Rule 164.310 and its implementation specifications. In an effort to 23 | safeguard ePHI from unauthorized access, tampering, and theft, access is allowed 24 | to areas only to those persons authorized to be in them and with escorts for 25 | unauthorized persons. 26 | {{/needStandardHIPAA}} 27 | 28 | ## Policy Statements 29 | 30 | {{companyShortName}} policy requires that 31 | 32 | (a) Physical access to {{companyShortName}} facilities is restricted. 33 | 34 | (b) All employees are required to wear employee badges at secure facilities 35 | (such as server rooms, data centers, labs). 36 | 37 | (c) All employees must follow physical security requirements and procedures 38 | documented by facility management. 39 | 40 | (d) On-site visitors and vendors must be escorted by a {{companyShortName}} employee at all 41 | times while on premise. 42 | 43 | (e) All workforce members are responsible for reporting an incident of 44 | unauthorized visitor and/or unauthorized access to {{companyShortName}}'s facility. 45 | 46 | (f) Retain a record for each physical access, including visits, maintenance and 47 | repairs to {{companyShortName}} production environments and secure facilities. 48 | 49 | * Details must be captured for all maintenance and repairs performed to 50 | physical security equipment such as locks, walls, doors, surveillance 51 | cameras; and 52 | * All records must be retained for the defined, predetermined timeframe. 53 | 54 | (g) Building security, such as fire extinguishers and detectors, escape routes, 55 | floor warden responsibilities, shall be maintained according to applicable laws 56 | and regulations. -------------------------------------------------------------------------------- /templates/policies/hr.md.tmpl: -------------------------------------------------------------------------------- 1 | # HR and Personnel Security 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} is committed to ensuring all workforce members actively address 6 | security and compliance in their roles at {{companyShortName}}. We encourage self management 7 | and reward the right behaviors. This policy specifies acceptable use of end-user 8 | computing devices and technology. Additionally, training is imperative to 9 | assuring an understanding of current best practices, the different types and 10 | sensitivities of data, and the sanctions associated with non-compliance. 11 | 12 | ## Policy Statements 13 | 14 | In addition to the roles and responsibilities stated [earlier](rar.md), 15 | {{companyShortName}} policy requires all workforce members to comply with the 16 | Acceptable Use Policy for End-use Computing and HR Security Policy. 17 | 18 | {{companyShortName}} policy requires that: 19 | 20 | (a) Background verification checks on all candidates for employees and 21 | contractors should be carried out in accordance with relevant laws, regulations, 22 | and ethics, and proportional to the business requirements, the classification of 23 | the information to be accessed, and the perceived risk. 24 | 25 | (b) Employees, contractors and third party users must agree and sign the terms 26 | and conditions of their employment contract, and comply with acceptable use. 27 | 28 | (c) Employees will go through an onboarding process that familiarizes them with 29 | the environments, systems, security requirements, and procedures {{companyShortName}} has in 30 | place. Employees will also have ongoing security awareness training that is 31 | audited. 32 | 33 | (d) Employee offboarding will include reiterating any duties and 34 | responsibilities still valid after terminations, verifying that access to any 35 | {{companyShortName}} systems has been removed, as well as ensuring that all company owned 36 | assets are returned. 37 | 38 | (e) {{companyShortName}} and its employees will take reasonable measures to 39 | ensure no sensitive data is transmitted via digital communications such as email 40 | or posted on social media outlets. 41 | 42 | (f) {{companyShortName}} will maintain a list of prohibited activities that will be part of 43 | onboarding procedures and have training available if/when the list of those 44 | activities changes. 45 | 46 | (g) A fair disciplinary process will be utilized for employees that are suspected of 47 | committing breaches of security. Multiple factors will be considered when 48 | deciding the response such as whether or not this was a first offense, training, 49 | business contracts, etc. {{companyShortName}} reserves the right to terminate employees in 50 | the case of serious cases of misconduct. 51 | -------------------------------------------------------------------------------- /templates/policies/ir.md.tmpl: -------------------------------------------------------------------------------- 1 | # Incident Response 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} implements an information security incident response process to 6 | consistently detect, respond, and report incidents, minimize loss and 7 | destruction, mitigate the weaknesses that were exploited, and restore 8 | information system functionality and business continuity as soon as possible. 9 | 10 | The incident response process addresses: 11 | 12 | * Continuous monitoring of threats through intrusion detection systems (IDS) and 13 | other monitoring applications; 14 | * Establishment of an information security incident response team; 15 | * Establishment of procedures to respond to media inquiries; 16 | * Establishment of clear procedures for identifying, responding, assessing, 17 | analyzing, and follow-up of information security incidents; 18 | * Workforce training, education, and awareness on information security incidents 19 | and required responses; and 20 | * Facilitation of clear communication of information security incidents with 21 | internal, as well as external, stakeholders 22 | 23 | {{#needStandardHIPAA}} 24 | !!! Note 25 | 26 | These policies were adapted from work by the [HIPAA Collaborative of Wisconsin Security Networking Group](http://hipaacow.org/wp-content/uploads/2015/02/HCR-Security-Incident-Response-FINAL-12.18.14.doc). Refer to the linked document for additional copyright information. 27 | 28 | {{/needStandardHIPAA}} 29 | 30 | ## Policy Statements 31 | 32 | {{companyShortName}} policy requires that: 33 | 34 | (a) All computing environments and systems must be monitored in accordance to 35 | the policies and procedures specified in the following {{companyShortName}} policies and 36 | procedures: 37 | 38 | * Auditing 39 | * System Access 40 | * End-user Computing and Acceptable Use 41 | 42 | (b) All alerts must be reviewed to identify security incidents. 43 | 44 | (c) Incident response procedures are invoked upon discovery of a valid security 45 | incident. 46 | 47 | (d) Incident response team and management must comply with any additional 48 | requests by law enforcement in the event of criminal investigation or national 49 | security, including but not limited to warranted data requests, subpoenas, and 50 | breach notifications. -------------------------------------------------------------------------------- /templates/policies/mdm.md.tmpl: -------------------------------------------------------------------------------- 1 | # Mobile Device Security and Storage Media Management 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} recognizes that media containing sensitive data may be 6 | reused when appropriate steps are taken to ensure that all stored sensitive data 7 | has been effectively rendered inaccessible. Destruction/disposal of sensitive 8 | data shall be carried out in accordance with federal and state law. The schedule 9 | for destruction/disposal shall be suspended for sensitive data involved in any 10 | open investigation, audit, or litigation. 11 | 12 | {{companyShortName}} utilizes virtual storage repositories to store production data. Volumes and repositories 13 | utilized by {{companyShortName}} and {{companyShortName}} Customers are 14 | encrypted. {{companyShortName}} does not use, own, or manage any mobile devices, 15 | removable storage media, or backup tapes that have access to sensitive data. 16 | 17 | ## Policy Statements 18 | 19 | {{companyShortName}} policy requires that: 20 | 21 | (a) All media, including mobile and removable media, storing {{companyShortName}} company 22 | data must be encrypted. 23 | 24 | (b) Critical data as defined in [{{companyShortName}} data classification model 25 | §data-management](data-mgmt.md) may not be stored on mobile devices or removable 26 | media such as USB flash drives. 27 | 28 | (c) All destruction/disposal of sensitive data storage media will be done in 29 | accordance with federal and state laws and regulations and pursuant to the 30 | {{companyShortName}}'s written retention policy/schedule. 31 | 32 | * Records that have satisfied the period of retention will be 33 | destroyed/disposed of in an appropriate manner. 34 | * Records involved in any open investigation, audit or litigation should not 35 | be destroyed/disposed of. 36 | 37 | (d) All sensitive data must rendered inaccessible in a forensically sound manner 38 | prior to media reuse or disposal. 39 | 40 | (e) Mobile devices, including laptops, smart phones and tables, used in support 41 | of critical business operations shall be fully managed and/or audited by 42 | {{companyShortName}} IT and Security. 43 | -------------------------------------------------------------------------------- /templates/policies/model.md.tmpl: -------------------------------------------------------------------------------- 1 | # Security Architecture and Operating Model 2 | 3 | `{{defaultRevision}}` 4 | 5 | In the digital age, cyber attacks are inevitable. At {{companyShortName}}, we are taking a 6 | “zero trust”, “minimal infrastructure” approach to managing risk and information 7 | security. 8 | 9 | This document describes our guiding principles and aspirations in managing risk 10 | and the building blocks of our security model. 11 | 12 | ## Policy Statements 13 | 14 | {{companyShortName}} policy requires that: 15 | 16 | (a) {{companyShortName}}'s security program and operations should be designed and 17 | implemented with the following objectives and best practices: 18 | 19 | * data-centric, cloud-first 20 | * assume compromise therefore never trust, always verify 21 | * apply controls using least-privilege and defense-in-depth principles 22 | * avoid single point of compromise 23 | * automate whenever possible, the simpler the better, less is more 24 | * prompt self management and reward good behaviors 25 | 26 | (b) Security shall remain a top priority in all aspects of {{companyShortName}}'s business 27 | operations and product development. -------------------------------------------------------------------------------- /templates/policies/policy-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | # Policy Management 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} implements policies and procedures to maintain compliance and integrity 6 | of data. The Security Officer and Privacy Officer are responsible for 7 | maintaining policies and procedures and assuring all {{companyShortName}} workforce members, 8 | business associates, customers, and partners are adherent to all applicable 9 | policies. Previous versions of policies are retained to assure ease of finding 10 | policies at specific historic dates in time. 11 | 12 | ## Policy Statements 13 | 14 | {{companyShortName}} policy requires that: 15 | 16 | (a) {{companyShortName}} policies must be developed and maintained to meet all 17 | applicable compliance requirements adhere to security best practices, including 18 | but not limited to: 19 | 20 | {{#needStandardHIPAA}} 21 | - HIPAA 22 | {{/needStandardHIPAA}} 23 | {{#needStandardHITRUST}} 24 | - HITRUST 25 | {{/needStandardHITRUST}} 26 | {{#needStandardGDPR}} 27 | - GDPR 28 | {{/needStandardGDPR}} 29 | {{#needStandardNIST}} 30 | - NIST 31 | {{/needStandardNIST}} 32 | - SOC 2 33 | 34 | (b) All policies must be reviewed at least annually. 35 | 36 | (c) All policy changes must be approved by {{companyShortName}} Security Officer. Additionally, 37 | 38 | * Major changes may require approval by {{companyShortName}} CEO or designee; 39 | * Changes to policies and procedures related to product development may 40 | require approval by the Head of Engineering. 41 | 42 | (d) All policy documents must be maintained with version control, and previous 43 | versions must be retained for a defined, predetermined timeframe. 44 | 45 | (e) Policy exceptions are handled on a case-by-case basis. 46 | 47 | * All exceptions must be fully documented with business purpose and reasons 48 | why the policy requirement cannot be met. 49 | * All policy exceptions must be approved by both {{companyShortName}} Security Officer and COO. 50 | * An exception must have an expiration date no longer than one year from date 51 | of exception approval and it must be reviewed and re-evaluated on or before 52 | the expiration date. 53 | -------------------------------------------------------------------------------- /templates/policies/privacy.md.tmpl: -------------------------------------------------------------------------------- 1 | # Privacy and Consent 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} is committed to protecting the privacy of our customers. 6 | 7 | ## Policy Statements 8 | 9 | {{companyShortName}} policy requires that: 10 | 11 | (a) Privacy policy shall be made available to inform Customers how {{companyShortName}} 12 | collects, uses, secures and shares customer information. 13 | 14 | (b) Valid consent must be obtained for data collected from a Customer and the 15 | purposes data is used for must be provided. Customer must be provided an option 16 | to opt-in or opt-out. -------------------------------------------------------------------------------- /templates/policies/program.md.tmpl: -------------------------------------------------------------------------------- 1 | # Security Program Overview 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} is committed to protecting its employees, partners, 6 | clients/customers and the company itself from damaging acts either malicious or 7 | unintentional in nature. This includes implementation of policies, standards, 8 | controls and procedures to ensure the Confidentiality, Integrity, and 9 | Availability of systems and data according to their risk level. 10 | 11 | The {{companyShortName}} security program and policies are developed on the 12 | principles that (1) security is everyone's responsibility and (2) 13 | self-management is best encouraged by rewarding the right behaviors. 14 | 15 | !!! TLDR 16 | 17 | [Quick Reference / Employee Handbook](employee-handbook.md) 18 | -------------------------------------------------------------------------------- /templates/policies/ref.md.tmpl: -------------------------------------------------------------------------------- 1 | # Addendum and References 2 | 3 | The following is a list of policy addendum and references. 4 | -------------------------------------------------------------------------------- /templates/policies/risk-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | # Risk Management 2 | 3 | `{{defaultRevision}}` 4 | 5 | This policy establishes the scope, objectives, and procedures of {{companyShortName}}'s 6 | information security risk management process. The risk management process is 7 | intended to support and protect the organization and its ability to fulfill its 8 | mission. 9 | 10 | ## Policy Statements 11 | 12 | {{companyShortName}} policy requires that: 13 | 14 | (a) A thorough risk assessment must be conducted to evaluate the potential 15 | threats and vulnerabilities to the confidentiality, integrity, and availability 16 | of sensitive, confidential and proprietary electronic information it stores, 17 | transmits, and/or processes. 18 | 19 | (b) Risk assessments must be performed with any major change to {{companyShortName}}'s 20 | business or technical operations and/or supporting infrastructure, no less than 21 | once per year. 22 | 23 | (c) Strategies shall be developed to mitigate or accept the risks identified in 24 | the risk assessment process. 25 | 26 | (d) Maintain documentation of all risk assessment, risk management, and risk 27 | mitigation efforts for a minimum of seven years. 28 | -------------------------------------------------------------------------------- /templates/policies/sdlc.md.tmpl: -------------------------------------------------------------------------------- 1 | # Secure Software Development and Product Security 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} development team follows the latest security best practices when 6 | developing software, and automates security testing throughout development 7 | lifecycle whenever possible. 8 | 9 | Security is integrated into all phases of {{companyShortName}} product development lifecycle, 10 | including: 11 | 12 | * Secure Design: 13 | 14 | - App Risk classification 15 | - Security req definition 16 | - Secure application design / RFC 17 | - Threat modeling 18 | - App data flow analysis 19 | 20 | * Secure Development and Testing: 21 | 22 | - Secure coding guidelines 23 | - Peer review 24 | - Security testing, for example: 25 | 26 | - Linting with security rules 27 | - Open source security analysis 28 | - Static secure code analysis 29 | - Dynamic security analysis 30 | - Penetration testing 31 | 32 | - Responsible vulnerability disclosure / bug bounty program 33 | 34 | * Remediation: 35 | 36 | - Follows defined vulnerability management lifecycle 37 | - Ensures no high risk security vulnerability is in production 38 | 39 | Details about the {{companyShortName}} software application architecture and 40 | security are documented on the [product development / engineering wiki]({{&devWikiURL}}). 41 | 42 | ## Policy Statements 43 | 44 | {{companyShortName}} policy requires that: 45 | 46 | (a) {{companyShortName}} software engineering and product development is required to follow 47 | security best practices. Product should be "Secure by Design" and "Secure by 48 | Default". 49 | 50 | (b) Quality assurance activities must be performed. This may include 51 | 52 | * peer code reviews prior to merging new code into the main development branch 53 | (e.g. master branch); and 54 | * thorough product testing before releasing to production (e.g. unit testing 55 | and integration testing). 56 | 57 | (c) Risk assessment activities (i.e. threat modeling) must be performed for a 58 | new product or major changes to an existing product. 59 | 60 | (d) Security requirements must be defined, tracked, and implemented. 61 | 62 | (e) Security analysis must be performed for any open source software and/or 63 | third-party components and dependencies included in {{companyShortName}} software products. 64 | 65 | (f) Static application security testing (SAST) must be performed throughout 66 | development and prior to each release. 67 | 68 | (g) Dynamic application security testing (DAST) must be performed prior to each 69 | release. 70 | 71 | (h) All critical or high severity security findings must be remediated prior to 72 | each release. 73 | 74 | (i) All critical or high severity vulnerabilities discovered post release must 75 | be remediated in the next release or within the defined, predetermined timeframe. 76 | 77 | (j) Any exception to the remediation of a finding must be documented and 78 | approved by the security team. -------------------------------------------------------------------------------- /templates/policies/system-audit.md.tmpl: -------------------------------------------------------------------------------- 1 | # System Audits, Monitoring and Assessments 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} shall audit, monitor, and assess the access and activity of 6 | systems and applications that process or store production and/or sensitive data 7 | such as personally identifiable information (PII) 8 | {{#needStandardHIPAA}} 9 | and electronic protected health information (ePHI) 10 | {{/needStandardHIPAA}} 11 | in order to ensure compliance. 12 | 13 | {{#needStandardHIPAA}} 14 | It is required by the HIPAA Security Rule, that healthcare organizations to 15 | implement reasonable hardware, software, and/or procedural mechanisms that 16 | record and examine activity in information systems that contain or use ePHI. 17 | {{/needStandardHIPAA}} 18 | 19 | Audit activities may be limited by application, system, and/or network auditing 20 | capabilities and resources. {{companyShortName}} shall make reasonable and 21 | good-faith efforts to safeguard information privacy and security through a 22 | well-thought-out approach to auditing that is consistent with available 23 | resources. 24 | 25 | It is the policy of {{companyShortName}} to safeguard the confidentiality, integrity, and 26 | availability of applications, systems, and networks. To ensure that appropriate 27 | safeguards are in place and effective, {{companyShortName}} shall audit access and activity 28 | to detect, report, and guard against: 29 | 30 | * Network vulnerabilities and intrusions; 31 | * Breaches in confidentiality and security of sensitive information; 32 | * Performance problems and flaws in applications; 33 | * Improper alteration or destruction of sensitive information; 34 | * Out of date software and/or software known to have vulnerabilities. 35 | 36 | This policy applies to all {{companyShortName}} systems that store, transmit, or process 37 | sensitive information. 38 | 39 | ## Policy Statements 40 | 41 | {{companyShortName}} policy requires that: 42 | 43 | (a) All critical computing systems and software, both virtual and physical, must 44 | enable audit logging. 45 | 46 | (b) Audit logs must include sufficient information to identify who did what, 47 | when, where. 48 | 49 | (c) An annual audit of {{companyShortName}} security controls must be conducted, either by a 50 | designated internal audit team or a qualified external audit firm. 51 | -------------------------------------------------------------------------------- /templates/policies/threat.md.tmpl: -------------------------------------------------------------------------------- 1 | # Threat Detection and Prevention 2 | 3 | `{{defaultRevision}}` 4 | 5 | In order to preserve the integrity of data that {{companyShortName}} stores, processes, or 6 | transmits for Customers, {{companyShortName}} implements strong intrusion detection tools 7 | and policies to proactively track and retroactively investigate unauthorized 8 | access. This include threat detection and prevention at both the network and 9 | host level, as well as threat intelligence monitoring. 10 | 11 | ## Policy Statements 12 | 13 | {{companyShortName}} policy requires that: 14 | 15 | (a) All critical systems, assets and environments must implement realtime threat 16 | detection or prevention. 17 | -------------------------------------------------------------------------------- /templates/policies/vendor.md.tmpl: -------------------------------------------------------------------------------- 1 | # Third Party Security, Vendor Risk Management and Systems/Services Acquisition 2 | 3 | `{{defaultRevision}}` 4 | 5 | {{companyShortName}} makes every effort to assure all third party organizations are 6 | compliant and do not compromise the integrity, security, and privacy of {{companyShortName}} 7 | or {{companyShortName}} Customer data. Third Parties include Vendors, Customers, Partners, 8 | Subcontractors, and Contracted Developers. 9 | 10 | ## Policy Statements 11 | 12 | {{companyShortName}} policy requires that: 13 | 14 | (a) A list of approved vendors/partners must be maintained and reviewed 15 | annually. 16 | 17 | (b) Approval from management, procurement and security must be in place prior to 18 | onboarding any new vendor or contractor. Additionally, all changes to existing 19 | contract agreements must be reviewed and approved prior to implementation. 20 | 21 | (c) For any technology solution that needs to be integrated with {{companyShortName}} 22 | production environment or operations, a Vendor Technology Review must be 23 | performed by the security team to understand and approve the risk. Periodic 24 | compliance assessment and SLA review may be required. 25 | 26 | (d) {{companyShortName}} Customers or Partners should not be allowed access outside of their 27 | own environment, meaning they cannot access, modify, or delete any data 28 | belonging to other 3rd parties. 29 | 30 | (e) Additional vendor agreements are obtained as required by applicable 31 | regulatory compliance requirements. 32 | 33 | {{#needStandardHIPAA}} 34 | * A standard HIPAA Business Associate Agreement (BAA) is defined and includes 35 | the required security controls in accordance with the organization's security 36 | policies. Additionally, responsibility is assigned in these agreements. A BAA 37 | must be signed with any vendor that may have a business need to access, and/or 38 | unsupervised access to PHI or ePHI. 39 | {{/needStandardHIPAA}} 40 | 41 | {{#needStandardGDPR}} 42 | * A GDPR Data Processing Agreement/Addendum (DPA) is defined and executed for 43 | each {{companyShortName}} vendor/contractor that processes personal data of 44 | EU users. 45 | {{/needStandardGDPR}} 46 | -------------------------------------------------------------------------------- /templates/policies/vuln-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | # Vulnerability Management 2 | 3 | `{{defaultRevision}}` 4 | 5 | ## Policy Statements 6 | 7 | {{companyShortName}} policy requires that: 8 | 9 | (a) All product systems must be scanned for vulnerability on the defined, predetermined schedule and 10 | with each major change, as applicable. 11 | 12 | (b) All vulnerability findings must be reported and tracked to resolution. 13 | Records of findings must be retained for a defined, predetermined timeframe. 14 | -------------------------------------------------------------------------------- /templates/procedures/cp-access-customer.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Platform Customer Access to Systems 2 | 3 | {{companyShortName}} does not allow direct system access by customers. Access is only 4 | available through the Web UI or API interface, with valid authentication and 5 | authorization detailed in the Product Security, Architecture, and Security 6 | pages of the engineering wiki. -------------------------------------------------------------------------------- /templates/procedures/cp-access-endpoints.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Employee Workstation / Endpoints Access and Usage 2 | 3 | All workstations at {{companyShortName}} are company owned, using one the following approved 4 | hardware vendors and operating systems: 5 | 6 | * Apple, Dell, or Lenovo 7 | * macOS, Linux (Ubuntu or Debian), or Windows 10 8 | 9 | 1. Workstations may not be used to engage in any activity that is illegal or is 10 | in violation of organization's policies. 11 | 1. Access may not be used for transmitting, retrieving, or storage of any 12 | communications of a discriminatory or harassing nature or materials that are 13 | obscene or "X-rated". Harassment of any kind is prohibited. No messages with 14 | derogatory or inflammatory remarks about an individual's race, age, 15 | disability, religion, national origin, physical attributes, sexual 16 | preference, or health condition shall be transmitted or maintained. No 17 | abusive, hostile, profane, or offensive language is to be transmitted through 18 | organization's system. 19 | 1. Information systems/applications also may not be used for any other purpose 20 | that is illegal, unethical, or against company policies or contrary to 21 | organization's best interests. Messages containing information related to a 22 | lawsuit or investigation may not be sent without prior approval. 23 | 1. Solicitation of non-company business, or any use of organization's 24 | information systems/applications for personal gain is prohibited. 25 | 1. Users may not misrepresent, obscure, suppress, or replace another user's 26 | identity in transmitted or stored messages. 27 | 1. Workstation hard drives will be encrypted using FileVault (macOS), BitLocker 28 | (Windows) or equivalent. 29 | 1. All workstations must have host firewalls enabled to prevent unauthorized 30 | access unless explicitly granted. 31 | 1. All workstations must have endpoint security software installed and actively 32 | running, if supported by the operating system. -------------------------------------------------------------------------------- /templates/procedures/cp-access-mfa.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Multi-factor Authentication 2 | 3 | Multi-factor authentication (MFA) is a standard control used by {{companyShortName}} to 4 | provide strong access control to critical systems and applications, and should 5 | be enabled whenever possible. 6 | 7 | {{companyShortName}} implements {{provider}} for MFA. 8 | 9 | !!! important 10 | 11 | **Approved MFA methods include:** 12 | 13 | - Push notification delivered through the {{provider}} mobile app (default and preferred for end-user access) 14 | - Hardware MFA token (required for the root user of AWS accounts) 15 | - A unique cryptographic certificate tied to a device 16 | - Time-based One-Time Password (TOTP) delivered through a mobile app, such as Google Authenticator 17 | - One-time passcode delivered through SMS text message (if it is the only supported option) 18 | - Secure physical facility (if the system or application can only be accessed at that location) 19 | -------------------------------------------------------------------------------- /templates/procedures/cp-access-phi.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Access to PHI/ePHI 2 | 3 | 1. Access to ePHI is permitted to genomics science staff, or staff that 4 | otherwise has a business need to access. 5 | 1. Access to any on-premise server that contains ePHI is restricted and 6 | monitored. *Currently {{companyShortName}} has no on-premise server that stores or 7 | processes ePHI.* 8 | 1. Access to ePHI in {{companyShortName}}'s production environments in the cloud is strictly 9 | prohibited. Access is protected via multiple layers of security controls 10 | such as IAM policies, restricted IAM roles, VPC configuration, S3 bucket 11 | policy, external monitoring, etc. 12 | 1. Users may not download ePHI to any workstations or end-user computing 13 | devices. 14 | -------------------------------------------------------------------------------- /templates/procedures/cp-access-privileged.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Privileged Access 2 | 3 | Privileged users must first access systems using standard, unique user accounts 4 | before elevating the privilege or switching to privileged users and performing 5 | privileged tasks. Examples include: 6 | 7 | * `sudo` in Linux/macOS 8 | * `Run as Administrator` in Windows 9 | * `Assume role` in AWS -------------------------------------------------------------------------------- /templates/procedures/cp-access-prod-data.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Production Data Access 2 | 3 | The following requirements and controls are in place for accessing production 4 | data by internal personnel: 5 | 6 | - There is no pre-provisioned, persisted "internal" access to production data 7 | stores. Access such as direct SSH to the production database servers and 8 | direct access to data objects in production S3 buckets are prohibited. 9 | 10 | - Access to customer data is granted on a per-account basis. 11 | 12 | - Access requests follow the same production access processes. Access must be 13 | approved by both the data owner and the security team. 14 | 15 | - Access to production data is granted only through an approved platform with 16 | strong centralized access control, with MFA. 17 | 18 | - An audit list of who has access to which customer data is maintained and 19 | reviewed monthly. Access is revoked when no longer needed. 20 | -------------------------------------------------------------------------------- /templates/procedures/cp-access-prod.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Production Access and Secrets Management 2 | 3 | {{companyShortName}} leverages a combination of [{{ciSystem}} credentials 4 | store](https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-{{ciSystem}}-Build-Jobs), 5 | [credstash](https://github.com/fugue/credstash), and [Amazon EC2 Systems Manager 6 | Parameter 7 | Store](https://aws.amazon.com/blogs/mt/the-right-way-to-store-secrets-using-parameter-store/) 8 | to securely store production secrets. Secrets are always encrypted; access to 9 | secrets is always controlled and audited. 10 | 11 | Details and usage are documented on the {{companyShortName}} Engineering Wiki. -------------------------------------------------------------------------------- /templates/procedures/cp-access-rbac.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Role Based Access Control (RBAC) 2 | 3 | By default, user access is granted based on the user's job function / role. 4 | For example: 5 | 6 | - Developer 7 | - Security 8 | - IT 9 | - Administrative 10 | - Marketing / Sales 11 | 12 | This is defined as **user groups** in {{IdP}}. 13 | 14 | Access to sensitive data and production customer data is highly restricted and 15 | further defined in its own section. 16 | -------------------------------------------------------------------------------- /templates/procedures/cp-access-reset.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Password Reset and other Helpdesk Requests 2 | 3 | {{companyShortName}} employees have the ability to obtain self-service support directly from 4 | supported business applications, such as password reset via the SSO/IdP tool. 5 | 6 | If needed, users may use our internal service desk or email request to obtain IT 7 | and Security support. 8 | 9 | A ticket is opened in {{ticketingSystem}} for each support request and assigned to the 10 | appropriate personnel. The person assigned must verify the identity of the 11 | requester and ensure the ticket has appropriate approval before implementing or 12 | providing support. The verification step and confirmation of "User identity 13 | verified" should be included as a comment in the ticket by the support 14 | personnel. Additionally, if a password or security credential has been created 15 | or supplied, confirm user has received it via another channel like 16 | slack/email/phone/zoom and document receipt in the ticket. -------------------------------------------------------------------------------- /templates/procedures/cp-access-review.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Access Reviews 2 | 3 | * All access to {{companyShortName}} systems and services are reviewed and updated following 4 | the procedures specified in [System Auditing](system-audit.md) to ensure proper 5 | authorizations are in place commensurate with job functions. 6 | * In cases of increased risk or known attempted unauthorized access, immediate 7 | steps are taken by the Security and Privacy Officer to limit access and reduce 8 | risk of unauthorized access. -------------------------------------------------------------------------------- /templates/procedures/cp-access-service.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Service Accounts 2 | 3 | * All application to application communication using service accounts is 4 | restricted and not permitted unless absolutely needed. Automated tools are 5 | used to limit account access across applications and systems. 6 | 7 | * Services that are part of {{companyShortName}} platform leverage AWS IAM policy 8 | configurations and/or OAuth for authorization. 9 | 10 | * Generic accounts are not allowed on {{companyShortName}} systems. 11 | 12 | * Direct system to system, system to application, and application to application 13 | authentication and authorization are limited and controlled to restrict 14 | access. 15 | 16 | * In AWS, service accounts are implemented in the form of IAM Roles, and their 17 | access defined by the corresponding IAM policies. The creation of these IAM 18 | roles and policies is implemented as code, which follows the secure 19 | development, review and production change approval process. 20 | 21 | * An inventory of all Service accounts is maintained by {{provider}} and 22 | reviewed periodically. -------------------------------------------------------------------------------- /templates/procedures/cp-access-sso.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Single Sign On 2 | 3 | * {{companyShortName}} selected {{provider}} as its primary Identity Provider (IdP) to control 4 | user access to systems and business applications. 5 | 6 | * Single sign-on (SSO) should be used whenever possible instead of local 7 | authentication. This centralized approach improves user experience and 8 | simplifies access management. 9 | 10 | * SSO is configured via industry standard SAML protocol between the IdP ({{provider}}) 11 | and the target application. 12 | 13 | * {{companyShortName}} will not configure SSO to target applications unless they score a 14 | "B" rating or higher on the [Qualys SSL Labs](https://www.ssllabs.com/) 15 | benchmark. 16 | 17 | * Security team is responsible for the administration of the IdP / SSO system, 18 | including user and access provisioning. Security team may delegate 19 | administrative privilege to a subset of the system, such as a specific 20 | application. -------------------------------------------------------------------------------- /templates/procedures/cp-access-standards.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Standards for Access Provisioning 2 | 3 | #### Workforce Clearance 4 | 5 | 1. The level of security assigned to a user to the organization's information 6 | systems is based on the minimum necessary amount of data access required to 7 | carry out legitimate job responsibilities assigned to a user's job 8 | classification and/or to a user needing access to carry out treatment, 9 | payment, or healthcare operations. 10 | 1. All access requests are treated on a "least-privilege" principle. 11 | 1. {{companyShortName}} maintains a minimum necessary approach to access to Customer data. 12 | {{#needStandardHIPAA}} 13 | As such, {{companyShortName}}, including all workforce members, does not readily have 14 | access to any ePHI. 15 | {{/needStandardHIPAA}} 16 | 17 | #### Access Authorization 18 | 19 | 1. Role based access categories for each {{companyShortName}} system and application are 20 | pre-approved by the Security Officer. 21 | 2. {{companyShortName}} utilizes hardware-defined and/or software-defined boundaries to 22 | segment data, prevent unauthorized access, and monitor traffic for denial of 23 | service attacks. 24 | 25 | #### Person or Entity Authentication 26 | 27 | 1. Each workforce member has and uses a unique user ID and password that 28 | identifies him/her as the user of the information system. 29 | 1. Each Customer and Partner has and uses a unique user ID and password or 30 | OpenID Connect that identifies him/her as the user of the information system. 31 | This is enforced through the use of **AWS Cognito**. 32 | 1. All customer support interactions must be verified before {{companyShortName}} support 33 | personnel will satisfy any request having information security implications. 34 | 35 | #### Unique User Identification 36 | 37 | 1. Access to the {{companyShortName}} Platform systems and applications is controlled by 38 | requiring unique User Login IDs and passwords for each individual user and 39 | developer. 40 | 1. Passwords requirements mandate strong password controls (see below). 41 | 1. Passwords are not displayed at any time and are not transmitted or stored in 42 | plain text. 43 | 1. Default accounts on all production systems and environments, including root, 44 | are disabled/locked. 45 | 1. Shared accounts are not allowed within {{companyShortName}} systems or networks. 46 | 47 | #### Automatic Logon and Logoff 48 | 49 | 1. Automated log-on configurations that store user passwords or bypass password 50 | entry are not permitted for use with {{companyShortName}} workstations or production 51 | systems. 52 | 53 | * Automatic log-on may only be permitted for low-risk systems such as 54 | conference room PCs connecting to a Zoom Room. 55 | * Such systems are configured on separate network VLANs. 56 | 57 | 1. Users are required to make information systems inaccessible by any other 58 | individual when unattended by the users (ex. by using a password protected 59 | screen saver or logging off the system). 60 | 1. Information systems automatically lock users such as enabling 61 | password-protected screensaver after 2 minutes or less of inactivity. 62 | 1. Information systems automatically enter standby or log users off the systems 63 | after 30 minutes or less of inactivity. 64 | 1. The Security Officer must pre-approves any exception to automatic log off 65 | requirements. -------------------------------------------------------------------------------- /templates/procedures/cp-access-vpn.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Remote Access / VPN 2 | 3 | * VPN remote access to non-production and non-privileged environments in AWS are 4 | permissible and implemented using **{{provider}}**. 5 | 6 | * VPN remote access to master and production accounts are prohibited. 7 | 8 | * VPN remote access to {{companyShortName}} office network(s) is configured via 9 | **{{provider}}**, and should be used whenever connecting from public networks. 10 | -------------------------------------------------------------------------------- /templates/procedures/cp-access-wifi.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Office Network and Wireless Access 2 | 3 | 1. {{companyShortName}} production systems are not accessible directly over wireless 4 | channels. 5 | 2. Wireless access is disabled on all production systems. 6 | 3. When accessing production systems via remote wireless connections, the same 7 | system access policies and procedures apply to wireless as all other 8 | connections, including wired. 9 | 4. Wireless networks managed within {{companyShortName}} non-production facilities (offices, 10 | etc.) are secured with the following configurations: 11 | 12 | * All data in transit over wireless is encrypted using WPA2 encryption; 13 | * Passwords are not currently on a rotation schedule because the office 14 | environments are considered insecure. 15 | * Passwords are changed immediately should a suspicious activity or 16 | indicator of compromise is detected. 17 | * Guest wireless access is on a separate SSID configured with different 18 | password and traffic VLAN. 19 | * Wireless access is managed by the IT Manager. 20 | * Wireless access points connected to the network are automatically 21 | scanned; rogue access points identified are immediately removed. -------------------------------------------------------------------------------- /templates/procedures/cp-asset-digital.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Digital Asset Inventory 2 | 3 | {{companyShortName}} Security team uses an automated system to query across our cloud-based 4 | infrastructure, including but is not limited to AWS, to obtain detailed records 5 | of all digital assets, including but not limited to: 6 | 7 | * Virtual machines 8 | * AWS EC2 instances 9 | * AWS S3 repositories 10 | * AWS Lambda functions 11 | * Security agents 12 | * Source code repositories 13 | * User accounts 14 | 15 | The records are stored in a database system maintained by {{companyShortName}} security 16 | team. Records are tagged with owner/project and classification when applicable. 17 | All records are kept up to date via automation. -------------------------------------------------------------------------------- /templates/procedures/cp-asset-paper.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Paper Records 2 | 3 | {{companyShortName}} does not use paper records for any sensitive information. Use of paper 4 | for recording and storing sensitive data is against {{companyShortName}} policies. -------------------------------------------------------------------------------- /templates/procedures/cp-asset-physical.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Physical Asset Inventory 2 | 3 | {{companyShortName}} IT leverages a SaaS-based IT asset management system, 4 | {{provider}}, to maintain inventory of all company 5 | owned physical computing equipment, including but not limited to: 6 | 7 | * servers 8 | * workstations 9 | * laptops 10 | * printers 11 | * networking equipment 12 | 13 | Each record includes details of the physical device such as manufacturer, model 14 | as well as ownership details and property tag ID. 15 | 16 | The movement of computing hardware and electronic media is maintained as part of 17 | the records, including media re-use and ownership reassignment. 18 | 19 | {{companyShortName}} IT manager is responsible for ensuring each physical asset is applied 20 | with a {{companyShortName}} property tag, and an up-to-date record is maintained in the IT 21 | asset management system. 22 | 23 | All company-owned devices are subject to a complete data wipe if deemed necessary, such as in the 24 | case of device infection or repurpose. This data wipe will be carried out by the IT manager. 25 | -------------------------------------------------------------------------------- /templates/procedures/cp-audit-control-deficiency.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Remediation of Control Deficiencies 2 | 3 | Most controls are continuously monitored and reported via automation on the 4 | {{provider}} platform. 5 | 6 | Control deficiencies identified as a result of an internal or external system 7 | audit are documented and reviewed with management. 8 | 9 | Security team works with the corresponding control owner to prioritize and 10 | mitigate the control deficiency, including applying corrective actions, 11 | implementating additional controls or adjusting existing controls as needed. 12 | -------------------------------------------------------------------------------- /templates/procedures/cp-audit-customers.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Auditing Customer and Partner Activity 2 | 3 | 1. Periodic monitoring of Customer and Partner activity shall be carried out to 4 | ensure that access and activity is appropriate for privileges granted and 5 | necessary to the arrangement between {{companyShortName}} and the 3rd party. 6 | {{companyShortName}} will make every effort to assure Customers and Partners 7 | do not gain access to data outside of their own environments. 8 | 9 | 1. If it is determined that the Customer or Partner has exceeded the scope of 10 | access privileges, {{companyShortName}}'s management and security must remedy 11 | the problem immediately. 12 | 13 | {{#needStandardHIPAA}} 14 | 1. If it is determined that a Customer or Partner has violated the terms of the 15 | HIPAA business associate agreement or any terms within the HIPAA regulations, 16 | {{companyShortName}} must take immediate action to remediate the situation. Continued 17 | violations may result in discontinuation of the business relationship. 18 | {{/needStandardHIPAA}} -------------------------------------------------------------------------------- /templates/procedures/cp-audit-internal.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Internal/Manual Auditing Activities 2 | 3 | Additional manual reviews, such as user accounts and access auditing, may be 4 | necessary from time to time. These activities may be triggered by the events 5 | listed above. 6 | 7 | * Responsibility for audit activity is assigned to {{companyShortName}}'s Security Officer. 8 | The Security Officer shall: 9 | 10 | * Assign the task of generating reports for audit activities to the 11 | workforce member responsible for the application, system, or network; 12 | * Assign the task of reviewing the audit reports to the workforce member 13 | responsible for the application, system, or network, the Privacy Officer, 14 | or any other individual determined to be appropriate for the task; 15 | * Organize and provide oversight to a team structure charged with audit 16 | compliance activities (e.g., parameters, frequency, sample sizes, report 17 | formats, evaluation, follow-up, etc.). 18 | * All connections to {{companyShortName}} are monitored. Access is limited to certain 19 | services, ports, and destinations. Exceptions to these rules, if created, 20 | are reviewed on an annual basis. 21 | 22 | * The manual review process shall define and include: 23 | 24 | * Description of the activity as well as rationale for performing the audit. 25 | * Identification of personnel to perform the review (workforce members shall 26 | not review audit logs that pertain to their own system activity). 27 | * Frequency of the auditing process. 28 | * Determination of significant events requiring further review and 29 | follow-up. 30 | * Identification of appropriate reporting channels for audit results and 31 | required follow-up. 32 | 33 | * Manual audits and reviews activities are tracked in {{ticketingSystem}}. 34 | 35 | * Auditing, reviews and testing may be carried out internally or provided 36 | through an external third-party vendor. Whenever possible, a third party 37 | auditing vendor should not be providing the organization IT oversight services 38 | (e.g., vendors providing IT services should not be auditing their own services 39 | to ensure separation of duties). -------------------------------------------------------------------------------- /templates/procedures/cp-audit-request.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Audit Requests 2 | 3 | 1. A request may be made for an audit for a specific cause. The request may come 4 | from a variety of sources including, but not limited to, Privacy Officer, 5 | Security Officer, Customer, Partner, or an Application owner or application 6 | user. 7 | 8 | 2. A request for an audit for specific cause must include time frame, frequency, 9 | and nature of the request. 10 | 11 | 3. A request for an audit must be reviewed and approved by {{companyShortName}}'s Privacy 12 | Officer and/or Security Officer before proceeding. Under no circumstances 13 | shall detailed audit information be shared with parties without proper 14 | permissions and access to see such data. 15 | 16 | * Should the audit disclose that a workforce member has accessed sensitive data 17 | inappropriately, the minimum necessary/least privileged information shall 18 | be shared with {{companyShortName}}'s Security Officer to determine appropriate 19 | sanction/corrective disciplinary action. 20 | * Only de-identified information shall be shared with Customer or Partner 21 | regarding the results of the investigative audit process. This information 22 | will be communicated to the appropriate personnel by {{companyShortName}}'s Privacy 23 | Officer or designee. Prior to communicating with customers and partners 24 | regarding an audit, it is recommended that {{companyShortName}} consider seeking 25 | guidance from risk management and/or legal counsel. 26 | -------------------------------------------------------------------------------- /templates/procedures/cp-audit-review.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Review and Reporting of Audit Findings 2 | 3 | 1. Audit information that is routinely gathered must be reviewed in a timely 4 | manner, at least monthly, by the responsible workforce member(s). 5 | Additional reviews are performed as needed to assure the proper data is being 6 | captured and retained. 7 | 8 | 2. The reporting process shall allow for meaningful communication of the audit 9 | findings to relevant workforce members, Customers, or Partners. 10 | 11 | * Significant findings shall be reported immediately in a written format. 12 | {{companyShortName}}'s security incident response form may be utilized to report a 13 | single event. 14 | * Routine findings shall be reported to the sponsoring leadership structure 15 | in a written report format. 16 | 17 | 3. Reports of audit results shall be limited to internal use on a minimum 18 | necessary/need-to-know basis. Audit results shall not be disclosed externally 19 | without administrative and/or legal counsel approval. 20 | 21 | 4. Security audits constitute an internal, confidential monitoring practice that 22 | may be included in {{companyShortName}}'s performance improvement activities and 23 | reporting. Care shall be taken to ensure that the results of the audits are 24 | disclosed to administrative-level oversight structures only and that 25 | information which may further expose organizational risk is shared with 26 | extreme caution. Generic security audit information may be included in 27 | organizational reports (individually-identifiable information shall not be 28 | included in the reports). 29 | 30 | 5. Whenever indicated through evaluation and reporting, appropriate corrective 31 | actions must be undertaken. These actions shall be documented and shared with 32 | the responsible workforce members, Customers, and/or Partners. 33 | -------------------------------------------------------------------------------- /templates/procedures/cp-audit-tools.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Auditing and Assessment Tools 2 | 3 | {{companyShortName}}'s Security Officer is authorized to select and use assessment tools 4 | that are designed to detect vulnerabilities and intrusions. Use of such tools 5 | against {{companyShortName}} systems and environments are prohibited by others, including 6 | Customers and Partners, without the explicit authorization of the Security 7 | Officer. These tools may include, but are not limited to: 8 | 9 | * Scanning tools and devices; 10 | * Password cracking utilities; 11 | * Network "sniffers"; 12 | * Security agents installed locally on servers and endpoints; 13 | * Passive and active intrusion detection systems; and 14 | * Penetration testing tools. 15 | 16 | Vulnerability testing software may be used to probe the network to identify what 17 | is running (e.g., operating system or product versions in place), whether 18 | publicly-known vulnerabilities have been corrected, and evaluate whether the 19 | system can withstand attacks aimed at circumventing security controls. -------------------------------------------------------------------------------- /templates/procedures/cp-audit-trails-integrity.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Audit Trail Integrity - Security Controls and Log Retention 2 | 3 | 1. Audit logs shall be protected from unauthorized access or modification, so 4 | the information they contain will be made available only if needed to 5 | evaluate a security incident or for routine audit activities as outlined in 6 | this policy. 7 | 2. All audit logs are protected in transit and encrypted at rest to control 8 | access to the content of the logs. 9 | 3. Whenever possible, audit logs shall be stored on a separate system to 10 | minimize the impact auditing may have on the privacy system and to prevent 11 | access to audit trails by those with system administrator privileges. 12 | 13 | * Separate systems are used to apply the security principle of "separation 14 | of duties" to protect audit trails from hackers. 15 | * {{companyShortName}} logging servers may include Elasticsearch, Logstash, and Kibana 16 | (ELK) as part of their baseline configuration to ease reviewing of audit 17 | log data. The ELK toolkit provides message summarization, reduction, and 18 | reporting functionality. 19 | 20 | 4. Reports summarizing audit activities shall be retained for a period of seven 21 | years. 22 | 5. Audit log data is retained locally on the audit log server or in the source 23 | environment for a period of one month. Beyond that, log data is encrypted and 24 | moved to warm storage (currently S3) using automated scripts, and is retained 25 | for a minimum of one year. 26 | 6. Raw event data may be purged after one month / 30 days as long as the 27 | required details are sufficiently covered in aggregated audit logs/reports. 28 | -------------------------------------------------------------------------------- /templates/procedures/cp-audit-training.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Training, Education, Awareness and Responsibilities 2 | 3 | 1. {{companyShortName}} workforce members are provided training, education, and 4 | awareness on safeguarding the privacy and security of business and data. 5 | {{companyShortName}}'s commitment to auditing access and activity of the 6 | information applications, systems, and networks is communicated through new 7 | employee orientation, ongoing training opportunities and events, and 8 | applicable policies. {{companyShortName}} workforce members are made aware of 9 | responsibilities with regard to privacy and security of information as well 10 | as applicable sanctions/corrective disciplinary actions should the auditing 11 | process detect a workforce member's failure to comply with organizational 12 | policies. 13 | 14 | 2. {{companyShortName}} Customers are provided with necessary information to understand 15 | {{companyShortName}} auditing capabilities. Platform Customers are responsible for the 16 | logging, auditing and retention of any application hosted outside of {{companyShortName}} 17 | environments, even though the applications may integrate with {{companyShortName}} 18 | Platform API. Customer applications hosted within the {{companyShortName}} environments 19 | will follow the auditing standards and procedures defined in this document. 20 | -------------------------------------------------------------------------------- /templates/procedures/cp-bcdr-app.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Application Service Event Recovery 2 | 3 | {{companyShortName}} will develop a status page to provide real time update and 4 | inform our customers of the status of each service. The status page is updated 5 | with details about an event that may cause service interruption / downtime. 6 | 7 | A follow up root-cause analysis details (RCA) will be available to customers 8 | upon request after the event has transpired for further details to cause and 9 | remediation plan for the future. Event Service Level 10 | 11 | #### Short (hours) 12 | 13 | * Experience a short delay in service. 14 | * {{companyShortName}} will monitor the event and determine course of action. 15 | Escalation may be required. 16 | 17 | #### Moderate (days) 18 | 19 | * Experience a modest delay in service where processes in flight may need to be 20 | restarted. 21 | * {{companyShortName}} will monitor the event and determine course of action. 22 | Escalation may be required. 23 | * {{companyShortName}} will notify customers of delay in service and provide 24 | updates on {{companyShortName}}’s status page. 25 | 26 | #### Long (a week or more) 27 | 28 | * Experience a delay in service and processes in flight may need to be 29 | restarted. 30 | * {{companyShortName}} will monitor the event and determine course of action. 31 | Escalation may be required. 32 | * {{companyShortName}} will notify customers of delay in service and provide 33 | updates on {{companyShortName}}’s status page. 34 | -------------------------------------------------------------------------------- /templates/procedures/cp-bcdr-data.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Production Environments and Data Recovery 2 | 3 | Production data is to be synchronized across multiple S3 buckets in AWS. 4 | Additionally, it is backed up to AWS Glacier for long term storage and recovery. 5 | In an event that requires data to be recovered, it will be retrieved from 6 | Glacier. 7 | 8 | {{companyShortName}} assumes that in the worst-case scenario, that one of the 9 | production environments suffers a complete data loss, the account will be 10 | reconstructed from code, and the data restored from Glacier that is hosted 11 | within a different AWS account and geolocation. 12 | 13 | Recovery of production Environments and data should follow the procedures listed 14 | above and in [Data Management - Backup and Recovery](data-mgmt.md#cp-data-backup) 15 | -------------------------------------------------------------------------------- /templates/procedures/cp-bcdr-site.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Work Site Recovery 2 | 3 | In the event a {{companyShortName}} facility is not functioning due to a 4 | disaster, employees will work from home or locate to a secondary site with 5 | Internet access, until the physical recovery of the facility impacted is 6 | complete. The recovery shall be performed by the facility management firm under 7 | contract with {{companyShortName}}, and coordinated by the Facility Manager 8 | and/or the Site Lead. 9 | 10 | {{companyShortName}}’s software development organization has the ability to work 11 | from any location with Internet access and does not require an office provided 12 | Internet connection. -------------------------------------------------------------------------------- /templates/procedures/cp-bcdr-test.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Testing and Maintenance 2 | 3 | The COO and/or Head of Engineering shall establish criteria for 4 | validation/testing of a Contingency Plan, an annual test schedule, and ensure 5 | implementation of the test. This process will also serve as training for 6 | personnel involved in the plan's execution. At a minimum the Contingency Plan 7 | shall be tested annually (within 365 days). The types of validation/testing 8 | exercises include tabletop and technical testing. Contingency Plans for all 9 | application systems must be tested at a minimum using the tabletop testing 10 | process. However, if the application system Contingency Plan is included in the 11 | technical testing of their respective support systems that technical test will 12 | satisfy the annual requirement. 13 | 14 | #### Tabletop Testing 15 | 16 | Tabletop Testing is conducted in accordance with 17 | [CMS's RMH Chapter 6 Supplemental Contingency Planning Exercise Procedures](https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH-Chapter-6-Supplemental-Contingency-Planning-Exercise-Procedures.docx). 18 | The primary objective of the tabletop test is to ensure designated personnel are 19 | knowledgeable and capable of performing the notification/activation requirements 20 | and procedures as outlined in the CP, in a timely manner. The exercises include, 21 | but are not limited to: 22 | 23 | * Testing to validate the ability to respond to a crisis in a coordinated, 24 | timely, and effective manner, by simulating the occurrence of a specific 25 | crisis. 26 | 27 | #### Simulation and/or Technical Testing 28 | 29 | The primary objective of the technical test is to ensure the communication 30 | processes and data storage and recovery processes can function at an alternate 31 | site to perform the functions and capabilities of the system within the 32 | designated requirements. Technical testing shall include, but is not limited to: 33 | 34 | * Process from backup system at the alternate site; 35 | * Restore system using backups; and 36 | * Switch compute and storage resources to alternate processing site. 37 | -------------------------------------------------------------------------------- /templates/procedures/cp-breach-authorities.md.tmpl: -------------------------------------------------------------------------------- 1 | ### List of Contacts for Authorities 2 | 3 | {{#needStandardHIPAA}} 4 | #### Health and Human Services 5 | 6 | - Phone: 7 | 1-877-696-6775 8 | - Mailing Address: 9 | Centralized Case Management Operations 10 | U.S. Department of Health and Human Services 11 | 200 Independence Avenue, S.W. 12 | Room 509F HHH Bldg. 13 | Washington, D.C. 20201 14 | - Website: 15 | 16 | {{/needStandardHIPAA}} 17 | 18 | #### Federal Trade Commission 19 | 20 | - Phone: 21 | 1-877-382-4357 22 | - Website: 23 | 24 | 25 | {{#needStandardGDPR}} 26 | #### Privacy Shield 27 | 28 | - Website: 29 | 30 | 31 | #### GDPR Lead Supervisory Authority (UK) - ICO 32 | 33 | - Website: 34 | 35 | - 36 | - 37 | 38 | #### GDPR Lead Supervisory Authority (Ireland) - DPC 39 | 40 | - Website: 41 | 42 | {{/needStandardGDPR}} 43 | 44 | #### Indianapolis Metropolitan Police Department 45 | 46 | - Phone: 47 | 317-327-3282 48 | - Address: 49 | 50 N. Alabama St. 50 | Indianapolis, IN 46204 51 | 52 | #### Federal Bureau of Investigation Indianapolis Office 53 | 54 | - Phone: 55 | 317-595-4000 56 | - Address: 57 | 8825 Nelson B Klein Pkwy 58 | Indianapolis, IN 46250 59 | -------------------------------------------------------------------------------- /templates/procedures/cp-breach-customer.md.tmpl: -------------------------------------------------------------------------------- 1 | ### {{companyShortName}} Platform Customer Responsibilities 2 | 3 | The following requirements and guidelines shall be provided to and agreed upon 4 | by a client organization using {{companyShortName}} platform to host sensitive 5 | data such as {{#needStandardHIPAA}}ePHI and{{/needStandardHIPAA}} PII. 6 | 7 | The agreement may be in the form of a contract or acceptance of terms and 8 | conditions. 9 | 10 | 1. The {{companyShortName}} Customer that accesses, maintains, retains, 11 | modifies, records, stores, destroys, or otherwise holds, uses, or discloses 12 | unsecured sensitive data shall, without unreasonable delay and in no case 13 | later than 72 hours after discovery of a breach, notify {{companyShortName}} 14 | of such breach. The Customer shall provide {{companyShortName}} with the 15 | following information: 16 | 17 | * A description of what happened, including the date of the breach, the date 18 | of the discovery of the breach, and the number of records and Customers 19 | affected, if known. 20 | * A description of the types of unsecured protected health information that 21 | were involved in the breach (such as full name, Social Security number, 22 | date of birth, home address, account number, etc.), if known. 23 | * A description of the action taken with regard to notification of patients 24 | regarding the breach. 25 | * Resolution steps taken to mitigate the breach and prevent future 26 | occurrences. 27 | 28 | 1. Depending on the nature of the breach, an investigation may be conducted by 29 | {{companyShortName}} or the Customer or jointly to determine the cause of breach. 30 | 31 | 1. Notice to Media: Unless {{companyShortName}} is directly at fault for the 32 | cause of breach, {{companyShortName}} Customers are responsible for providing 33 | notice to prominent media outlets at the Customer's discretion. 34 | 35 | 1. Notice to Authorities: Unless {{companyShortName}} is directly at fault for 36 | the cause of breach, {{companyShortName}} Customers are responsible for 37 | providing notice to the appropriate authorities, including the Secretary of 38 | Health and Human Services (HHS) and your Lead Supervisory Authority (LSA) 39 | under GDPR, at the Customer's discretion. 40 | -------------------------------------------------------------------------------- /templates/procedures/cp-breach-letter.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Sample Letter to Customers in Case of Breach 2 | 3 | [Date] 4 | 5 | [Name] 6 | [Name of Customer] 7 | [Address 1] 8 | [Address 2] 9 | [City, State Zip Code] 10 | 11 | Dear [Name of Customer]: 12 | 13 | I am writing to you from {{companyFullName}}, with important information about 14 | a recent breach that affects your account with us. We became aware of this 15 | breach on [Insert Date] which occurred on or about [Insert Date]. The breach 16 | occurred as follows: 17 | 18 | Describe event and include the following information: 19 | 20 | * A brief description of what happened, including the date of the breach and the 21 | date of the discovery of the breach, if known. 22 | * A description of the types of unsecured protected health information that were 23 | involved in the breach (such as whether full name, Social Security number, 24 | date of birth, home address, account number, diagnosis, disability code or 25 | other types of information were involved), if known. 26 | * Any steps the Customer should take to protect themselves from potential harm 27 | resulting from the breach. 28 | * A brief description of what {{companyShortName}} is doing to investigate the 29 | breach, to mitigate harm to individuals, and to protect against further 30 | breaches. 31 | * Contact procedures for individuals to ask questions or learn additional 32 | information, which includes a toll-free telephone number, an e-mail address, 33 | web site, or postal address. 34 | 35 | Other Optional Considerations: 36 | 37 | * Recommendations to assist customer in remedying the breach. 38 | 39 | We will assist you in remedying the situation. 40 | 41 | Sincerely, 42 | 43 | 44 | {{securityOfficerName}} 45 | Security Officer 46 | {{companyFullName}} 47 | {{securityOfficerEmail}} 48 | {{companyPhoneNumber}} -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-aws.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Provisioning AWS Accounts 2 | 3 | #### AWS Account Structure / Organization 4 | 5 | {{companyShortName}} maintains a single Organization in AWS, maintained in a 6 | top-level AWS account (master). Sub-accounts are connected that each hosts 7 | separate workloads and resources in its own sandboxed environment. The master 8 | account itself handles aggregated billing for all connected sub-accounts but 9 | does not host any workload, service or resource, with the exception of DNS 10 | records for {{companyShortName}} root domain, using AWS Route53 service. DNS 11 | records for subdomains are maintained in the corresponding sub-accounts. 12 | 13 | Access to each account is funneled through our designated SSO provider, which 14 | establishes a trust relationship to a set of predefined roles in the master 15 | account. Once authenticated, a user then leverages AWS IAM Assume Role 16 | capability to switch to a sub-account to access services and resources. 17 | 18 | The account and network structure looks like the following: 19 | 20 | ``` 21 | SSO/IdP ── {{companyShortName}}-master 22 | │ └── billing and root DNS records only 23 | │ 24 | ├── {{companyShortName}}-dev 25 | │   └── VPC 26 | │ └── Subnets 27 | │ └── Security-Groups 28 | │ └── EC2 instances 29 | │ └── Docker containers 30 | │ 31 | ├── {{companyShortName}}-test 32 | │   └── VPC 33 | │ └── Subnets 34 | │ └── Security-Groups 35 | │ └── EC2 instances 36 | │ └── Docker containers 37 | │ 38 | ├── {{companyShortName}}-infra 39 | │   └── VPC 40 | │ └── Subnets 41 | │ └── Security-Groups 42 | │ └── EC2 instances 43 | │ └── Docker containers 44 | │ 45 | ├── {{companyShortName}}-prod-us1 46 | │   └── VPC 47 | │ └── Subnets 48 | │ └── Security-Groups 49 | │ └── EC2 instances 50 | │ └── Docker containers 51 | │ 52 | ├── {{companyShortName}}-prod-us2 53 | │ 54 | ... 55 | ``` 56 | 57 | #### Infrastructure-as-Code 58 | 59 | {{companyShortName}} AWS environments and infrastructure are managed as code. 60 | Provisioning is accomplished using a set of automation scripts and {{provider}} 61 | code. Each new environment is created as a sub-account connected to 62 | `{{companyShortName}}-master`. The creation and provisioning of a new account 63 | follows the instructions documented in the Bootstrap a new AWS environment page 64 | of the development wiki. 65 | -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-config.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Configuration Management Processes 2 | 3 | 1. Configuration management is automated using industry-recognized tools like 4 | Chef, Salt and Terraform to enforce secure configuration standards. 5 | 6 | 2. All changes to production systems, network devices, and firewalls are 7 | reviewed and approved by Security team before they are implemented to assure 8 | they comply with business and security requirements. 9 | 10 | 3. All changes to production systems are tested before they are implemented in 11 | production. 12 | 13 | 4. Implementation of approved changes are only performed by authorized 14 | personnel. 15 | 16 | 5. Tooling is used to generate an up to date system inventory. 17 | 18 | * All systems are categorized and labeled by their corresponding 19 | environment, such as *dev*, *test*, and *prod*. 20 | * All systems are classified and labeled based on the data they store or 21 | process, according to {{companyShortName}} data classification 22 | model. 23 | * The Security team maintains automation which monitors all changes to IT 24 | assets, generates inventory lists, using automatic IT assets discovery, 25 | and services provided by each cloud provider. 26 | * IT assets database is used to generate the diagrams and asset lists 27 | required by the Risk Assessment phase of {{companyShortName}}'s 28 | [Risk Management procedures](risk-mgmt.md) 29 | * {{companyShortName}} Change Management process ensures that all asset inventory 30 | created by automation is reconciled against real changes to production 31 | systems. This process includes periodic manual audits and approvals. 32 | * During each change implementation, the change is reviewed and verified by 33 | the target asset owner as needed. 34 | 35 | 6. {{companyShortName}} uses the [Security Technical Implementation Guides 36 | (STIGs)](http://iase.disa.mil/stigs/) published by the Defense Information 37 | Systems Agency as a baseline for hardening systems. 38 | 39 | * Windows-based systems use a baseline Active Directory group policy 40 | configuration in conjunction with the DISA STIGs. 41 | * Linux-based systems use Red Hat Enterprise Linux STIG as a guideline for 42 | implementation. 43 | * EC2 instances in AWS are provisioned using only hardened and approved 44 | Amazon Machine Images (AMIs). 45 | * Docker containers are launched using only approved Docker images that have 46 | been through security testing. 47 | 48 | 7. All IT assets in {{companyShortName}} have time synchronized to a single 49 | authoritative source. 50 | 51 | * On-premise systems are configured to point to an internal NTP server. 52 | * The internal NTP server and all AWS instances are pointing to the same set 53 | of ntp.org servers. 54 | 55 | 6. All frontend functionality (e.g. user dashboards and portals) is separated 56 | from backend (e.g. database and app servers) systems by being deployed on 57 | separate servers or containers. 58 | 59 | 7. All software and systems are required to complete full-scale testing before 60 | being promoted to production. 61 | 62 | 8. All code changes are reviewed to assure software code quality, while in 63 | development, to proactively detect potential security issues using 64 | pull-requests and static code analysis tools. More details can be found in 65 | the *Software Release / Code Promotion* section. 66 | -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-emergency.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Emergency Change 2 | 3 | In the event of an emergency, the person or team on call is notified. This may 4 | include a combination or Development, IT, and Security. 5 | 6 | If an emergency change must be made, such as patching of a zero-day security 7 | vulnerability or recovering from a system downtime, and that the standard change 8 | management process cannot be followed due to time constraint or personnel 9 | availability or other unforeseen issues, the change can be made by: 10 | 11 | * **Notification:** The Engineering Lead, Security Lead, and/or IT Lead must be 12 | notified by email, Slack, or phone call prior to the change . Depending on the 13 | nature of the emergency, the leads may choose to inform members of the 14 | executive team. 15 | 16 | * **Access and Execution:** Manually access of the production system or manual 17 | deploy of software, using one of the following access mechanisms as defined in 18 | [Access Control policy and procedures](access.md): 19 | 20 | 1. Support/Troubleshooting access 21 | 2. Root account or root user access 22 | 3. Local system access (for on-premise environment) 23 | 24 | * **Post-emergency Documentation:** A PRODCM ticket should be created within 24 25 | hours following the emergency change. The ticket should contains all details 26 | related to the change, including: 27 | 28 | * Reason for emergency change 29 | * Method of emergency access used 30 | * Steps and details of the change that was made 31 | * Sign-off/approvals must be obtained per the type of change as defined by 32 | the standard CM process 33 | 34 | * **Prevention and Improvement:** The change must be fully reviewed by Security 35 | and Engineering together with the person/team responsible for the change. Any 36 | process improvement and/or preventative measures should be documented and an 37 | implementation plan should be developed. -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-monitor.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Configuration Monitoring and Auditing 2 | 3 | All infrastructure and system configurations, including all software-defined 4 | sources, are centrally aggregated to a configuration management database (CMDB) 5 | -- {{provider}}. 6 | 7 | Configuration auditing rules are created according to established baseline, 8 | approved configuration standards and control policies. Deviations, 9 | misconfigurations, or configuration drifts are detected by these rules and 10 | alerted to the security team. 11 | -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-network.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Configuration and Management of Network Controls 2 | 3 | All network devices and controls on a sensitive network are configured such 4 | that: 5 | 6 | * Vendor provided default configurations are modified securely, including 7 | 8 | - default encryption keys, 9 | - default SNMP community strings, if applicable, 10 | - default passwords/passphrases, and 11 | - other security-related vendor defaults, if applicable. 12 | 13 | * Encryption keys and passwords are changed anytime anyone with knowledge of the 14 | keys or passwords leaves the company or changes positions. 15 | 16 | * Traffic filtering (e.g. firewall rules) and inspection (e.g. Network IDS/IPS 17 | or AWS VPC flow logs) are enabled. 18 | 19 | * An up-to-date network diagram is maintained. 20 | 21 | In AWS, network controls are implemented using Virtual Private Clouds (VPCs) and 22 | Security Groups. The configurations are managed as code and stored in approved 23 | repos. All changes to the configuration follow the defined code review, change 24 | management and production deployment approval process. 25 | -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-patch.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Patch Management Procedures 2 | 3 | **Local Systems** 4 | 5 | {{companyShortName}} uses automated tooling to ensure systems are up-to-date 6 | with the latest security patches. 7 | 8 | * On local Linux and Windows systems, the unattended-upgrades tool is used to 9 | apply security patches in phases. 10 | 11 | - High Risk security patches are automatically applied as they are released 12 | - Monthly system patching for regular applications are applied as needed. 13 | - Snapshotting of a system will take place before an update is applied. 14 | - Once the update is deemed stable the snapshot will be removed. 15 | - In case of failure of the update the snapshot will be rolled back. 16 | - If the staging systems function properly after the two-week testing 17 | period, the security team will promote that snapshot into the mirror used 18 | by all production systems. These patches will be applied to all production 19 | systems during the next nightly patch run. 20 | - The patching process may be expedited by the Security team 21 | - On Windows systems, the baseline Group Policy setting configures Windows 22 | Update to implement the patching policy. 23 | 24 | **Cloud Resources** 25 | 26 | {{companyShortName}} follows a "cattle-vs-pets" methodology to keep the 27 | resources in the cloud environments immutable and up-to-date with security 28 | patches. 29 | 30 | * AWS Elastic Container Service (ECS) is used to dynamically manage container 31 | resources based on demand. 32 | 33 | * Engineering team builds security-approved AMI from the latest AWS optimized 34 | Amazon Machine Image (AMI) to include required security agent. 35 | 36 | * The security agents installed on the security-approved AMIs continuously scan 37 | for and report new vulnerabilities. 38 | 39 | * The custom AMIs are automatically rebuilt from the latest AWS AMIs weekly to 40 | include the latest security patches. 41 | 42 | **User Endpoints** 43 | 44 | {{companyShortName}} requires auto-update for security patches to be enabled for 45 | all user endpoints, including laptops and workstations. 46 | 47 | * The auto-update configuration and update status on all end-user systems are 48 | inspected by Security through either manual periodic audits or automated 49 | compliance auditing agents installed on the endpoints. -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-prodcm.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Production Deploy / Code Promotion Processes 2 | 3 | In order to promote changes into Production, a valid and approved Change Request 4 | (CR) is required. It can be created in the [Change Management System/Portal][1] 5 | which implements the {{companyShortName}} Change Management workflow, using the 6 | Production Change Management (PRODCM) {{ticketingSystem}} project to manage 7 | changes and approvals. 8 | 9 | [1]: {{&cmPortal}} 10 | 11 | * At least two approvals are required for each PRODCM ticket. By default, the 12 | approvers are 13 | 14 | - Security Lead and 15 | - Engineering Lead. 16 | 17 | * Additional approver(s) may be added depending on the impacted component(s). 18 | For example, 19 | 20 | - the IT Manager is added as an approver for IT/network changes; and 21 | - the DevOps Lead is added as an approver for changes to `aws-{{companyShortName}}-infra` 22 | account in AWS. 23 | 24 | * Each PRODCM ticket requires the following information at a minimum: 25 | 26 | - Summary of the change 27 | - Component(s) impacted 28 | - Justification 29 | - Rollback plan 30 | 31 | * Additional details are required for a code deploy, including: 32 | 33 | - Build job name 34 | - Build ID and/or number 35 | - Deploy action (e.g. plan, apply) 36 | - Deploy branch (e.g. master) 37 | - Target environment (e.g. `aws-{{companyShortName}}-infra`, `aws-{{companyShortName}}-prod-us`, `datacenter-hq`) 38 | - Links to pull requests and/or {{ticketingSystem}} issues 39 | - Security scan status and results -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-provision-endpoint.md.tmpl: -------------------------------------------------------------------------------- 1 | ### User Endpoint Security Controls and Configuration 2 | 3 | 1. Employee laptops, including Windows, Mac, and Linux systems, are configured 4 | either 5 | 6 | * Manually by IT or the device owner; or 7 | * Automatically using a configuration management tool or equivalent scripts. 8 | 9 | 2. The following security controls are applied at the minimum: 10 | 11 | * Disk encryption 12 | * Unique user accounts and strong passwords 13 | * Approved NTP servers 14 | * Approved security agents 15 | * Locking after 2 mins of inactivity 16 | * Auto-update of security patches 17 | 18 | 3. The security configurations on all end-user systems are inspected by Security 19 | through either a manual periodic review or an automated compliance auditing 20 | tool. 21 | -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-provision-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Configuration and Provisioning of Management Systems 2 | 3 | 1. Provisioning management systems such as configuration management servers, 4 | remote access infrastructure, directory services, or monitoring systems follows 5 | the same procedure as provisioning a production system. 6 | 7 | 2. Critical infrastructure roles applied to new systems must be clearly 8 | documented by the implementer in the change request. 9 | -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-provision-prod.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Production Systems Provisioning 2 | 3 | 1. Before provisioning any systems, a request must be created and approved in 4 | the {{ticketingSystem}} Production Change Management (PRODCM) project. 5 | 6 | * {{ticketingSystem}} access requires authenticated users. 7 | * Security grants access to the {{ticketingSystem}} PRODCM project following the procedures 8 | covered in the [Access Establishment and Modification 9 | section](access.md). 10 | 11 | 2. The security team must approve the provisioning request before any new system 12 | can be provisioned, unless a pre-approved automation process is followed. 13 | 14 | 3. Once provisioning has been approved, the implementer must configure the new 15 | system according to the standard baseline chosen for the system's role. 16 | 17 | 4. If the system will be used to store sensitive information, the implementer 18 | must ensure the volume containing this sensitive data is encrypted. 19 | 20 | 5. Sensitive data in motion must always be encrypted. 21 | 22 | 6. A security analysis is conducted once the system has been provisioned. This 23 | can be achieved either via automated configuration/vulnerability scans or 24 | manual inspection by the security team. Verifications include, but is not 25 | limited to: 26 | 27 | * Removal of default users used during provisioning. 28 | * Network configuration for system. 29 | * Data volume encryption settings. 30 | * Intrusion detection and virus scanning software installed. 31 | 32 | 7. The new system is fully promoted into production upon successful verification 33 | against corresponding {{companyShortName}} standards and change request approvals. -------------------------------------------------------------------------------- /templates/procedures/cp-ccm-provision-server.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Server Hardening Guidelines and Processes 2 | 3 | 1. **Linux System Hardening:** Linux systems have their baseline security 4 | configuration applied via automation tools. These tools cover: 5 | 6 | * Ensuring that the machine is up-to-date with security patches and is 7 | configured to apply patches in accordance with our policies. 8 | * Stopping and disabling any unnecessary OS services. 9 | * Apply applicable DISA STIGs to OS and applications. 10 | * Configuring 15-minute session inactivity timeouts for SSH sessions. 11 | * Installing and configuring the virus scanner. 12 | * Installing and configuring the NTP daemon, including ensuring that 13 | modifying system time cannot be performed by unprivileged users. 14 | * Configuring disk volumes for providers that do not have native support for 15 | encrypted data volumes, including ensuring that encryption keys are 16 | protected from unauthorized access. 17 | * Configuring authentication to the centralized Directory Services servers. 18 | * Configuring audit logging as described in the [Auditing Policy 19 | section](system-audit.md). 20 | 21 | 1. **Windows System Hardening:** Windows systems have their baseline security 22 | configuration applied via the combination of Group Policy settings and/or 23 | automation scripts. These baseline settings cover: 24 | 25 | * Joining the Windows Domain Controller and applying the Active Directory 26 | Group Policy configuration (for AD-managed systems only). 27 | * Ensuring that the machine is up-to-date with security patches and is 28 | configured to apply patches in accordance with our policies. 29 | * Apply applicable DISA STIGs to OS and applications. 30 | * Stopping and disabling any unnecessary OS services. 31 | * Configuring session inactivity timeouts. 32 | * Installing and configuring security protection agents such as anti-virus 33 | scanner. 34 | * Configuring transport encryption according to the requirements described 35 | in the [Mobile Device Security and Disposable Media Management 36 | section](mdm.md). 37 | * Configuring the system clock to point to approved NTP servers and ensuring 38 | that modifying system time cannot be performed by unprivileged users. 39 | * Configuring audit logging as described in the [Auditing Policy 40 | section](system-audit.md). 41 | 42 | 1. Any additional configuration changes applied to hardened Windows systems must 43 | be clearly documented by the implementer and reviewed by the Security team. -------------------------------------------------------------------------------- /templates/procedures/cp-compliance-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Compliance Program Management 2 | 3 | {{companyShortName}} management and security/compliance team has identified and 4 | regularly reviews all relevant statutory, regulatory, and contractual 5 | requirements. 6 | 7 | {{companyShortName}}'s compliance policy includes requirements to meet any and 8 | all applicable compliance requirements. 9 | 10 | Additionally, the Vendor Risk Management policies and procedures specify the 11 | details related to contractual agreements with clients, partners and vendors, 12 | as well as requirements and process related to intellectual property rights and 13 | the use of proprietary software products. -------------------------------------------------------------------------------- /templates/procedures/cp-compliance-monitor.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Continuous Compliance Monitoring 2 | 3 | The status of compliance is tracked via {{provider}}. Compliance dashboards are 4 | configured with applicable internal and external standards and frameworks. Any 5 | potential gaps detected are reported on the compliance dashboards. 6 | -------------------------------------------------------------------------------- /templates/procedures/cp-data-backup.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Backup and Recovery 2 | 3 | #### Customer Data 4 | 5 | {{companyShortName}} stores data in a secure production account in AWS, using a 6 | combination of S3, DynamoDB, and Aurora SQL databases. By default, Amazon S3 7 | provides durable infrastructure to store important data and is designed for 8 | durability of 99.999999999% of objects. 9 | 10 | {{#needStandardHIPAA}} 11 | All data store services and platforms in use are HIPAA compliant. 12 | {{/needStandardHIPAA}} 13 | 14 | {{companyShortName}} performs automatic backup of all customer and system data to protect 15 | against catastrophic loss due to unforeseen events that impact the entire 16 | system. An automated process will back up all data to a separate AWS region in 17 | the same country (e.g. US East to US West). By default, data will be backed up 18 | daily. The backups are encrypted in the same way as live production data. 19 | 20 | Customers can also utilize the {{companyShortName}} Application Programming Interface (API) 21 | to extract and store their data elsewhere. Standard API usage fees will apply. 22 | 23 | #### Source code 24 | 25 | {{companyShortName}} stores its source in git repositories hosted by {{sourceControl}}. 26 | 27 | Source code repositories are backed up to {{companyShortName}}’s AWS S3 infrastructure 28 | account on a weekly basis with a common set of configuration for each repository 29 | to enforce SDLC processes. 30 | 31 | In the event that {{sourceControl}} suffers a catastrophic loss of data, source code 32 | will be restored from the backups in AWS S3. 33 | 34 | Because AWS and {{sourceControl}} can both host git repositories, we are able to 35 | leverage git's ability to maintain a full history of all changes to our git 36 | repos via the commit log. 37 | 38 | #### Business records and documents 39 | 40 | Each data owner/creator is responsible for maintaining a backup copy of their 41 | business files local on their laptop/workstation to the appropriate location on 42 | {{companyShortName}} SharePoint team site. Examples of business files include, but are not 43 | limited to: 44 | 45 | * Documents (e.g. product specs, business plans) 46 | * Presentations 47 | * Reports and spreadsheets 48 | * Design files/images/diagrams 49 | * Meeting notes/recordings 50 | * Important records (e.g. approval notes) 51 | 52 | Unless the local workstation/device has access to **Critical** data, backups of 53 | user workstations/devices are self managed by the device owner. Backups may be 54 | stored on an external hard drive or using a cloud service such as iCloud if and 55 | only if the data is both encrypted and password protected (passwords must meet 56 | {{companyShortName}} requirements). 57 | -------------------------------------------------------------------------------- /templates/procedures/cp-data-classification.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Data Classification Model 2 | 3 | {{companyShortName}} defines the following four classifications of data: 4 | 5 | * **Critical** 6 | * **Confidential** 7 | * **Internal** 8 | * **Public** 9 | 10 | #### Definitions and Examples 11 | 12 | **Critical** data includes data that must be protected due to regulatory requirements, privacy, 13 | and/or security sensitivities. 14 | 15 | Unauthorized disclosure of critical data may result in major disruption to 16 | business operations, significant cost, irreparable reputation damage, and/or 17 | legal prosecution to the company. 18 | 19 | External disclosure of critical data is strictly prohibited without an approved 20 | process and agreement in place. 21 | 22 | *Example Critical Data Types* includes 23 | 24 | * PII 25 | {{#needStandardHIPAA}} 26 | * PHI or ePHI 27 | {{/needStandardHIPAA}} 28 | {{#needStandardPCI}} 29 | * PCI or CHD (cardholder data) 30 | {{/needStandardPCI}} 31 | * Production Security data, such as 32 | - Production secrets, passwords, access keys, certificates, etc. 33 | - Production security audit logs, events, and incident data 34 | 35 | **Confidential** and proprietary data represents company secrets and is of 36 | significant value to the company. 37 | 38 | Unauthorized disclosure may result in disruption to business operations and loss 39 | in value. 40 | 41 | Disclosure requires the signing of NDA and management approval. 42 | 43 | *Example Confidential Data Types* includes 44 | 45 | * Business plans 46 | * Employee/HR data 47 | * News and public announcements (pre-announcement) 48 | * Patents (pre-filing) 49 | * Specialized source codes 50 | * Non-production Security data, including 51 | - Non-prod secrets, passwords, access keys, certificates, etc. 52 | - Non-prod security audit logs, events, reports, and incident data 53 | - Audit/compliance reports, security architecture docs, etc. 54 | 55 | **Internal** data contains information used for internal operations. 56 | 57 | Unauthorized disclosure may cause undesirable outcome to business operations. 58 | 59 | Disclosure requires management approval. NDA is usually required but may be 60 | waived on a case-by-case basis. 61 | 62 | *Example Internal Data Types* includes 63 | 64 | * Internal documentation 65 | * Policies and procedures 66 | * Product roadmaps 67 | * Most source codes 68 | 69 | **Public** data is Information intended for public consumption. Although 70 | non-confidential, the integrity and availability of public data should be 71 | protected. 72 | 73 | *Example Internal Data Types* includes 74 | 75 | * News and public announcements (post-announcement) 76 | * Marketing materials 77 | * Product documentation 78 | * Contents posted on company website(s) and social media channel(s) 79 | -------------------------------------------------------------------------------- /templates/procedures/cp-data-deletion.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Data Deletion Procedures 2 | 3 | #### For Platform Customers 4 | 5 | {{#needStandardHIPAA}} 6 | Despite not being a requirement within HIPAA, {{companyShortName}} understands and 7 | appreciates the importance of health data retention. Acting as a 8 | subcontractor/service provider, and at times a business associate, {{companyShortName}} is 9 | not directly responsible for health and medical records retention as set forth 10 | by each state. 11 | {{/needStandardHIPAA}} 12 | 13 | {{companyShortName}} has created and implemented the following procedures to 14 | make it easier for {{companyShortName}} Customers to support data retention 15 | laws. 16 | 17 | Some types of customer data may be automatically transitioned to a storage class 18 | that is appropriate for archival or infrequent usage. The guidelines for 19 | transitioning data to different storage classes is at the discretion of 20 | {{companyShortName}}. 21 | 22 | Customer data is retained for as long as the account is in active status. Data 23 | enters an expired state when the account is voluntarily closed. Expired account 24 | data will be retained for 14 days. After 14 days, the project/account and 25 | related data will be removed. Customers that wish to voluntarily close their 26 | account should download their data manually or via the API prior to closing 27 | their account. 28 | 29 | If an account is involuntarily suspended, then there is a 14 day grace period 30 | during which the account will be inaccessible but can be re-opened if the customer 31 | meets their payment obligations and resolves any terms of service violations. If 32 | a customer wishes to manually backup their data in a suspended account, then 33 | they must ensure that their account is brought back to good standing so that the 34 | API and user interface will be available for their use. After 14 days, the 35 | suspended account will be closed and the data will be permanently removed 36 | (except when required by law to retain). 37 | 38 | #### For patient data as as a Covered Entity 39 | 40 | {{companyShortName}} is NOT a covered entity. Should we become a covered entity in the 41 | future, we would be required by law to retain healthcare records for up to 10 42 | years beyond when service was last provided when providing healthcare services 43 | directly to patients. Any patient data that is marked for deletion will be 44 | archived for the time required by law. This archived data can be retrieved by 45 | the customer as long as it is retrieved within 10 years from date of last 46 | service. -------------------------------------------------------------------------------- /templates/procedures/cp-data-handling.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Data Handling Requirements Matrix 2 | 3 | Requirements for data handling, such as the need for encryption and the duration 4 | of retention, are defined according to the {{companyShortName}} Data 5 | Classifications. 6 | 7 | | Data | Labeling or Tagging | Segregated Storage | Endpoint Storage | Encrypt At Rest | Encrypt In Transit | Encrypt In Use | Controlled Access | Monitoring | Destruction at Disposal | Retention Period | Backup Recovery | 8 | |------------------|---------------------|--------------------|------------------|-----------------|--------------------|----------------|-------------------|------------|------------------------|------------------|-----------------| 9 | | **Critical** | Required | Required | Prohibited | Required | Required | Required | Access is blocked to end users by default; Temporary access for privileged users only | Required | Required | 7 years for audit trails; Varies for customer-owned data† | Required | 10 | | **Confidential** | Required | N/R | Allowed | Required | Required | Required | All access is based on need-to-know | Required | Required | 7 years for official documentation; Others vary based on business need | Required | 11 | | **Internal** | Required | N/R | Allowed | N/R | N/R | N/R | All employees and contractors (read); Data owners and authorized individuals (write) | N/R | N/R | 7 years for official documentation; Others vary based on business need | Optional | 12 | | **Public** | N/R | N/R | Allowed | N/R | N/R | N/R | Everyone (read); Data owners and authorized individuals (write) | N/R | N/R | Varies based on business need | Optional | 13 | 14 | N/R = Not Required 15 | 16 | † customer-owned data is stored for as long as they remain as a 17 | {{companyShortName}} customer, or as required by regulations, whichever is 18 | longer. Customer may request their data to be deleted at any time; unless 19 | retention is required by law. -------------------------------------------------------------------------------- /templates/procedures/cp-data-lifecycle.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Data Inventory and Lifecycle Management 2 | 3 | {{companyShortName}} Security team uses an automated system to query across our cloud-based 4 | infrastructure, including but is not limited to AWS, to obtain detailed records 5 | of all data repositories, including but not limited to: 6 | 7 | * AWS S3 repositories 8 | * AWS RDS and DynamoDB instances 9 | * AWS EC2 volumes 10 | * Source code repositories 11 | * Office 365 12 | * On-premise storage systems (manually maintained) 13 | 14 | The records are stored in a database system maintained by {{companyShortName}} security 15 | team. Records are tagged with owner/project and classification when applicable. 16 | All records are kept up to date via automation. The system is also designed to 17 | track movement of data and update/alert accordingly. 18 | 19 | **AWS S3 Object Lifecycle Management** 20 | 21 | The {{companyShortName}} platform will automatically adjust the storage class for certain 22 | types of data based on its usage pattern and age. This allows the {{companyShortName}} 23 | platform to provide competitive pricing while still allowing the customer to 24 | store large amounts of data. 25 | 26 | AWS provides the following [storage 27 | classes](): 28 | 29 | * General Purpose 30 | * Infrequent Access 31 | * Archive (Amazon Glacier) 32 | 33 | S3 lifecycle policies are used to manage the storage class for certain types of 34 | data. In most cases, the {{companyShortName}} platform automatically adjusts the storage 35 | class but we may give customers the ability to adjust the storage class manually 36 | to meet their pricing or performance needs. 37 | 38 | {{companyShortName}} performs regular full backups of all production data. We leverage S3 39 | lifecycle policies to automatically remove old backup data. This allows older 40 | data to "age out" instead of having to explicitly delete it. S3 lifecycle 41 | policies are also used to adjust the storage class of data backups based on the 42 | age of the backup. 43 | 44 | **Other Business Data** 45 | 46 | All internal and confidential business records and documents, such as product 47 | plans, business strategies, presentations and reports, are stored outside of an 48 | employee workstation or laptop. 49 | 50 | * Official records are stored in record management systems such as 51 | - {{ticketingSystem}} (tickets), 52 | - {{sourceControl}} (source code), 53 | - {{hrSystem}} (HR), 54 | - {{expenseReporting}} (expense reports), etc. 55 | 56 | * Unstructured business documents such as Word documents, Excel spreadsheets 57 | and PowerPoint presentations are stored on {{companyShortName}} internal 58 | file share. 59 | 60 | * Confidential business documents/records are be stored in encrypted form and 61 | with access control enabled on a need-to-know basis. 62 | 63 | **Transient Data Managemet** 64 | 65 | Data may be temporarily stored by a system for processing. For example, a 66 | storage device may be used to stage temp/raw files prior to being uploaded 67 | to the production environment in AWS. These transient data repositories are not 68 | intended for long term storage, and data is purged immediately after use. 69 | 70 | *{{companyShortName}} currently does NOT use transient storage for any sensitive data.* 71 | -------------------------------------------------------------------------------- /templates/procedures/cp-data-protection-at-rest.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Protecting Data At Rest 2 | 3 | #### Encryption of Data at Rest 4 | 5 | All databases, data stores, and file systems are encrypted with AES-256 using 6 | separate keys for each storage type. The keys are rotated periodically. 7 | 8 | #### Local Disk/Volume Encryption 9 | 10 | Encryption and key management for local disk encryption of on-premise servers 11 | and end-user devices follow the defined best practices for Windows, macOS, and 12 | Linux/Unix operating systems, such as Bitlocker and FileVault. -------------------------------------------------------------------------------- /templates/procedures/cp-data-protection-cert.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Certificate Management 2 | 3 | {{companyShortName}} uses AWS Certificate Manager (ACM) and LetsEncrypt for 4 | certificate management. 5 | 6 | - Certificates are renewed automatically. 7 | 8 | - Security team monitors the certificates for expiration, potential compromise 9 | and use/validity. Certificate revocation process is invoked if the certificate 10 | is no longer needed or upon discovery of potential compromise. -------------------------------------------------------------------------------- /templates/procedures/cp-data-protection-in-transit.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Protecting Data In Transit 2 | 3 | 1. All external data transmission is encrypted end-to-end using encryption keys 4 | managed by {{companyShortName}}. This includes, but is not limited to, cloud 5 | infrastructure and third party vendors and applications. 6 | 7 | 2. Transmission encryption keys and systems that generate keys are protected 8 | from unauthorized access. Transmission encryption key materials are protected 9 | with access controls, and may only be accessed by privileged accounts. 10 | 11 | 3. Transmission encryption keys use a minimum of 4096-bit RSA keys, or keys and 12 | ciphers of equivalent or higher cryptographic strength (e.g., 256-bit AES 13 | session keys in the case of IPSec encryption). 14 | 15 | 4. Transmission encryption keys are limited to use for one year and then must be 16 | regenerated. 17 | 18 | 5. For all {{companyShortName}} APIs, enforcement of authentication, authorization, and 19 | auditing is used for all remote systems sending, receiving, or storing data. 20 | 21 | 6. System logs of all transmissions of Production Data access are kept. These logs must 22 | be available for audit. 23 | 24 | #### Encryption of Data in Transit 25 | 26 | All internet and intranet connections are encrypted and authenticated using TLS 27 | 1.2 (a strong protocol), ECDHE_RSA with P-256 (a strong key exchange), and 28 | AES_128_GCM (a strong cipher). 29 | 30 | #### Data protection via end-user messaging channels 31 | 32 | Restricted and sensitive data is not allowed to be sent over electronic end-user 33 | messaging channels such as email or chat, unless end-to-end encryption is 34 | enabled. 35 | -------------------------------------------------------------------------------- /templates/procedures/cp-data-protection-in-use.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Protecting Data In Use 2 | 3 | Data in Use, sometimes known as Data in Process, refers to active data being 4 | processed by systems and applications which is typically stored in a 5 | non-persistent digital state such as in computer random-access memory (RAM), CPU 6 | caches, or CPU registers. 7 | 8 | Protection of data in use relies on application layer controls and system access 9 | controls. See the [Production Security / SDLC][1] and [Access][2] sections for 10 | details. 11 | 12 | [1]: sdlc.md 13 | [2]: access.md 14 | 15 | {{companyShortName}} applications implement logical account-level data 16 | segregation to protect data in a multi-tenancy deployment. In addition, 17 | {{companyShortName}} applications may incorporate advanced security features 18 | such as Runtime Application Self Protection (RASP) modules and Attribute Based 19 | Access Control (ABAC) for protection of data in use. -------------------------------------------------------------------------------- /templates/procedures/cp-data-protection-integrity.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Data Integrity Protection 2 | 3 | When appropriate, {{companyShortName}} engineering should implement "Versioning" 4 | and "Lifecycle", or equivalent data management mechanism, such that direct edit 5 | and delete actions are not allowed on the data to prevent accidental or 6 | malicious overwrite. This protects against human errors and cyberattacks such as 7 | ransomware. 8 | 9 | In AWS, the IAM and S3 bucket policy in production will be implemented 10 | accordingly when the environments are configured. When changes must be made, a 11 | new version is created instead of editing and overwriting existing data. 12 | 13 | * All edits create a new version and old versions are preserved for a period of 14 | time defined in the lifecycle policy. 15 | 16 | * Data objects are "marked for deletion" when deleted so that they are 17 | recoverable if needed within a period of time defined according to the data 18 | retention policy. 19 | 20 | * Data is archived offsite -- i.e. to separate AWS account and/or region. 21 | 22 | Additionally, all access to sensitive data is authenticated, and audited via 23 | logging of the infrastructure, systems and/or application. 24 | -------------------------------------------------------------------------------- /templates/procedures/cp-data-protection-kms.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Encryption Key Management 2 | 3 | {{companyShortName}} uses AWS Key Management Service (KMS) for encryption key management. 4 | 5 | - KMS keys are unique to {{companyShortName}} environments and services. 6 | 7 | - KMS keys are automatically rotated yearly. -------------------------------------------------------------------------------- /templates/procedures/cp-employee-acceptable-use.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Acceptable Use of End-user Computing 2 | 3 | {{companyShortName}} requires all workforce members to comply with the following 4 | acceptable use requirements and procedures, such that: 5 | 6 | (a) Per {{companyShortName}} [security architecture](model.md), all workforce 7 | members are primarily considered as remote users and therefore must follow all 8 | system access controls and procedures for remote access. 9 | 10 | (b) Use of {{companyShortName}} computing systems is subject to monitoring by 11 | {{companyShortName}} IT and/or Security team. 12 | 13 | (c) Employees may not leave computing devices (including laptops and smart 14 | devices) used for business purpose, including company-provided and BYOD devices, 15 | unattended in public. 16 | 17 | (d) Device encryption must be enabled for all mobile devices accessing company 18 | data, such as whole-disk encryption for all laptops. 19 | 20 | (e) Use only legal, [approved software](approved-software.md) with a valid 21 | license installed through a [pre-approved application store](approved-software.md). 22 | Do not use personal software for business purposes and vice versa. 23 | 24 | (f) Encrypt all email messages containing sensitive or confidential data. 25 | 26 | (g) Employees may not post any sensitive or confidential data in public forums 27 | or chat rooms. If a posting is needed to obtain technical support, data must be 28 | sanitized to remove any sensitive or confidential information prior to posting. 29 | 30 | (h) Anti-malware or equivalent protection and monitoring must be installed and 31 | enabled on all endpoint systems that may be affected by malware, including 32 | workstations, laptops and servers. 33 | 34 | (i) All data storage devices and media must be managed according to the {{companyShortName}} 35 | Data Classification specifications and Data Handling procedures. 36 | 37 | (j) It is strictly forbidden to download or store any sensitive data on end-user 38 | computing devices, including laptops, workstations and mobile devices. 39 | 40 | (k) Mobile devices are not allowed to connect directly to {{companyShortName}} production 41 | environments. 42 | -------------------------------------------------------------------------------- /templates/procedures/cp-employee-development.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Continuous Education and Skills Development 2 | 3 | {{companyShortName}} provides employees the opportunity to attend conferences, 4 | trade shows, and/or ongoing training/studies relevant to their job function 5 | and business objectives. 6 | -------------------------------------------------------------------------------- /templates/procedures/cp-employee-escalation.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Employee Issue Escalation 2 | 3 | {{companyShortName}} workforce members are to escalate issues using the 4 | procedures outlined in the Employee Quick Reference. Issues that are brought to 5 | the Escalation Team are assigned an owner. The membership of the Escalation Team 6 | is maintained by the Chief Executive Officer or his delegate. 7 | 8 | Security incidents, particularly those involving sensitive data, are handled 9 | using the process described in [Incident Response](ir.md). If the incident 10 | involves a breach of sensitive data, the Security Officer will manage the 11 | incident using the process described in [Breach Notification](breach.md). Refer 12 | to [Incident Response](ir.md) for a list of sample items that can trigger 13 | {{companyShortName}}'s incident response procedures; if you are unsure whether 14 | the issue is a security incident, contact the Security team immediately. 15 | 16 | It is the duty of the incident owner to follow the process outlined below: 17 | 18 | 1. Create an Issue in the {{ticketingSystem}} Security Project. 19 | 2. The Issue is investigated, documented, and, when a conclusion or remediation 20 | is reached, it is moved to Review. 21 | 3. The Issue is reviewed by another member of the Escalation Team. If the Issue 22 | is rejected, it goes back for further evaluation and review. 23 | 4. If the Issue is approved, it is marked as Done, adding any pertinent notes 24 | required. 25 | 5. The workforce member that initiated the process is notified of the outcome 26 | via email. 27 | -------------------------------------------------------------------------------- /templates/procedures/cp-employee-exiting.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Employee Exiting/Termination Procedures 2 | 3 | A master checklist for employee existing/termination is maintained by 4 | HR/Facilities. It is published in the HR system or the HR folder on 5 | [{{companyShortName}}'s internal file sharing site](#). 6 | 7 | 1. The Human Resources Department (or other designated department), users, and 8 | their supervisors (HR) are required to notify Security upon completion and/or 9 | termination of access needs and facilitating completion of the "Termination 10 | Checklist". 11 | 2. HR are required to notify Security to terminate a user's access rights if 12 | there is evidence or reason to believe the following (these incidents are 13 | also reported on an incident report and is filed with the Privacy Officer): 14 | 15 | * The user has been using their access rights inappropriately; 16 | * A user's password has been compromised (a new password may be provided to 17 | the user if the user is not identified as the individual compromising the 18 | original password); 19 | * An unauthorized individual is utilizing a user's User Login ID and 20 | password (a new password may be provided to the user if the user is not 21 | identified as providing the unauthorized individual with the User Login ID 22 | and password). 23 | 24 | 3. Security will terminate users' access rights immediately upon notification, 25 | and will coordinate with the appropriate {{companyShortName}} employees to terminate 26 | access to any non-production systems managed by those employees. 27 | 4. Security audits and may terminate access of users that have not logged into 28 | organization's information systems/applications for an extended period of 29 | time. -------------------------------------------------------------------------------- /templates/procedures/cp-employee-onboarding.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Employee Onboarding Procedures 2 | 3 | A master checklist for employee onboarding is maintained by HR/Facilities. 4 | It is published in the HR system or the HR folder on 5 | [{{companyShortName}}'s internal file sharing site](#). 6 | 7 | The HR Representative / Facility Manager is responsible to create an Issue in 8 | the {{ticketingSystem}} HR & Facilities project to initiate and track the 9 | onboarding process. The onboarding process should include the following 10 | IT/Security items: 11 | 12 | 1. Training. 13 | 14 | * New workforce member is provided training on {{companyShortName}} security policy, 15 | acceptable use policy, and given access to the Employee 16 | Handbook. 17 | {{#needStandardHIPAA}} 18 | * HIPAA awareness training is provided to new workforce member. 19 | {{/needStandardHIPAA}} 20 | * Records of training and policy acceptance is kept in the HR system 21 | (currently EaseCentral). 22 | * The training and acceptance must be completed within 30 days of 23 | employment. 24 | 25 | 2. Access. 26 | 27 | * Standard access is provisioned according to the job role and approval as 28 | specified in the HR onboarding {{ticketingSystem}} ticket. 29 | * Non-standard access requires additional approval following the access 30 | request procedures. 31 | * Request for modifications of access for any {{companyShortName}} employee 32 | can be made using the procedures outlined in the 33 | [Access Establishment and Modification policy and procedures](access.md). 34 | 35 | 3. System configuration. 36 | 37 | * The end-user computing device (e.g. workstation or laptop) may be 38 | provisioned by IT to install necessary software, malware protection, 39 | security agents, and setting system configurations. 40 | * Users in a technical role, such as Development, may choose to self 41 | configure their system. In this case, the user is given configuration 42 | guidelines defined by IT and Security. The system must have the required 43 | security configuration and endpoint agents installed for monitoring and to 44 | ensure compliance. -------------------------------------------------------------------------------- /templates/procedures/cp-employee-performance.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Employee Performance Review Process 2 | 3 | Formal performance reviews are conducted annually using {{provider}}. 4 | 5 | - 360 feedback is collected from team members working directly with the employee 6 | - Employee provides their own self assessment for both performance outcome and 7 | behavior 8 | - Manager reviews employee self-assessment and peer feedback, and documents 9 | the final review and rating 10 | - The final review and rating is reviewed and signed by both the employee and 11 | their manager 12 | -------------------------------------------------------------------------------- /templates/procedures/cp-employee-recognition.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Employee Incentives and Rewards 2 | 3 | {{companyShortName}} encourages employees to go above and beyond to contribute 4 | to the business objectives and help their peers and customers. Employees are 5 | recognized and rewarded for positive behavior on a regular basis via peer 6 | recognition, appreciation, feedback, and rewards using {{provider}}. 7 | -------------------------------------------------------------------------------- /templates/procedures/cp-employee-screening.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Employee Screening Procedures 2 | 3 | {{companyShortName}} publishes job descriptions for available positions and 4 | conducts interviews to assess a candidates technical skills as well as culture 5 | fit prior to hiring. 6 | 7 | Background checks of an employee or contractor is performed by HR/operations 8 | and/or the hiring team prior to the start date of employment. 9 | -------------------------------------------------------------------------------- /templates/procedures/cp-employee-whistleblower.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Whistleblower Policy and Process 2 | 3 | The {{companyShortName}} requires all workforce members to observe high 4 | standards of business and personal ethics in the conduct of their duties and 5 | responsibilities. All workforce members must practice honesty and integrity in 6 | fulfilling their responsibilities and comply with all applicable laws and 7 | regulations. 8 | 9 | (a) Reporting Responsibility. Each workforce member is required and encouraged 10 | to report serious concerns so that {{companyShortName}} can address and correct 11 | inappropriate internal conduct and actions. This includes 12 | 13 | * questionable or improper accounting or auditing matters, 14 | * violations and suspected violations of company policies or ethics, or 15 | * suspected violations of law or regulations that govern 16 | {{companyShortName}}’s operations 17 | 18 | (b) Acting in Good Faith. Anyone filing a written complaint concerning a 19 | violation or suspected violation must be acting in good faith and have 20 | reasonable grounds for believing the information disclosed indicates a 21 | violation. Any allegations that prove not to be substantiated and which prove to 22 | have been made maliciously or knowingly to be false will be viewed as a serious 23 | disciplinary offense. 24 | 25 | (c) Confidentiality. Insofar as possible, the confidentiality of the 26 | whistleblower will be maintained. However, identity may have to be disclosed to 27 | conduct a thorough investigation, to comply with the law, and to provide accused 28 | individuals their legal rights of defense. 29 | 30 | (d) No Retaliation. Workforce members, in good faith, reporting a concern under 31 | the Whistleblower Policy shall NOT be subject to retaliation or adverse 32 | employment consequences. Moreover, any workforce member who retaliates against 33 | someone who has reported a concern in good faith is subject to disciplinary 34 | actions up to and including termination of employment. 35 | 36 | (e) Reporting. Reports of concerns may be filed directly with the company CEO, 37 | COO, and/or the Compliance Officer. Additional reporting procedure details can 38 | be found in the employee handbook. 39 | -------------------------------------------------------------------------------- /templates/procedures/cp-events-analysis.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Security Events Analysis 2 | 3 | Security logs, events, and audit trails are reviewed by the security team with 4 | the assistance of automated systems and processes. 5 | 6 | * Auditing logs are automatically analyzed and correlated by the monitoring 7 | solutions and/or a centralized security information and event management 8 | system. 9 | * The systems are configured with rules/policies to identify suspicious 10 | activities, vulnerabilities and misconfigurations. 11 | * Alerts are triggered upon identification of an issue based on the policy 12 | configuration. 13 | * The alerts are sent immediately to the responsible staff (e.g. security team) 14 | for analysis. The alerts may be sent via email, Slack messaging, or as 15 | notification on the monitoring dashboard. 16 | * Analysis is prioritized based on alert severity. High severity alerts are 17 | typically reviewed within 24 hours. 18 | * Incident response process is followed, as needed. 19 | * Patches and updates will be applied to all systems in a timely manner. 20 | -------------------------------------------------------------------------------- /templates/procedures/cp-gov-bod.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Board of Directors Responsibilities 2 | 3 | The Board of Directors (BoD) meets quarterly to discuss financials, operations, 4 | business results, strategies and planning. The BoD responsibilities include: 5 | 6 | * Evaluate the performance of the Chief Executive Officer (CEO) and the 7 | executive management team 8 | 9 | * Establish policies, evaluate and approve the compensation of senior 10 | management of the company 11 | 12 | * Review succession plans and development programs for senior management 13 | 14 | * Review and approve long-term strategic and business plans and monitor 15 | organization's performance against the plans 16 | 17 | * Review and approve any major risks and the risk remediation/acceptance 18 | 19 | * Adopt policies of corporate conduct, including compliance with applicable 20 | laws, rules and regulations, maintenance of accounting, financial and other 21 | controls, and reviewing the adequacy of compliance systems and controls 22 | 23 | * Evaluate the overall effectiveness of the Board and its committees and the 24 | individual directors on a periodic basis 25 | 26 | * Adopt and implement best practices of corporate governance in full conformity 27 | with the letter and spirit of all applicable laws, rules and regulations 28 | -------------------------------------------------------------------------------- /templates/procedures/cp-hr-mgmt.md.tmpl: -------------------------------------------------------------------------------- 1 | ## HR Management and Reporting 2 | 3 | {{companyShortName}} uses {{hrSystem}} to manage its workforce personnel records. 4 | 5 | ### Organization Structure 6 | 7 | A reporting structure has been established that aligns with the organization's 8 | business lines and/or individual's functional roles. The organizational chart is 9 | available to all employees via the {{hrSystem}} and/or posted on the internal 10 | web portal. 11 | 12 | ### Job Functions and Descriptions 13 | 14 | Position / Job descriptions are documented and updated as needed that define the 15 | skills, responsibilities, and knowledge levels required for certain jobs. 16 | 17 | ### Performance Reviews and Feedback 18 | 19 | Employees receive regular feedback and acknowledgement from their manager and 20 | peers. Formal performance reviews are conducted annually using {{provider}}. 21 | Performance measures, incentives, and other rewards are established by 22 | management according to responsibilities at all levels, reflecting appropriate 23 | dimensions of performance and expected standards of conduct. 24 | -------------------------------------------------------------------------------- /templates/procedures/cp-internal-comms.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Internal Business Communications 2 | 3 | #### Company-wide updates 4 | 5 | {{companyShortName}} holds a company-wide roundtable at least quarterly to 6 | communicate updates across all aspects of business operations, performance and 7 | objectives. 8 | 9 | Senior management sends out additional company-wide announcements as appropriate 10 | through pre-established internal communication channels such as email or 11 | messaging (e.g. Slack #general channel). 12 | 13 | #### Departmental, team and/or project status updates 14 | 15 | Regular performance and status updates are communicated by each department, 16 | functional team, and/or designated individuals through pre-established channels. 17 | 18 | Additionally, each project team maintains team updates at their own committed 19 | cadence and channel -- for example, daily development standups/scrum or weekly 20 | team meetings. 21 | -------------------------------------------------------------------------------- /templates/procedures/cp-ir-emergency.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Emergency Operations Mode 2 | 3 | If an incident constitutes an emergency – for example, a detected cyberattack 4 | that impacts production systems – {{companyShortName}} plans to operate in a “read-only” 5 | mode, to continue to provide customers access to their data. All write access is 6 | temporarily blocked and data upload is paused until the emergency is resolved. 7 | This is accomplished by updating the access policy in production AWS 8 | environments. 9 | 10 | In emergency operations mode, temporary access may be granted to security and/or 11 | engineering team to access the production environments to perform forensics, 12 | root cause analysis, eradication/remediation, or other necessary activities for 13 | incident recovery. -------------------------------------------------------------------------------- /templates/procedures/cp-ir-records.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Incident Tracking and Records 2 | 3 | A record is created for each reported incident in {{provider}}. Each incident 4 | record contains details about the incident capturing the incident attributes 5 | and progression, including the following as applicable: 6 | 7 | - Summary 8 | - Description 9 | - Impact 10 | - Priority / Urgency 11 | - Categorization 12 | - Analysis Notes and Comments 13 | - Cause / Determination 14 | - Outcome / Resolution 15 | - Lessons Learned 16 | 17 | If a more detailed post-mortem is applicable, the Security and/or DevOps team 18 | will create the write-up and link it in the incident record. 19 | -------------------------------------------------------------------------------- /templates/procedures/cp-ir-sirt.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Security Incident Response Team (SIRT) 2 | 3 | The Security Incident Response Team (SIRT) is responsible for: 4 | 5 | * Review, analyze and log of all received reports and track their statuses. 6 | * Performing investigations, creating and executing action plans, post-incident 7 | activities. 8 | * Collaboration with law enforcement agencies. 9 | 10 | Current members of the {{companyShortName}} SIRT: 11 | 12 | * Security and Privacy Officer 13 | * Security Engineers 14 | * Head of Engineering 15 | * DevOps and Production Support Team -------------------------------------------------------------------------------- /templates/procedures/cp-ir-tabletop.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Tabletop Exercise 2 | 3 | At least once per year, {{companyShortName}} security and engineering teams 4 | jointly performs a Red Team exercise and/or a simulated "drill" of an emergency 5 | cyberattack that results in one or more **CRITICAL** incidents. Depending on the 6 | type of exercise, the duration may range from 2-4 hours (simulated "drill") to a 7 | couple of weeks (full Red Teaming exercise). 8 | 9 | The exercise will follow a cyberattack playbook. It may be conducted with all 10 | internal resources or with the help of an external security consulting firm. The 11 | goal of the exercise is to ensure all parties involved receive proper training 12 | to handle an actual incident and to test out the documented procedures in order 13 | to identify gaps ahead of a real event. Senior leadership team may be invited to 14 | participate in the "drill" depending on the nature of the exercise or receive a 15 | readout of the outcome. -------------------------------------------------------------------------------- /templates/procedures/cp-ism-policies.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Understanding the Policies and Documents 2 | 3 | Policies are written in individual documents, each pertaining to a specific 4 | domain of concern. 5 | 6 | Each document starts with the current version number and/or last updated date, 7 | followed by a brief summary. The remaining of the document is structured to 8 | contain two main sections: 9 | 10 | * Policy Statements 11 | * Controls and Procedures 12 | 13 | All policy documents are maintained, reviewed, updated and approved following 14 | standards and procedures outlined in [Policy Management](policy-mgmt.md). 15 | 16 | -------------------------------------------------------------------------------- /templates/procedures/cp-ism-reporting.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Review and Reporting 2 | 3 | The information security program, policies, procedures and controls are reviewed 4 | on a regular basis internally by cross functional team members and externally by 5 | qualified assessors. 6 | 7 | {{#haveSecurityScorecard}} 8 | A security scorecard is produced every {{securityScorecardPeriod}} with updates 9 | to key metrics of the {{companyShortName}} information security program, to 10 | measure its adoption and effectiveness. 11 | 12 | The latest scorecard can be accessed here: [Security 13 | Scorecard]({{&securityScorecardURL}}). 14 | {{/haveSecurityScorecard}} 15 | -------------------------------------------------------------------------------- /templates/procedures/cp-ism-scope.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Information Security Program and Scope 2 | 3 | {{companyShortName}} has developed a security program and implemented controls 4 | to meet and exceed all compliance requirements, including but not limited to 5 | {{#needStandardHIPAA}}HIPAA,{{/needStandardHIPAA}} 6 | {{#needStandardPCI}}PCI,{{/needStandardPCI}} 7 | {{#needStandardNIST}}NIST,{{/needStandardNIST}} 8 | SOC 2 Common Criteria and other applicable industry best practices. 9 | 10 | On a high level, {{companyShortName}}’s information security program covers: 11 | 12 | 1. Inventory and protection of all critical assets 13 | 2. Visibility into and the management of data lifecycle, from creation to 14 | retention to deletion 15 | 3. Protection of data-at-rest, data-in-transit, and data-in-use 16 | 4. Segmented network architecture 17 | 5. Automated security configuration and remediation 18 | 6. Centralized identity and access management 19 | 7. Secure product development 20 | 8. Continuous monitoring and auditing 21 | 9. Validated plan and practice for business continuity, disaster recovery, and 22 | emergency response 23 | 10. End-user computing protection and awareness training 24 | 25 | More information about the {{companyShortName}} Security and Privacy program can 26 | be found at [{{securityPolicyURL}}]({{&securityPolicyURL}}) and 27 | [{{privacyPolicyURL}}]({{&privacyPolicyURL}}). 28 | 29 | The information security program and its policies and procedures cover all 30 | {{companyShortName}} workforce members, including full-time and part-time 31 | employees in all job roles, temporary staff, contractors and subcontractors, 32 | volunteers, interns, managers, executives employees, and third parties. 33 | 34 | The information security program is managed by dedicated security and compliance 35 | personnel, using {{provider}} as a GRC platform. 36 | -------------------------------------------------------------------------------- /templates/procedures/cp-mdm-byod.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Support and Management of BYOD Devices 2 | 3 | {{companyShortName}} provides company-issued laptops and workstations to all employees. 4 | 5 | {{#supportBYODandMDM}} 6 | 7 | Mobile devices (including personal smart devices) may be used for business 8 | purpoose under the following conditions and management: 9 | 10 | - All employee mobile devices accessing or containing company data are 11 | inventoried and managed by IT using **{{provider}}**. The inventory will 12 | maintain current information on the owner of the device, its approved usages, 13 | installed applications, system status (operating system version and patches), 14 | and its state (e.g. in-use, lost, decommissioned). 15 | 16 | - Mobile device management software is deployed to ensure the proper protection 17 | and configuration of mobile devices, including: 18 | 19 | - Encryption must be enabled for device storage 20 | - Device password must be enabled and meet security policy requirements 21 | - Device must be locked after 2 minutes of inactivity 22 | - Operating systems and patches are up to date 23 | 24 | - All applications downloaded on employee mobile devices used for business 25 | purposes must be installed through a pre-approved app store or 26 | [application list](approved-software.md). 27 | 28 | - Circumvention of built-in device security controls such as jailbreaking is 29 | strictly prohibited and enforced by detective or preventative software. 30 | 31 | - Anti-malware software is installed and active on mobile devices. Alternatively, 32 | a sandbox environment is created on BYOD devices using the **{{provider}}** 33 | MDM solution to allow only white-listed application and data in a contained 34 | workspace. 35 | 36 | - Any confidential or sensitive data is only allowed to be accessed via and 37 | stored inside the sandbox environment on mobile devices. 38 | 39 | - Employees acknowledge that their mobile devices may be remotely controlled, 40 | locked or erased via the MDM software. 41 | 42 | - Eligibility and usage of BYOD devices is subject to manager and/or IT/Security 43 | approval. 44 | 45 | {{/supportBYODandMDM}} 46 | 47 | {{^supportBYODandMDM}} 48 | 49 | {{companyShortName}} currently does not require or support employees bringing their own 50 | computing devices. 51 | 52 | The end-user computing devices are self managed. Each {{companyShortName}} employee is 53 | responsible to 54 | 55 | * configure their laptop/workstation to meeting the [configuration and 56 | management requirements](ccm.md); and 57 | 58 | * ensure the latest security patches are installed or auto-update is enabled. 59 | 60 | IT and Security provides automated scripts for end-user system configurations 61 | and/or technical assistance as needed. Such configurations are audited daily 62 | using **{{provider}}** centrally managed by the Security team. 63 | 64 | {{/supportBYODandMDM}} -------------------------------------------------------------------------------- /templates/procedures/cp-mdm-disposal.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Media Disposal Process 2 | 3 | IT and Security is responsible to ensure media containing critical / sensitive 4 | data is disposed securely in the following manner: 5 | 6 | * The methods of destruction, disposal, and reuse are reassessed periodically, 7 | based on current technology, accepted practices, and availability of timely 8 | and cost-effective destruction, disposal, and reuse technologies and services. 9 | This may include 10 | 11 | - Secure wipe; 12 | - Physical destruction; 13 | - Destruction of encryption keys (if the data on the media is encrypted 14 | using a strong algorithm such as AES-256). 15 | 16 | * If the records have been requested in the course of a judicial or 17 | administrative hearing, a qualified protective order will be obtained to 18 | ensure that the records are returned to the organization or properly 19 | destroyed/disposed of by the requesting party. 20 | 21 | * All {{companyShortName}} Subcontractors provide that, upon termination of the contract, 22 | they will return or destroy/dispose of all patient health information. In 23 | cases where the return or destruction/disposal is not feasible, the contract 24 | limits the use and disclosure of the information to the purposes that prevent 25 | its return or destruction/disposal. 26 | 27 | * In the cases of a {{companyShortName}} Customer terminating a contract with 28 | {{companyShortName}} and no longer utilize {{companyShortName}} Services, 29 | data will be returned or disposed per contract agreement or 30 | {{companyShortName}} Platform use terms and conditions. In all cases it is 31 | solely the responsibility of the {{companyShortName}} Customer to maintain 32 | the safeguards required of laws and regulations once the data is transmitted 33 | out of {{companyShortName}} environments. 34 | -------------------------------------------------------------------------------- /templates/procedures/cp-mdm-usb.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Use of USB Flash Drive and External Storage Device 2 | 3 | Per {{companyShortName}} corporate policy, confidential and critical data may 4 | not be stored on external devices such as USB flash drives. 5 | {{#needStandardHIPAA}} 6 | This includes and is not limited to ePHI. 7 | {{/needStandardHIPAA}} 8 | For definition of confidential and critical data, see 9 | {{companyShortName}} Data Classification and Handling Policy. 10 | 11 | Usage of USB flash drives for temporary transfer of confidential and critical 12 | data may be allowed on a case by case basis, when the following process is 13 | followed: 14 | 15 | * Data is only allowed on encrypted flash devices approved by {{companyShortName}} 16 | Security and the IT Manager (currently **{{provider}}**). 17 | * The process starts with the submission of a ticket in {{ticketingSystem}}. 18 | The ticket must be approved by IT and Security. 19 | * Upon completion of data transfer all sensitive data on the device must be 20 | completely removed. 21 | * The device is to be returned to the IT Manager to double check that the data 22 | has been removed. 23 | * The IT Manager will check the drive back in. 24 | -------------------------------------------------------------------------------- /templates/procedures/cp-model-architecture.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Security Architecture 2 | 3 | {{companyShortName}} developed a security architecture on top of its three main 4 | infrastructure environments - Cloud (AWS), DevOps, and workforce collaboration / 5 | end-user computing. 6 | 7 | #### Architecture Diagrams 8 | 9 | Detailed architecture diagrams of the in-scope networks, endpoints, applications 10 | as well as the security operations are developed and maintained by {{provider}}. 11 | 12 | #### Cloud Architecture 13 | 14 | ##### Cloud Native 15 | 16 | * Designed for the cloud using true multi-tenant architecture 17 | * Auto scaling across multiple data centers in multiple regions around the world 18 | * {{companyShortName}} services deployed inside private subnets of Virtual Private Cloud (VPC) 19 | * Comprehensive security and compliance via AWS certifications 20 | * Ongoing security testing by AWS and AWS customers 21 | 22 | ##### Customer Benefits 23 | 24 | * Infrastructure is tailored to our customer's goals and usage patterns 25 | * "Shared use" model reduces cost 26 | * Nearly infinite compute and data capacity via AWS cloud provider 27 | * Customers can focus on solving business problems and not worry about infrastructure 28 | * Automatic backup and recovery 29 | * Continuous improvements via change control process 30 | * Faster adoption of new technology 31 | 32 | ##### Evolution of Cloud Computing 33 | 34 | 1. Baremetal 35 | 36 | - A computer in someone else's data center 37 | 38 | 1. Virtual Machine 39 | 40 | - A portion of a computer in someone else's data center 41 | - In AWS, a Virtual Machine is created from Amazon Machine Image (AMI) 42 | 43 | 1. Container 44 | 45 | - A package of essential application libraries and code but not 46 | the core OS libraries - Simpler to scale a docker image because - No 47 | duplication of core OS processes (networking, filesystem, etc) - Typically 48 | a Docker container 49 | 50 | 1. Function 51 | 52 | - Just the application code that runs in a pre-built container 53 | 54 | {{companyShortName}} strives to leverage functions as the primary building 55 | blocks for our platform because: 56 | 57 | * functions deploy more quickly than containers and virtual machines 58 | * AWS automatically scales Lambda functions based on the number of incoming invocations 59 | * they are short-lived processes which minimizes attack surface -------------------------------------------------------------------------------- /templates/procedures/cp-model-metrics.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Metrics, Measurements and Continuous Monitoring 2 | 3 | A set of metrics / KPIs have been defined to assist in the measuring, reporting 4 | and optimizing the security program and the controls in place. 5 | 6 | A security scorecard is produced every {{securityReportingPeriod}} with updates 7 | to key metrics of the {{companyShortName}} information security program, to 8 | measure its adoption and effectiveness. 9 | 10 | The reports and scorecards are maintained by and can be accessed at {{provider}}. 11 | -------------------------------------------------------------------------------- /templates/procedures/cp-model-quality.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Quality of Service 2 | 3 | {{companyShortName}} strives to provide a high quality of service 4 | to all of its customers. This is accomplished through a security 5 | architecture that encompasses all of {{companyShortName}}'s operations 6 | and provides high data confidentiality, integrity, and availability. 7 | 8 | An overview of {{companyShortName}}'s architecture can be found in 9 | [Security Architecture](cp-model-architecture.md). 10 | {{companyShortName}} uses a highly scalable cloud architecture to 11 | provide system quality at all times. 12 | 13 | All systems are monitored and measured in real time as described in 14 | [Application Service Event Recovery](cp-bcdr-app.md). 15 | 16 | {{companyShortName}} uses DevOps methodology as described in 17 | [Software Development Process](cp-sdlc-dev.md) 18 | to ensure a smooth delivery process of all systems and applications. 19 | 20 | Status for external facing, customer applications and systems is published 21 | at {{&statusPageURL}}. 22 | -------------------------------------------------------------------------------- /templates/procedures/cp-physical-cleandesk.md.tmpl: -------------------------------------------------------------------------------- 1 | #### Clean Desk Policy and Procedures 2 | 3 | Employees must secure all sensitive/confidential information in their workspace 4 | at the conclusion of the work day and when away from their workspace. This 5 | includes both electronic and physical information such as: 6 | 7 | * computer workstations, laptops, and tablets 8 | * removable storage devices including CDs, DVDs, USB drives, and external hard drives 9 | * printed materials 10 | 11 | Computer workstations/laptops must be locked (password protected) when 12 | physically unattended. Portable devices such as laptops and tablets should be 13 | taken home at the conclusion of the work day. 14 | 15 | Removable storage devices and printed documents must be treated as sensitive 16 | material and locked in a drawer or similar when not in use. Printed materials 17 | must be immediately removed from printers or fax machines. Passwords must not be 18 | written down or stored physically. 19 | 20 | Keys and access cards used for access to sensitive or restricted 21 | information/areas must not be left unattended anywhere in the office. -------------------------------------------------------------------------------- /templates/procedures/cp-physical-datacenter.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Data Center Security 2 | 3 | Physical security of data centers is ensured by the cloud infrastructure service 4 | provided, {{provider}}. 5 | -------------------------------------------------------------------------------- /templates/procedures/cp-policy-framework.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Policies and Controls Framework 2 | 3 | {{companyShortName}} maintains a set of policies and controls that captures 4 | standards, regulatory, legal, and statutory requirements relevant to the 5 | business needs. The framework and its contents are reviewed at least annually to 6 | ensure changes that could affect the business processes are reflected. 7 | 8 | #### Structure 9 | 10 | Similar to the concept of "micro-services", the policies and control procedures 11 | are written in individual "micro-docs". They are mapped to each other via a 12 | JSON configuration. 13 | 14 | #### Controls Mapping 15 | 16 | A JSON document configures the mapping of each control procedure to one or more 17 | security/compliance frameworks, as applicable. 18 | 19 | Note that the controls mapping is only between a control/procedure document to 20 | the requirement, not at the policy level. This is because we strongly believe 21 | that you must have documented controls and procedures to implement and enforce a 22 | high level written policy. Having a written policy by itself without 23 | implementation or enforcement does not address the risk of any security 24 | or compliance requirement. 25 | 26 | #### Compliance standards 27 | 28 | At least once a year, {{companyShortName}} reviews the regulatory, legal, and 29 | statutory requirements relevant to its business needs and adopts any relevant 30 | standards into its controls framework and governance program. 31 | 32 | The list of applicable standards can be found it the same repository as the 33 | policies and controls documentation and/or in the {{provider}} compliance 34 | management application/platform. 35 | -------------------------------------------------------------------------------- /templates/procedures/cp-privacy-notices.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Privacy Policy 2 | 3 | Current Privacy Policy is published at 4 | <{{&privacyPolicyURL}}> 5 | 6 | ### Notice of Privacy Practice 7 | 8 | Current Notice of Privacy Practice (NPP) is published at 9 | <{{&privacyPolicyURL}}> 10 | 11 | ### Platform Use Terms and Consent 12 | 13 | The Terms of Use and Consent for {{companyShortName}} platform and applications 14 | are hosted online or within the application itself. 15 | -------------------------------------------------------------------------------- /templates/procedures/cp-risk-fraud.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Fraud Risks 2 | 3 | Due to its transparent culture, team size and operating model, including 4 | separation of duties, comprehensive controls, continuous monitoring and auditing, 5 | {{companyShortName}} considers its fraud-related risk to be very low. 6 | 7 | {{companyShortName}} hires {{CPA}} to perform accounting services and 8 | annual financial audits. 9 | 10 | Fraud risk is re-evaluated as part of the organization's annual risk assessment. 11 | The assessment considers the following aspects of fraud: 12 | 13 | - Pressures and/or incentives 14 | - Opportunities 15 | - Rationalities 16 | 17 | Financial-related fraud assessment is led by the COO/CFO. 18 | 19 | IT-related fraud assessment is led by the Compliance Officer or CISO. 20 | 21 | #### Potential Frauds and Likelihood 22 | 23 | Fraud Risk | Likelihood | In Place Controls/Monitors 24 | ---------- | ---------- | -------------------------- 25 | Fraudulent Financial Reporting | Low | Monthly executive team reviews of business plan and revenue; Financial review by external accounting firm 26 | Misappropriation of Assets | Low | Expense reporting and asset tracking in place 27 | Regulatory and Legal Misconduct | Low | Audit and compliance policies and processes, including whistleblower procedures; engage external law firm to review legal conduct 28 | Payroll Fraud | Low | Payroll is reviewed by at least two people internally as well as by external accounting firm 29 | Kickbacks / Conflict of Interest | Low | Team-based vendor review and selection process 30 | Misuse of Cloud Resources | Low | Continuous resource monitoring for all cloud accounts and regions and expense monitoring 31 | Other IT Fraud | Low | IT assets and resources tracking 32 | -------------------------------------------------------------------------------- /templates/procedures/cp-risk-insurance.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Cyber Liability Insurance 2 | 3 | {{companyShortName}} holds cyber liability insurance with sufficient coverage 4 | based on the organization's risk profile. 5 | 6 | Our current cyber policy is covered by {{provider}}. 7 | -------------------------------------------------------------------------------- /templates/procedures/cp-risk-mgmt-objectives.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Risk Management Objectives 2 | 3 | {{companyShortName}} has established formal risk analysis and risk management 4 | processes to 5 | 6 | - identify risks that may impact its business operations or the confidentiality, 7 | integrity and availability of its critical data; and 8 | 9 | - reduce risk to an acceptable level by implementation of mitigation controls. 10 | 11 | Unmitigated risk above the pre-defined acceptable level must be reviewed, 12 | approved and accepted by senior management. 13 | 14 | #### Acceptable Risk Levels 15 | 16 | Risks that are either low impact or low probability, based on the scoring 17 | mechanism defined in [risk assessment process](cp-risk-assess.md), are generally 18 | considered acceptable. 19 | 20 | All other risks must be individually reviewed and managed according to the 21 | [risk management process](cp-risk-mgmt.md). 22 | -------------------------------------------------------------------------------- /templates/procedures/cp-risk-registry.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Risk Registry 2 | 3 | {{companyShortName}} Security team maintains a registry of risks, captured and kept updated 4 | 5 | * in a document on company SharePoint; and/or 6 | * in the security operations tool/database. 7 | 8 | The risk registry includes all risks and threats identified during annual risk 9 | assessment and all interim reviews. -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-appsec-req.md.tmpl: -------------------------------------------------------------------------------- 1 | ### High Level Application Security Requirements 2 | 3 | All {{companyShortName}} software must be developed to include the following general 4 | application security principles and requirements. Web applications must also 5 | protect itself against the [OWASP Top 6 | 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2017_Release_Candidate) 7 | vulnerabilities. 8 | 9 | 1. Protect sensitive customer data such as {{#needStandardHIPAA}}PHI, {{/needStandardHIPAA}} 10 | PII and account passwords. Encrypt data stored (at rest). 11 | 12 | 2. Secure data in transit and customer communications via TLS. 13 | 14 | 3. Provision strong access control (authentication and authorization). Prevent 15 | and report unauthorized access. 16 | 17 | 4. Log all transactions and activities to be able to tell who did what, when, 18 | where, and how. Mask or remove sensitive data in logs. 19 | 20 | 5. Implement client security at application endpoints (e.g. browser, mobile 21 | app). 22 | 23 | 6. Communicate securely across application endpoints and between service 24 | consumers/producers. 25 | 26 | 7. Use secure defaults to ensure security when in all error conditions. 27 | 28 | 8. Check and maintain the security of all third party and open source 29 | libraries/components/dependencies. 30 | 31 | 9. Validate all data inputs; encode data outputs when appropriate. 32 | 33 | 10. Deploy and configure applications securely to production. 34 | 35 | 11. Perform regular vulnerability analysis and apply security patches promptly. 36 | 37 | 12. Secure privileged access to production environments and ensure ongoing 38 | application monitoring. 39 | 40 | All software code must complete a set of security scans/testing prior to being 41 | deployed to production, including open source dependency scanning, static and 42 | dynamic application security testing, as well as periodic penetration testing. 43 | 44 | Pre-production testing is performed with nonproduction data in nonproduction 45 | environments. Health checks are performed regularly or automated in production. 46 | 47 | Software vulnerability identified through any of the above processes shall be 48 | reported and tracked following {{companyShortName}} Vulnerability Management process 49 | as defined in the [Vulnerability Management Policy and Procedures](vuln-mgmt.md). -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-bugbounty.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Responsible Disclore and Bug Bounty Program 2 | 3 | #### Public Vulnerability Disclosure / Bug Bounty Program 4 | 5 | All technology contains bugs, including both functional defects and security 6 | vulnerability. 7 | 8 | {{companyShortName}} uses a third party platform to maintain a public 9 | vulnerability disclosure / bug bounty program. This program takes advantage of 10 | crowd-sourced security researchers to perform penetration testing of 11 | {{companyShortName}}'s platform and its public facing resources. 12 | 13 | The current program provider is {{provider}}. 14 | -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-dast.md.tmpl: -------------------------------------------------------------------------------- 1 | 2 | ### Dynamic Application Security Testing (DAST) 3 | 4 | Dynamic testing is available by request to the Security team and is performed 5 | using {{provider}}. Security team is currently looking into automation of 6 | this type of scanning. 7 | 8 | Additionally, manual baseline dynamic testing is available by request to the 9 | Security team. 10 | 11 | #### Integration of Dynamic testing into automatic tests 12 | Upon availability of automatic UI tests for applications being developed 13 | internally, an extension based on [OWASP 14 | ZAP](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) is used to 15 | transparently work with any UI tests available and automatically 16 | add basic dynamic tests into build pipeline. -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-design.md.tmpl: -------------------------------------------------------------------------------- 1 | 2 | ### Secure Design and Application Threat Modeling 3 | 4 | {{companyShortName}} Security Team in collaboration with development team performs full 5 | Application Threat Modeling and Risk Assessment on per-application basis using a 6 | custom approach that relies on industry standards and best practices. 7 | 8 | Major application updates are captured via an **RFC** process. The RFC 9 | template includes **Security Consideration** as a required section. This 10 | section is used to document abuse cases including: 11 | 12 | - risks identified, 13 | - attack vectors, and 14 | - mitigating controls. 15 | 16 | Each RFC is required to capture sufficient details of the feature/component to 17 | be developed, including use cases, motivation and outcome, and the following 18 | design details as applicable: 19 | 20 | - authentication/authorization mechanisms, 21 | - network communications, 22 | - data encryption, 23 | - cloud services used, 24 | - logging/auditing, 25 | - data flow diagram/description, 26 | - edge cases, drawbacks, and alternatives. 27 | 28 | The RFC must be approved prior to implementation. Security team is included in 29 | RFC reviews via the pull request process. 30 | 31 | #### Platform Design and DevOps Security Details 32 | 33 | Documentation on the {{companyShortName}} [Engineering Wiki]({{&devWikiURL}}) 34 | may include additional security specifications as well as the security design 35 | and implementation details of the {{companyShortName}} Platform and its 36 | supporting operations. 37 | -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-foss.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Free and Open Source Software (FOSS) Security 2 | 3 | {{companyShortName}} security and development team implemented a process to 4 | 5 | - Inventory all software dependencies; 6 | - Scan software dependencies for known security vulnerability; 7 | - Fix any and all high risk findings prior to production; and 8 | - Review and identify licensing issues of the 3rd party software and 9 | libraries. 10 | 11 | The current tool in use is {{provider}}. {{provider}} supports Node.js, Ruby, 12 | and Java. Documentation can be found at the {{provider}} website. 13 | 14 | {{provider}} also enables automatic license analysis for dependencies, and this 15 | functionality is embedded into the `securityScan()` {{ciSystem}} pipeline step. 16 | 17 | {{provider}} can be leveraged in local development environment to scan locally 18 | and/or at every build for dev to include dev dependencies. -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-iaaa.md.tmpl: -------------------------------------------------------------------------------- 1 | 2 | ### Access Control of the Application (Identification, Authentication, Authorization, Accounting) 3 | 4 | {{companyShortName}} external software application that is customer facing with 5 | access to customer specific data, including sensitive information such as PII 6 | {{#needStandardHIPAA}}and ePHI{{/needStandardHIPAA}}, implements strong access 7 | control, covering the Identification, Authentication, Authorization, and 8 | Accounting/Auditing (IAAA) of access and user activity. 9 | 10 | The implementation ensures that 11 | 12 | - the user requesting access is the one claimed (Identification and 13 | Authentication); 14 | 15 | - only users authorized to access specific data 16 | {{#needStandardHIPAA}}(such as ePHI){{/needStandardHIPAA}} are allowed to 17 | (Authorization); and 18 | 19 | - their access activities are logs (Accounting/Auditing) according to the 20 | {{companyShortName}} auditing standards. 21 | 22 | The current implementation leverages {{provider}} for user identity management 23 | and access. 24 | 25 | The backend platform implements granular Attribute-Based 26 | Access Control (ABAC) for granting access to specific services and data based on 27 | the attribute(s) of a principal (i.e. user requesting access -- an attribute 28 | could be the role or group membership or organization the user belongs to) and 29 | the attribute(s) of the requested resource (i.e. data or service -- an attribute 30 | could be the project this data belongs to). 31 | 32 | More implementation details are documented on the internal Engineering wiki. -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-monitor.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Production System Monitoring and Paging 2 | 3 | Software and systems deployed in production are monitored 24/7 for health check 4 | and other major/critical error conditions. The on call team is paged via 5 | {{provider}} in the event an error or failure is detected. 6 | 7 | Notifications via additional channels such as Slack and email are also 8 | configured. 9 | -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-outsourcing.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Outsourced Software Development 2 | 3 | {{companyShortName}} requires all outsourced software development to follow the 4 | same rigor and process as internal engineering. Outsourced developers must 5 | develop in our secure environment, accept and follow our security policies and 6 | procedures, and comply with the same secure coding standards, including: 7 | 8 | * Receive regular OWASP or equivalent secure coding training. 9 | 10 | * Follow the same source control, code review, and security code scanning 11 | procedures as defined. 12 | 13 | * Install endpoint compliance agent that checks to make sure firewall, 14 | encryption, patching, password policy, screensaver password, and other 15 | required protection is properly configured. 16 | 17 | Additionally, the third party firm providing outsourced development services 18 | must demonstrate that they have conducted the appropriate screening during 19 | hiring. -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-pentest.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Penetration Testing 2 | 3 | #### External Penetration Testing 4 | 5 | An external penetration testing is performed at least once a year by a qualified 6 | security researcher / ethical hacker on the security team internally and/or with 7 | an external security consulting firm. 8 | -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-sast.md.tmpl: -------------------------------------------------------------------------------- 1 | 2 | ### Static Application Security Testing (SAST) 3 | 4 | Tools: 5 | 6 | - The {{provider}} Platform - static and dynamic code analysis. Together with 7 | the FOSS security tool, the SAST testing was made available to use via 8 | the automated `security-scan` docker image, as well as integrated into 9 | {{companyShortName}} {{ciSystem}} pipeline library via the `securityScan()` step 10 | 11 | - Manual code security reviews are periodically performed by the Security team 12 | as follows: 13 | 14 | - Periodic review as part of weekly activities 15 | 16 | - Every pull request which includes security team as approvers 17 | 18 | - By request - {{ticketingSystem}} issue created on the Security project/board -------------------------------------------------------------------------------- /templates/procedures/cp-sdlc-scm.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Source Code Management 2 | 3 | {{companyShortName}} development/engineering team uses {{sourceControl}} for 4 | source code management. Access to {{sourceControl}} and its configuration 5 | standards include: 6 | 7 | * All developers must authenticate to gain access to {{sourceControl}} and code 8 | repos hosted on {{sourceControl}} according to standards and procedures 9 | defined in the [Access Policy](access.md): 10 | 11 | - Access control to the {{sourceControl}} web interface must be enabled, via 12 | SSO and/or MFA if applicable 13 | 14 | - SSH public/private key access may be used for command line or `git` access 15 | to the code repos 16 | 17 | * All code repos in {{sourceControl}} follow these configuration standards: 18 | 19 | - All repos must have an owner identified and listed 20 | 21 | - All repos are by default `private` 22 | 23 | * Certain branch restrictions are enabled, including: 24 | 25 | - The `master` branch cannot be rebased 26 | 27 | - Restrict direct commits into `master` 28 | 29 | - Restrict history rewrites of `master` 30 | 31 | - Restrict deletion of `master` 32 | 33 | * Certain pull request (PR) requirements are enforced before merging, including: 34 | 35 | - Must have at least 1 review approval to merge 36 | 37 | - Must have at least 1 successful build to merge 38 | 39 | - all PR tasks must be completed -------------------------------------------------------------------------------- /templates/procedures/cp-threat-firewall.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Firewall Protection 2 | 3 | Firewall protection is implemented at the following layers 4 | 5 | * **Network** - including Network ACL and Security Groups in AWS as well as on- 6 | premise firewalls between the office networks and the Internet. 7 | 8 | * **Host** - local firewalls are enabled on the user endpoints as well as 9 | servers (compute and database instances in AWS are protected by security 10 | groups) 11 | 12 | * **Application** - web application firewall (WAF) and content distribution are 13 | configured at the application layer to protect against common web application 14 | attacks such as cross site scripting, injection and denial-of-service attacks. -------------------------------------------------------------------------------- /templates/procedures/cp-threat-hids.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Host Intrusion Detection 2 | 3 | Host based intrusion detection is supported via one of the following: 4 | 5 | * On Windows and macOS systems: **{{provider}}** agents for malware 6 | detection and behavior-based endpoint threat detection. 7 | 8 | * On Linux servers: **{{provider}}** agents for activity monitoring, 9 | vulnerability scanning, and threat detection. This includes all virtual 10 | instances running in the cloud environment. -------------------------------------------------------------------------------- /templates/procedures/cp-threat-intel.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Threat Intelligence Monitoring 2 | 3 | **NH-ISAC** 4 | 5 | {{companyShortName}} is an active member of the [National Health Information Sharing and 6 | Analysis Center (NH-ISAC)](https://nhisac.org/). 7 | 8 | {{companyShortName}} Security team is subscribed to receive threat alerts from NH-ISAC. 9 | 10 | **Intelligence Feeds** 11 | 12 | Additional intelligence feeds are received automatically through some of the 3rd 13 | party security solutions that have been implemented on the networks and/or 14 | endpoints. The data gathered through these external intel feeds is automatically 15 | used by the security solutions to analyze events and generate alerts. 16 | 17 | **Regulatory Requirements Updates** 18 | 19 | The Security and Privacy Officer actively monitors the regulatory compliance 20 | landscape for updates to regulations such as HIPAA, PCI and GDPR. 21 | -------------------------------------------------------------------------------- /templates/procedures/cp-threat-malware.md.tmpl: -------------------------------------------------------------------------------- 1 | ### System Malware Protection 2 | 3 | 1. All end-user workstations and production systems must have antivirus running. 4 | The default anti-malware solution used is {{provider}}. The anti-malware solution 5 | will include protection against malicious mobile code. 6 | 7 | * Next generation endpoint protection agent may be used as an equivalent solution. 8 | * Hosts are scanned continuously for malicious binaries in critical system 9 | paths. Additionally, if supported, the agent is set to to scan system 10 | every 2 hours and at reboot to assure no malware is present. 11 | * The malware signature database is kept up to date, changes are pushed 12 | continuously. 13 | * Logs of virus scans and alerts are maintained according to the 14 | requirements outlined in [System Auditing](system-audit.md). 15 | 16 | 2. Detected malware is evaluated and removed following the established [incident 17 | response process](ir.md). 18 | 19 | 3. All systems are to only be used for {{companyShortName}} business needs. 20 | -------------------------------------------------------------------------------- /templates/procedures/cp-threat-nids.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Network Intrusion Detection 2 | 3 | #### Intrusion Detection for On-Premise Internal Networks 4 | 5 | * {{companyShortName}} leverages {{provider}} for network security of its on-premise 6 | environments. 7 | * {{provider}} features stateful firewall inspection and intrusion 8 | detection/prevention (IDS/IPS) of applicable incoming and outgoing network 9 | traffic. Attacks and suspicious network activities are blocked automatically. 10 | * {{companyShortName}} IT manager is responsible for configuring the firewall and IDS/IPS 11 | rules and review the configuration as least quarterly. 12 | 13 | #### Intrusion Detection in AWS Cloud Environments 14 | 15 | {{companyShortName}} implemented a real-time threat detection solution by 16 | monitoring AWS Cloudtrail events and/or VPC flow logs. 17 | 18 | * Cloudtrail events are monitored by **{{provider}}** 19 | * VPC flow logs are sent to and analyzed by **{{provider}}**. 20 | 21 | Additional monitoring is provided by our infrastructure service provider AWS. -------------------------------------------------------------------------------- /templates/procedures/cp-threat-siem.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Centralized Security Information and Event Management 2 | 3 | Security events and alerts are aggregated to and correlated by one or both of 4 | the following solutions: 5 | 6 | * {{provider}} 7 | * Internally developed security automation tooling 8 | -------------------------------------------------------------------------------- /templates/procedures/cp-threat-webapp.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Web Application Protection 2 | 3 | {{companyName}} leverages AWS Services to protect web applications against 4 | common attacks such as SQL injection, cross-site scripting, and 5 | denial-of-service (DoS/DDoS) attacks. The services used include AWS Shield, WAF, 6 | Cloudfront, and/or API Gateway. -------------------------------------------------------------------------------- /templates/procedures/cp-training-awareness.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Ongoing Awareness Training 2 | 3 | {{companyShortName}} leverages {{provider}} to deliver innovative, fun and 4 | engaging security awareness contents to all employees monthly. This security 5 | awareness training shall include modules on 6 | 7 | - phishing, 8 | - social engineering, 9 | - proper internet use (social media, email, clicking, etc), 10 | - access control (proper passwords, 2FA, screen locking, etc), 11 | - mobile device security, 12 | - data protection, and 13 | - system security (anti-malware, patches, secure configuration, etc). 14 | 15 | Progress is tracked individually for each employee and reported on 16 | {{provider}}'s cloud-managed learning platform. -------------------------------------------------------------------------------- /templates/procedures/cp-training-hipaa.md.tmpl: -------------------------------------------------------------------------------- 1 | ### HIPAA Awareness Training 2 | 3 | {{companyShortName}} requires all employees to take a HIPAA awareness training 4 | within 30 days of onboarding and annually thereafter. The training record is 5 | captured within the HR record and/or the learning system {{provider}}. -------------------------------------------------------------------------------- /templates/procedures/cp-training-policy.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Policy and Compliance Training 2 | 3 | 1. The Security & Privacy Officer facilitates the training of all workforce 4 | members as follows: 5 | 6 | 1. New workforce members within their first month of employment; 7 | 2. Existing workforce members annually; 8 | 3. Existing workforce members whose functions are affected by a material 9 | change in the policies and procedures, within a month after the material 10 | change becomes effective; 11 | 4. Existing workforce members as needed due to changes in security and risk 12 | posture of {{companyShortName}}. 13 | 14 | 2. Documentation of the training session materials and attendees is retained for 15 | a minimum of seven years. 16 | 17 | 3. The training session focuses on, but is not limited to, the following 18 | subjects defined in {{companyShortName}}'s security policies and procedures: 19 | 20 | 1. SOC 2 Security Principals and Controls; 21 | {{#needStandardNIST}} 22 | 1. NIST Security Rules; 23 | {{/needStandardNIST}} 24 | {{#needStandardHIPAA}} 25 | 1. HIPAA Privacy, Security, and Breach notification rules; 26 | {{/needStandardHIPAA}} 27 | {{#needStandardPCI}} 28 | 1. PCI DSS requirements; 29 | {{/needStandardPCI}} 30 | 1. Risk Management procedures and documentation; 31 | 1. Auditing. {{companyShortName}} may monitor access and activities of all users; 32 | 1. Workstations may only be used to perform assigned job responsibilities; 33 | 1. Users may not download software onto {{companyShortName}}'s workstations 34 | and/or systems without prior approval from the Security Officer; 35 | 1. Users are required to report malicious software to the Security Officer 36 | immediately; 37 | 1. Users are required to report unauthorized attempts, uses of, and theft 38 | of {{companyShortName}}'s systems and/or workstations; 39 | 1. Users are required to report unauthorized access to facilities 40 | 1. Users are required to report noted log-in discrepancies (i.e. 41 | application states users last log-in was on a date user was on 42 | vacation); 43 | 1. Users may not alter sensitive data maintained in a database, unless authorized to 44 | do so by a {{companyShortName}} Customer; 45 | 1. Users are required to understand their role in {{companyShortName}}'s contingency 46 | plan; 47 | 1. Users may not share their user names nor passwords with anyone; 48 | 1. Requirements for users to create and change passwords; 49 | 1. Users must set all applications that contain or transmit sensitive data to 50 | automatically log off after 15 minutes of inactivity; 51 | 1. Supervisors are required to report terminations of workforce members 52 | and other outside users; 53 | 1. Supervisors are required to report a change in a users title, role, 54 | department, and/or location; 55 | 1. Procedures to backup sensitive data; 56 | 1. Procedures to move and record movement of hardware and electronic media 57 | containing sensitive data; 58 | 1. Procedures to dispose of discs, CDs, hard drives, and other media 59 | containing sensitive data; 60 | 1. Procedures to re-use electronic media containing sensitive data; 61 | 1. Secrets management (such as SSH key) and sensitive document encryption 62 | procedures. 63 | -------------------------------------------------------------------------------- /templates/procedures/cp-vendor-contracts.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Vendor Contractual Agreements 2 | 3 | {{#needStandardHIPAA}} 4 | **HIPAA.** If the vendor needs access to PHI/ePHI, the vendor must be HIPAA 5 | compliant and a [Business Associate Agreement (BAA)][BAA] is required. 6 | 7 | [BAA]: hipaa-baa.md 8 | {{/needStandardHIPAA}} 9 | 10 | {{#needStandardGDPR}} 11 | **GDPR.** If the vendor processes data for customers from in the European 12 | Economic Area, United Kingdom or Switzerland (the “Designated Countries”), the 13 | vendor must be GDPR compliance and a [Data Processing Agreement (DPA)][DPA] is 14 | required. 15 | 16 | [DPA]: gdpr-dpa.md 17 | {{/needStandardGDPR}} 18 | 19 | **SLA for Service Providers.** For network and infrastructure service providers 20 | that support production and/or critical operations at {{companyShortName}}, a 21 | Service Level Agreement (SLA) is defined and included in the service contract. 22 | 23 | As appropriate, the executed agreement(s) are linked or attached to the vendor 24 | on the [approved vendors list][1]. 25 | 26 | [1]: approved-vendors.md -------------------------------------------------------------------------------- /templates/procedures/cp-vendor-monitor.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Monitoring Vendor Risks 2 | 3 | Vendor contracts are reviewed either annually or according to the signed 4 | contract duration. 5 | 6 | Based on the risk level and the sensitivity/criticality of data the vendor has 7 | access to, the vendor review may include an updated risk analysis performed by 8 | the security team in addition to legal and business review of contract terms. 9 | 10 | If the vendor is a service provider, the DevOps team monitors the service status 11 | of the provider according to its SLA. This is done by either manually reviewing 12 | the posted service status on the vendor's status pages at least quarterly, or by 13 | setting up alarms for service interruption using automation. 14 | -------------------------------------------------------------------------------- /templates/procedures/cp-vendor-ssa.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Software and Systems Acquisition Process 2 | 3 | {{companyShortName}} Security maintains 4 | a list of [pre-approved business software][1] and 5 | a list of [approved vendors / contractors][2]. 6 | 7 | [1]: approved-software.md 8 | [2]: approved-vendors.md 9 | 10 | If additional commercial software, hardware system, or cloud services is needed, 11 | a request should be submitted through {{companyShortName}} internal service 12 | desk. This will trigger the approval by manager/security and procurement 13 | process. 14 | 15 | As applicable, {{companyShortName}} security team may conduct a risk analysis on 16 | the software or system to ensure it complies with {{companyShortName}} security, 17 | compliance and legal requirements and does not interfere with the security 18 | controls. If a risk is identified, additional controls should be identified and 19 | implemented (or planned) prior to acquisition. An alternative product may be 20 | considered as a result of the risk analysis. 21 | -------------------------------------------------------------------------------- /templates/procedures/cp-vendor-vtr.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Vendor Technology Risk Review 2 | 3 | {{companyShortName}} security policy requires a risk review of vendor 4 | technology, prior to any technology being integrated to {{companyShortName}} 5 | operations and/or infrastructure. Employees are required to engage security team 6 | to conduct such review. The request may be submitted by email directly to the 7 | security team, or by opening a {{ticketingSystem}} ticket through the 8 | {{companyShortName}} internal service desk. 9 | 10 | Security team is responsible to conduct the reviews via interviews and reviews 11 | of documentation, to ensure the vendor complies with regulatory requirements and 12 | follows security best practices to minimize risk to an acceptable level. 13 | 14 | A vendor technology risk (VTR) assessment is conducted using {{provider}}, in 15 | the following steps: 16 | 17 | 1. Reviewer sends questionnaire link(s) to vendor contact. 18 | 1. Vendor completes the questionnaire(s). 19 | 1. Vendor saves/exports answers to the assessment questionnaire(s). 20 | 1. Vendor contact sends the answers file back to reviewer. 21 | 1. Reviewer opens the same questionnaire(s) and loads the answers received from 22 | the vendor to complete the assessment. 23 | 1. Reviewer follows up with vendor contact as needed. 24 | 1. Reviewer facilities discussion with business owner to determine if the risk 25 | is acceptable. Vendor remediation may be required depending on the results. 26 | 27 | A list of [approved vendors / contractors][1] is maintained by the Security and 28 | Operations teams. 29 | 30 | [1]: approved-vendors.md -------------------------------------------------------------------------------- /templates/procedures/cp-vuln-scan.md.tmpl: -------------------------------------------------------------------------------- 1 | ### Vulnerability Scanning and Infrastructure Security Testing 2 | 3 | The scanning and identification of system vulnerabilities is performed by 4 | 5 | 1. Automated security agent installed on all Linux servers. 6 | 7 | * This includes physical and virtual servers hosted on premise as well as 8 | EC2 instances in AWS. 9 | * The agent automatically reports to a centralized management 10 | server/dashboard with details of the server instance and any vulnerability 11 | finding. 12 | * This assessment is performed on an ongoing basis. 13 | 14 | 2. Additionally, periodic security scans of {{companyShortName}} on-premise systems are done 15 | using a combination of open-source and commercial vulnerability testing 16 | tools, including: 17 | 18 | * OpenVAS 19 | * Nmap 20 | * OWASP ZAP 21 | * Burp Suite Pro 22 | 23 | 3. Penetration testing is performed regularly as part of the {{companyShortName}} 24 | vulnerability management policy. 25 | 26 | * External penetration testing is performed continuously through a public 27 | vulnerability disclosure / bug bounty program. 28 | * Additional external penetration testing is performed at least annually by 29 | either a certified penetration tester on {{companyShortName}} security team or an 30 | independent third party. 31 | * White-box internal penetration testing is performed at least quarterly by 32 | the security team. 33 | 34 | 4. {{companyShortName}} developed an internal vulnerability management tool/database used to 35 | track all system entities and associated vulnerabilities. 36 | 37 | 5. Findings from a vulnerability scan or penetration testing are analyzed by the 38 | security team, together with IT and Engineering as needed, and reported 39 | following the process as defined in the next section. A written report may be 40 | generated in addition to creating the findings in {{ticketingSystem}}. 41 | 42 | 6. All security testing reports and findings records are retained for 7 years. 43 | -------------------------------------------------------------------------------- /templates/ref/approved-software.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Approved Software 2 | 3 | `{{defaultRevision}}` 4 | 5 | Software approved for use at {{ companyShortName }} includes, but is not limited to: 6 | 7 | * Adobe suite 8 | * Atlassian suite 9 | * Code editors (Atom, Emacs, Vim, VS Code, etc) 10 | * Dashlane 11 | * Docker 12 | * Node/NPM 13 | * Office 365 14 | * Okta (and any apps/services managed by Okta) 15 | * Postman 16 | * Slack 17 | * Sketch 18 | * Zoom 19 | 20 | Reputable and well documented open source / free software may be used for 21 | development purposes at the discretion of the Engineering team. Cb Defense 22 | agents must be active to monitor the behavior of all application processes. 23 | Additional periodic audit may be conducted to review the usage of open source 24 | tools. Examples of such software include, but are not limited to: 25 | 26 | * Chrome and various browser extensions 27 | * Firefox and various browser extensions 28 | * Homebrew 29 | * GraphQL/GraphiQL 30 | * Keybase 31 | * Skitch 32 | * Spectacle 33 | * etc. 34 | 35 | Software not in the list above may be installed if it is necessary for a 36 | business purpose, legal, with a valid license, and approved on a case-by-case 37 | basis by your manager or the Security Officer. -------------------------------------------------------------------------------- /templates/ref/approved-vendors.md.tmpl: -------------------------------------------------------------------------------- 1 | ## Approved Vendors 2 | 3 | `{{defaultRevision}}` 4 | 5 | For confidentiality reasons, the list of approved vendors is maintained 6 | internally at company Wiki / SharePoint site. -------------------------------------------------------------------------------- /templates/ref/nist-mapping.md.tmpl: -------------------------------------------------------------------------------- 1 | ## NIST Mappings to {{ companyShortName }} Policies and Controls 2 | 3 | `{{defaultRevision}}` 4 | 5 | Below is a list of NIST SP 800-53 Controls Families and the mappings to 6 | {{companyShortName}} policies and controls in place. 7 | 8 | ID | NIST SP 800-53 Control Family | {{ companyShortName }} Policies and Controls 9 | -- | --- | --- 10 | AC | Access Control | [Access][1] 11 | AT | Awareness and Training | [Roles and Responsibilities][2] 12 | AU | Audit and Accountability | [Roles and Responsibilities][2]; [Compliance Audits][3] 13 | CA | Security Assessment and Authorization | [Risk Management][4]; [Access][1] 14 | CM | Configuration Management | [Configuration and Change Management][5] 15 | CP | Contingency Planning | [Business Continuity and Disaster Recovery][6] 16 | IA | Identification and Authentication | [Access][1] 17 | IR | Incident Response | [Incident Response][7]; [Breach Notification][8] 18 | MA | Maintenance | [Configuration and Change Management][5] 19 | PE | Physical and Environmental Protection | [Facility and Physical Security][9] 20 | PL | Planning | [Security Program Overview][10]; [Security Architecture & Operating Model][11] 21 | PS | Personnel Security | [HR & Personnel Security][12] 22 | RA | Risk Assessment | [Risk Management][4] 23 | SA | System and Services Acquisition | [Third Party Security, Vendor Risk Management and Systems/Services Acquisition][13] 24 | SC | System and Communications Protection | [Data Management][14]; [Data Protection][15]; and [Threat Detection & Prevention][16] 25 | SI | System and Information Integrity | [Data Management][14]; [Data Protection][15]; [Product Security & Secure Software Development][17]; [Vulnerability Management][18];and [System Audits, Monitoring & Assessments][19] 26 | PM | Program Management | [Security Program Overview][10]; [Roles and Responsibilities][2]; and [Policy Management][20] 27 | 28 | [1]: access.md 29 | [2]: rar.md 30 | [3]: compliance-audit.md 31 | [4]: risk-mgmt.md 32 | [5]: ccm.md 33 | [6]: bcdr.md 34 | [7]: ir.md 35 | [8]: breach.md 36 | [9]: facility.md 37 | [10]: program.md 38 | [11]: model.md 39 | [12]: hr.md 40 | [13]: vendor.md 41 | [14]: data-mgmt.md 42 | [15]: data-protection.md 43 | [16]: threat.md 44 | [17]: sdlc.md 45 | [18]: vuln-mgmt.md 46 | [19]: system-audit.md 47 | [20]: policy-mgmt.md 48 | -------------------------------------------------------------------------------- /templates/ref/sanction-notice.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JupiterOne/security-policy-templates/0dcc3b23ebf582254962c13df14b570c27c36a37/templates/ref/sanction-notice.pdf -------------------------------------------------------------------------------- /templates/standards/template.csv: -------------------------------------------------------------------------------- 1 | Section,ID,Title,Requirement 2 | Name of first section,1.1,Optional Title,Summary text of my first security requirment 3 | Name of first section,1.2,,A second requirement that has no title 4 | Section 2,2.1,,My awesome new requirement 5 | Section 2,2.2,,Everyone will love this -------------------------------------------------------------------------------- /templates/standards/template.json: -------------------------------------------------------------------------------- 1 | { 2 | "standard": "", 3 | "version": "", 4 | "webLink": "", 5 | "domains": [ 6 | { 7 | "title": "§ ", 8 | "controls": [ 9 | { 10 | "ref": "", 11 | "title": "", 12 | "summary": "" 13 | } 14 | ] 15 | }, 16 | { 17 | "title": "§ ", 18 | "controls": [ 19 | { 20 | "ref": "", 21 | "title": "", 22 | "summary": "" 23 | }, 24 | { 25 | "ref": "", 26 | "title": "", 27 | "summary": "" 28 | } 29 | ] 30 | } 31 | ] 32 | } -------------------------------------------------------------------------------- /util/COMPLIANCE-SEARCH-TOOL-README.md: -------------------------------------------------------------------------------- 1 | ### Compliance Standards Searcher Tool Against Procedure Docs 2 | 3 | This Python script uses nltk and whoosh libraries to condense standards 4 | from a compliance document in our standardized json form into searchable queries 5 | and then index a directory of procedure/policy documents and run the search queries 6 | against them. The 5 most likely documents to fulfill each standard are outputted. 7 | 8 | #### How to Run 9 | 10 | Run setup-compliance-script.py to install dependencies. 11 | 12 | The searcher script has arguments for the name of the compliance document json as well as 13 | the full path to the directory of procedure docs. 14 | 15 | The script should be ran as follows: 16 | `python3 compliance.py -sf example-compliance.json -dir /Users/person/Repos/security-policy-templates/templates/procedures` 17 | 18 | 19 | #### Modifying The Script 20 | 21 | "Stopwords" are removed from the standards to make them more searchable. To add or remove stopwords, 22 | change the union statement on line 29 of compliance.py. 23 | -------------------------------------------------------------------------------- /util/build-summary.js: -------------------------------------------------------------------------------- 1 | 'use strict'; 2 | 3 | const fs = require('fs'); 4 | 5 | const rawConfig = fs.readFileSync('../templates/config.json'); 6 | const config = JSON.parse(rawConfig); 7 | 8 | const proceduresMap = []; 9 | for (const procedure of config.procedures) { 10 | proceduresMap[procedure.id] = procedure; 11 | } 12 | 13 | const referencesMap = []; 14 | for (const reference of config.references) { 15 | referencesMap[reference.id] = reference; 16 | } 17 | 18 | const policyOutputs = []; 19 | for (const policy of config.policies) { 20 | const procedureOutputs = []; 21 | for (const p of policy.procedures) { 22 | if (proceduresMap[p]) { 23 | procedureOutputs.push( 24 | `- **${proceduresMap[p].name}**\n\n` + 25 | ` _${proceduresMap[p].summary}_\n\n` 26 | ); 27 | } else if (referencesMap[p]) { 28 | procedureOutputs.push( 29 | `- **${referencesMap[p].name}**\n\n` 30 | ); 31 | } 32 | } 33 | policyOutputs.push( 34 | `## ${policy.name}\n\n` + 35 | procedureOutputs.join('') 36 | ); 37 | } 38 | 39 | const output = '# Summary and Guidance\n\n' + policyOutputs.join(''); 40 | 41 | fs.writeFileSync('../summary.md', output); 42 | -------------------------------------------------------------------------------- /util/compliance.py: -------------------------------------------------------------------------------- 1 | from json import load 2 | from os import path, rename, mkdir, listdir 3 | from nltk.corpus import stopwords 4 | from nltk.tokenize import word_tokenize 5 | from nltk import download 6 | from whoosh.index import create_in, open_dir 7 | from whoosh.fields import Schema, TEXT 8 | from whoosh.qparser import QueryParser 9 | from whoosh import scoring 10 | import argparse 11 | 12 | parser = argparse.ArgumentParser() 13 | parser.add_argument("-sf", 14 | "--standards_file", 15 | help="the file that contains the standards you wish to search", 16 | type=str, 17 | default="csa-ccm.json") 18 | parser.add_argument("-dir", 19 | "--directory", 20 | help="the full path of your procedures directory", 21 | type=str, 22 | default="/Users/jpdimarz/Scratch/compliance-search-script/procedures") 23 | args = parser.parse_args() 24 | standards_file = args.standards_file 25 | directory = args.directory 26 | download('punkt') 27 | download('stopwords') 28 | stopwords = set(stopwords.words('english')) 29 | stop_words = stopwords.union(['.', ',', '(', ')', 'shall', 'e.g.', 'use', 'i.e.', '/', ':', '•', "'s", 'and/or']) 30 | 31 | def searchStandards(): 32 | procedures = listdir(directory) 33 | searchDict = dict() 34 | 35 | with open(standards_file) as f: #load the file with the standards 36 | ccm = load(f) 37 | sections = ccm['sections'] 38 | 39 | for section in sections: 40 | for standard in section['requirements']: 41 | word_tokens = word_tokenize((standard['title'] + " " + standard['summary']).lower()) 42 | 43 | filtered_sentence = [] 44 | for w in word_tokens: 45 | if w not in stop_words: 46 | filtered_sentence.append(w) 47 | 48 | newSum = "" 49 | for w in filtered_sentence: #create the search query from condensed terms 50 | newSum = newSum + " OR " + w 51 | 52 | searchDict[('Suggestions for ' + standard['title'] + ': ' + standard['ref'])] = newSum 53 | 54 | 55 | schema = Schema(title=TEXT(stored=True), content=TEXT(stored=True)) #schema for indexing file 56 | 57 | if not path.exists("indexdir"): #create directory for indexing 58 | mkdir("indexdir") 59 | ix = create_in("indexdir", schema=schema, indexname="usages") 60 | 61 | writer = ix.writer() 62 | for procedure_file in procedures: #index each file 63 | procedure = path.join(directory, procedure_file) 64 | with open(procedure, mode="r", encoding="utf-8") as f: 65 | text = f.read() 66 | writer.add_document(title=procedure_file, content=text) 67 | writer.commit() 68 | 69 | 70 | searcher = ix.searcher() 71 | with ix.searcher() as searcher: #search the index to get results 72 | for title, searchQuery in searchDict.items(): 73 | query = QueryParser("content", schema=ix.schema).parse(searchQuery) 74 | results = searcher.search(query) 75 | print(title) 76 | for i in range(5): 77 | print(results[i]['title']) 78 | print() 79 | 80 | 81 | 82 | def main(): 83 | searchStandards() 84 | 85 | if __name__ == "__main__": 86 | main() 87 | -------------------------------------------------------------------------------- /util/control-req-mapper.js: -------------------------------------------------------------------------------- 1 | 'use strict'; 2 | 3 | const fs = require('fs'); 4 | 5 | const ctrlreqFile = '.work/controls-reqs.json'; 6 | const mappingFile = '../templates/standards/controls-mapping.json'; 7 | const standardName = 'MyStandard' 8 | 9 | const ctrlreq = JSON.parse(fs.readFileSync(ctrlreqFile)); 10 | 11 | const mapping = JSON.parse(fs.readFileSync(mappingFile)); 12 | 13 | const requirementsByControl = {}; 14 | 15 | for (const domain of ctrlreq.domains || []) { 16 | for (const control of domain.controls || []) { 17 | requirementsByControl[control.ref] = []; 18 | } 19 | } 20 | 21 | for (const section of ctrlreq.sections || []) { 22 | for (const requirement of section.requirements || []) { 23 | if (requirementsByControl[requirement.control]) { 24 | requirementsByControl[requirement.control].push(requirement.ref); 25 | } 26 | } 27 | } 28 | 29 | for (const procedure of mapping.procedures || []) { 30 | for (const implement of procedure.implements || []) { 31 | if (implement.standard === standardName) { 32 | implement.requirements = []; 33 | for (const control of implement.controls || []) { 34 | implement.requirements.push(...requirementsByControl[control]); 35 | } 36 | } 37 | } 38 | } 39 | 40 | fs.writeFileSync(mappingFile, JSON.stringify(mapping, null, 2)); 41 | -------------------------------------------------------------------------------- /util/internal-standard.js: -------------------------------------------------------------------------------- 1 | 'use strict'; 2 | 3 | const fs = require('fs'); 4 | 5 | const inputFile = '../templates/config.json'; 6 | const outputFile = '../templates/standards/security-program.json'; 7 | const mappingFile = '../templates/standards/controls-mapping.json'; 8 | 9 | const input = JSON.parse(fs.readFileSync(inputFile)); 10 | const mapping = JSON.parse(fs.readFileSync(mappingFile)); 11 | 12 | const domains = []; 13 | const proceduresById = {}; 14 | 15 | for (const procedure of input.procedures || []) { 16 | proceduresById[procedure.id] = { 17 | ref: procedure.id, 18 | title: procedure.name, 19 | summary: procedure.summary 20 | } 21 | } 22 | 23 | for (const policy of input.policies || []) { 24 | const controls = []; 25 | for (const control of policy.procedures || []) { 26 | if (proceduresById[control]) { 27 | controls.push(proceduresById[control]); 28 | } 29 | } 30 | domains.push({ 31 | title: policy.name, 32 | controls 33 | }) 34 | } 35 | 36 | const standard = { 37 | standard: "Security Program", 38 | version: `${new Date().getFullYear()}`, 39 | webLink: "https://apps.us.jupiterone.io/policies", 40 | domains 41 | } 42 | 43 | fs.writeFileSync(outputFile, JSON.stringify(standard, null, 2)); 44 | 45 | /** 46 | * Process SOC 2 mappings 47 | */ 48 | const soc2inputFile = '../templates/standards/soc2-controls-mapping.json'; 49 | const soc2outputFile = '../templates/standards/soc2-security-controls.json'; 50 | 51 | const soc2 = JSON.parse(fs.readFileSync(soc2inputFile)); 52 | 53 | const soc2domains = []; 54 | for (const domain of soc2.domains || []) { 55 | for (const control of domain.controls || []) { 56 | const controls = []; 57 | for (const procedureId of control.procedures || []) { 58 | const procedure = proceduresById[procedureId]; 59 | if (procedure) { 60 | controls.push({ 61 | ref: procedureId, 62 | title: procedure.title, 63 | summary: procedure.summary 64 | }); 65 | } 66 | } 67 | soc2domains.push({ 68 | title: `§ ${domain.title}\n【${control.ref}】 ${control.summary}`, 69 | controls 70 | }) 71 | } 72 | } 73 | 74 | const soc2output = { 75 | standard: soc2.standard, 76 | version: soc2.version, 77 | webLink: soc2.webLink, 78 | domains: soc2domains 79 | } 80 | 81 | fs.writeFileSync(soc2outputFile, JSON.stringify(soc2output, null, 2)); 82 | -------------------------------------------------------------------------------- /util/parser-soc2.js: -------------------------------------------------------------------------------- 1 | /** 2 | * This utility parses the SOC 2 controls into a JSON document 3 | */ 4 | const csvtojson = require("csvtojson"); 5 | const fs = require('fs'); 6 | const startCase = require('lodash/startcase'); 7 | 8 | /** 9 | * Expected CSV Headers: 10 | * Ref,Criteria,Controls,Selected Controls 11 | */ 12 | const scope = 'Security'; 13 | const inputFile = `.work/soc2-controls.csv`; 14 | const outputFile = `../templates/standards/soc2-${scope.toLowerCase()}.json`; 15 | const tempFile = '.work/soc2-controls.json'; 16 | 17 | async function parse() { 18 | const framework = { 19 | standard: 'SOC 2', 20 | version: `TSC ${scope}`, 21 | webLink: 'https://www.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/trust-services-criteria.pdf', 22 | domains: [] 23 | }; 24 | 25 | const data = await csvtojson().fromFile(inputFile); 26 | 27 | fs.writeFileSync(tempFile, JSON.stringify(data, null, 2)); 28 | 29 | const domains = []; 30 | const controlsByDomain = {} 31 | 32 | let domain; 33 | let controls; 34 | for (const control of data || []) { 35 | if (control.Ref.length == 0 && control.Criteria.length > 0) { 36 | domain = startCase(control.Criteria.toLowerCase()); 37 | controls = controlsByDomain[domain] || []; 38 | 39 | if (!domains.includes(domain)) { 40 | domains.push(domain); 41 | controlsByDomain[domain] = controls; 42 | } 43 | } 44 | else if (control.Ref.length > 0) { 45 | controls.push( 46 | ...parseControl(control) 47 | ); 48 | } 49 | } 50 | 51 | for (const domain of domains) { 52 | framework.domains.push({ 53 | title: domain, 54 | controls: controlsByDomain[domain], 55 | }); 56 | } 57 | 58 | fs.writeFileSync(outputFile, JSON.stringify(framework, null, 2)); 59 | } 60 | 61 | function parseControl(data) { 62 | const title = data.Criteria.split(':')[0]; 63 | const summary = data.Criteria.split(':')[1]; 64 | 65 | const criteria = { 66 | ref: data.Ref, 67 | title: summary ? title.trim() : data.Ref, 68 | summary: summary ? summary.trim() : title.trim(), 69 | } 70 | 71 | const controls = []; 72 | let controlNum = 0; 73 | for (const control of data.Controls.split('•') || []) { 74 | if (controlNum == 0) { 75 | controlNum++; 76 | continue; 77 | } 78 | const controlSummary = control.trim(); 79 | if (controlSummary.length > 0) { 80 | controls.push({ 81 | ref: `${data.Ref} (${String.fromCharCode(96 + controlNum)})`, 82 | summary: controlSummary 83 | }); 84 | controlNum++; 85 | } 86 | } 87 | 88 | return [ 89 | criteria, 90 | ...controls 91 | ]; 92 | } 93 | 94 | parse(); -------------------------------------------------------------------------------- /util/parser-thsa.js: -------------------------------------------------------------------------------- 1 | /** 2 | * This utility parses the THSA questionnaire into a JSON document 3 | * 4 | * THSA - Together Health Security Assessment 5 | * see: https://www.together.health/security-assessment 6 | */ 7 | const csvtojson = require("csvtojson"); 8 | const fs = require('fs'); 9 | 10 | /** 11 | * Expected CSV Headers: 12 | * Ref,Criteria,Controls,Selected Controls 13 | */ 14 | const version = '2019.1'; 15 | const inputFile = `.work/TogetherHealth+Security+Assessment+-+THSA+v2019.1.csv`; 16 | const outputFile = `../templates/standards/thsa.json`; 17 | const tempFile = '.work/thsa-controls.json'; 18 | 19 | const headerRefId = 'SCF #'; 20 | const headerDomain = 'SCF Domain'; 21 | const headerControl = 'SCF Control'; 22 | const headerDescription = 'SCF Control Question'; 23 | 24 | async function parse() { 25 | const framework = { 26 | standard: 'THSA', 27 | version, 28 | webLink: 'https://www.together.health/security-assessment', 29 | domains: [] 30 | }; 31 | 32 | const data = await csvtojson().fromFile(inputFile); 33 | 34 | fs.writeFileSync(tempFile, JSON.stringify(data, null, 2)); 35 | 36 | const domains = []; 37 | const controlsByDomain = {} 38 | 39 | let domain; 40 | let controls; 41 | for (const control of data || []) { 42 | if (control) { 43 | domain = control[headerDomain]; 44 | controls = controlsByDomain[domain] || []; 45 | 46 | if (!domains.includes(domain)) { 47 | domains.push(domain); 48 | controlsByDomain[domain] = controls; 49 | } 50 | 51 | if (control[headerRefId].length > 0) { 52 | controls.push({ 53 | ref: control[headerRefId], 54 | title: control[headerControl], 55 | summary: control[headerDescription] 56 | }); 57 | } 58 | } 59 | } 60 | 61 | for (const domain of domains) { 62 | framework.domains.push({ 63 | title: domain, 64 | controls: controlsByDomain[domain], 65 | }); 66 | } 67 | 68 | fs.writeFileSync(outputFile, JSON.stringify(framework, null, 2)); 69 | } 70 | 71 | parse(); -------------------------------------------------------------------------------- /util/setup-compliance-script.py: -------------------------------------------------------------------------------- 1 | import subprocess 2 | import sys 3 | 4 | def install(package): 5 | subprocess.call([sys.executable, "-m", "pip", "install", package]) 6 | 7 | 8 | if __name__ == '__main__': 9 | install('whoosh') 10 | install('argparse') 11 | install('nltk') 12 | --------------------------------------------------------------------------------