diff --git a/src/assets/data/resources.json b/src/assets/data/resources.json index eb98056d..139b4cbc 100644 --- a/src/assets/data/resources.json +++ b/src/assets/data/resources.json @@ -1,31 +1,69 @@ { "items": [ { - "name" : "Quick Start Steps", - "desc" : "
Which component types are being used to build your system? Consider types of Cloud Services, Virtualization Platforms, Operating Systems, Databases, Application Logic, and Web Servers.
See our CMS SAF Implementation/Hardening page for scripts to automatically harden the system components you identified in Step 1 every time you build or fix them.
See our CMS SAF Validation page for scripts to automatically validate the security of your system components identified in Step 1 every time you build or fix them.
Depending on how you develop and operate your system, be it traditional administrative servers or DevOps orchestration pipelines, you can decide where it makes the most sense to stage the hardening (Kitchen, Ansible, Terraform, Puppet, etc) and validation (InSpec) runners for the scripts identified in Steps 2 and 3 (See graphic below on the many ways InSpec can be installed).
See our Heimdall_tools page to find code to convert the output from common Static and Dynamic Code Analysis Tools into the CMS ISPG standard Heimdall Data Format (HDF). HDF security validation data can be visualized for analysis using Heimdall Lite or Heimdall Server (more on those in Step 6!).
Use Heimdall Lite or your own Heimdall Server to visualize and identify remediation steps in the output from InSpec (Step 3 Validation) and Heimdall_tools (Step 5). Heimdall Lite is a single-page browser-based solution, while Heimdall Server provides your team with its own back-end database for storing security validation data and more! Both allow the user to ingest security validation data via a GUI, the API, Splunk, or S3!
If you don’t see a hardening script, validation script, or security tool converter you need here, click on the \"Give Us Feedback\" button in the header above and let us know your interest!
Want more context? The steps above embrace the best practices cited below. We also provide more perspective below on InSpec, the core CMS SAF tool for automated security configuration validation.
" + "name": "Tutorials", + "desc": "See below for video examples of installing and running SAF tools.", + "videos": { + "goals": [ + { + "name": "Validate", + "install_links": [{ "name": "InSpec", "link": "https://saf.cms.gov" }], + "run_links": [ + { "name": "InSpec scan against remote operating systems", "link": "https://saf.cms.gov" }, + { "name": "InSpec scan against AWS resources", "link": "https://saf.cms.gov" }, + { "name": "InSpec scan against remote databases (conventional and AWS-based)", "link": "https://saf.cms.gov" }, + { "name": "InSpec scan against remote application services", "link": "https://saf.cms.gov" }, + { "name": "InSpec scan against remote web servers", "link": "https://saf.cms.gov" }, + { "name": "InSpec scan of docker instances", "link": "https://saf.cms.gov" } + ] + }, + { + "name": "Normalize", + "install_links": [{ "name": "Heimdall_Tools", "link": "https://heimdall-tools.mitre.org" }], + "run_links": [ + { "name": "Converting Sonarqube to view in Heimdall Server", "link": "https://saf.cms.gov" }, + { "name": "Converting Burp Suite to view in Heimdall Server", "link": "https://saf.cms.gov" } + ] + }, + { + "name": "Visualize", + "install_links": [{ "name": "Heimdall Server", "link": "https://heimdall.mitre.org" }], + "run_links": [ + { "name": "Load via GUI", "link": "https://saf.cms.gov" }, + { "name": "Load via S3", "link": "https://saf.cms.gov" }, + { "name": "Load via Splunk", "link": "https://saf.cms.gov" }, + { "name": "Load via API", "link": "https://saf.cms.gov" } + ] + } + ] + } + }, + { + "name": "Planning Guide", + "desc": "Which component types are being used to build your system? Consider types of Cloud Services, Virtualization Platforms, Operating Systems, Databases, Application Logic, and Web Servers.
See our CMS SAF Implementation/Hardening page for scripts to automatically harden the system components you identified in Step 1 every time you build or fix them.
See our CMS SAF Validation page for scripts to automatically validate the security of your system components identified in Step 1 every time you build or fix them.
Depending on how you develop and operate your system, be it traditional administrative servers or DevOps orchestration pipelines, you can decide where it makes the most sense to stage the hardening (Kitchen, Ansible, Terraform, Puppet, etc) and validation (InSpec) runners for the scripts identified in Steps 2 and 3 (See graphic below on the many ways InSpec can be installed).
See our Heimdall_tools page to find code to convert the output from common Static and Dynamic Code Analysis Tools into the CMS ISPG standard Heimdall Data Format (HDF). HDF security validation data can be visualized for analysis using Heimdall Lite or Heimdall Server (more on those in Step 6!).
Use Heimdall Lite or your own Heimdall Server to visualize and identify remediation steps in the output from InSpec (Step 3 Validation) and Heimdall_tools (Step 5). Heimdall Lite is a single-page browser-based solution, while Heimdall Server provides your team with its own back-end database for storing security validation data and more! Both allow the user to ingest security validation data via a GUI, the API, Splunk, or S3!
If you don’t see a hardening script, validation script, or security tool converter you need here, click on the \"Give Us Feedback\" button in the header above and let us know your interest!
Want more context? The steps above embrace the best practices cited below. We also provide more perspective below on InSpec, the core CMS SAF tool for automated security configuration validation.
" }, { "name": "Mature DevSecOps Best Practices", "desc": "DevSecOps is a software development framework that stresses automation and rapid user feedback to deliver quality, secure software quickly. A DevSecOps pipline is a collection of tools and practices that can automate as much of development as possible, from testing to change management to deployment.", - "values" : [ + "values": [ { - "name" : "DevSecOps Checklist", - "desc" : "", - "download_link" : "DevSecOps-Checklist-07022020.pdf" + "name": "DevSecOps Checklist", + "desc": "", + "download_link": "DevSecOps-Checklist-07022020.pdf" }, { - "name" : "DevSecOps Best Practices Guide", - "desc" : "", - "download_link" : "DRAFT-DevSecOps_Best_Practices_Guide_20190516.pdf" + "name": "DevSecOps Best Practices Guide", + "desc": "", + "download_link": "DRAFT-DevSecOps_Best_Practices_Guide_20190516.pdf" }, { - "name" : "InSpec Profile Lifecycle SOP", - "desc" : "", - "download_link" : "CMS_InSpec_Profile_Lifecycle_SOP_v1.0_20190702.pdf" + "name": "InSpec Profile Lifecycle SOP", + "desc": "", + "download_link": "CMS_InSpec_Profile_Lifecycle_SOP_v1.0_20190702.pdf" } ] }, - + { "name": "InSpec", "desc": "InSpec is a free and open-source Chef framework for testing and auditing applications and infrastructure. InSpec is designed to integrate very easily into existing DevSecOps pipelines. CMS has partnered with the open-source community to create a growing number of baseline testing profiles to make it easy for developers to jump right in.", diff --git a/src/components/gettingstarted/gsInfo.vue b/src/components/gettingstarted/gsInfo.vue index 9278351a..9d4c8014 100644 --- a/src/components/gettingstarted/gsInfo.vue +++ b/src/components/gettingstarted/gsInfo.vue @@ -2,24 +2,123 @@- {{item.name}} +
+ {{ item.name }}
-+
- {{entry.name}} + {{ + entry.name + }} {{entry.name}} + >{{ entry.name }} -
-{{ goal.name }}
Install
Run