Skip to content

MCSB_v1 - DevOps Security

ID Control Domain CIS Controls v7.1 ID(s) CIS Controls v8 ID(s) NIST SP800-53 r4 ID(s) PCI-DSS v3.2.1 ID(s) Recommendation Security Principle Azure Guidance Azure Implementation and additional context AWS Guidance AWS Implementation and additional context Customer Security Stakeholders:
DS-1 DevOps Security nan 16.10 - Apply Secure Design Principles in Application Architectures SA-15: DEVELOPMENT PROCESS, STANDARDS, AND TOOLS 6.5 Conduct threat modeling Perform threat modeling to identify the potential threats and enumerate the mitigating controls. Ensure your threat modeling serves the following purposes: Use threat modeling tools such as the Microsoft threat modeling tool with the Azure threat model template embedded to drive your threat modeling process. Use the STRIDE model to enumerate the threats from both internal and external and identify the controls applicable. Ensure the threat modeling process includes the threat scenarios in the DevOps process, such as malicious code injection through an insecure artifacts repository with misconfigured access control policy. Threat Modeling Overview: Use threat modeling tools such as the Microsoft threat modeling tool with the Azure threat model template embedded to drive your threat modeling process. Use the STRIDE model to enumerate the threats from both internal and external and identify the controls applicable. Ensure the threat modeling process includes the threat scenarios in the DevOps process, such as malicious code injection through an insecure artifacts repository with misconfigured access control policy. Microsoft Threat Modeling Tool: Policy and standards: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-policy-standards
16.14 - Conduct Threat Modeling 12.2 https://www.microsoft.com/securityengineering/sdl/threatmodeling https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
Secure your applications and services in the production run-time stage. If using a threat modeling tool is not applicable, you should, at minimum, use a questionnaire-based threat modeling process to identify the threats. If using a threat modeling tool is not applicable, you should, at minimum, use a questionnaire-based threat modeling process to identify the threats. Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
Secure the artifacts, underlying CI/CD pipeline and other tooling environment used for build, test, and deployment. The threat modeling at least should include the following aspects: Application threat analysis (including STRIDE + questionnaire based method): How to approach threat modeling for AWS:
Define the security requirements of the application. Ensure these requirements are adequately addressed in the threat modeling. Ensure the threat modeling or analysis results are recorded and updated when there is a major security-impact change in your application or in the threat landscape. https://docs.microsoft.com/azure/architecture/framework/security/design-threat-model Ensure the threat modeling or analysis results are recorded and updated when there is a major security-impact change in your application or in the threat landscape. https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/ Posture management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-posture-management
Analyze application components, data connections and their relationship. Ensure this analysis also includes the upstream and downstream connections outside of your application scope.
List the potential threats and attack vectors that your application components, data connections and upstream and downstream services may be exposed to. Azure Template - Microsoft Security Threat Model Stencil: Application threat analysis (including STRIDE + questionnaire based method):
Identify the applicable security controls that can be used to mitigate the threats enumerated and identify any controls gaps (e.g., security vulnerabilities) that may require additional treatment plans. https://github.com/AzureArchitecture/threat-model-templates https://docs.microsoft.com/azure/architecture/framework/security/design-threat-model
Enumerate and design the controls that can mitigate the vulnerabilities identified.
DS-2 DevOps Security 18.3 - Verify That Acquired Software is Still Supported 16.4 - Establish and Manage an Inventory of Third-Party Software Components SA-12: SUPPLY CHAIN PROTECTION 6.3 Ensure software supply chain security Ensure your enterprise’s SDLC (Software Development Lifecycle) or process include a set of security controls to govern the in-house and third-party software components (including both proprietary and open-source software) where your applications have dependencies. Define gating criteria to prevent vulnerable or malicious components being integrated and deployed into the environment. For the GitHub platform, ensure the software supply chain security through the following capability or tools from GitHub Advanced Security or GitHub’s native feature:- Use Dependency Graph to scan, inventory and identify all your project’s dependencies and related vulnerabilities through Advisory Database. GitHub Dependency Graph: If you use AWS CI/CD platforms such as CodeCommit or CodePipeline, ensure the software supply chain security using CodeGuru Reviewer to scan the source code (for Java and Python) through the CI/CD workflows. Platforms such as CodeCommit and CodePipeline also supports third-party extensions to implement similar controls to inventory, analyze and remediate the third-party software components and their vulnerabilities. GitHub Dependency Graph: Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
18.4 - Only Use Up-to-Date And Trusted Third-Party Components 16.6 - Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities SA-15: DEVELOPMENT PROCESS, STANDARDS, AND TOOLS 6.5 https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph
18.8 - Establish a Process to Accept and Address Reports of Software Vulnerabilities 16.11 - Leverage Vetted Modules or Services for Application Security Components The software supply chain security controls should at least include the following aspects: - Use Dependabot to ensure that the vulnerable dependency is tracked and remediated, and ensure your repository automatically keeps up with the latest releases of the packages and applications it depends on. If you manage your source code through the GitHub platform, ensure the software supply chain security through the following capability or tools from GitHub Advanced Security or GitHub’s native feature: Posture management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-posture-management
- Use GitHub's native code scanning capability to scan the source code when sourcing the code externally. GitHub Dependabot: - Use Dependency Graph to scan, inventory and identify all your project’s dependencies and related vulnerabilities through Advisory Database. GitHub Dependabot:
Properly manage a Software Bill of Materials (SBOM) by identifying the upstream dependencies required for the service/resource development, build, integration and deployment phase. - Use Microsoft Defender for Cloud to integrate vulnerability assessment for your container image in the CI/CD workflow. https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates - Use Dependabot to ensure that the vulnerable dependency is tracked and remediated, and ensure your repository automatically keeps up with the latest releases of the packages and applications it depends on. https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates
Inventory and track the in-house and third-party software components for known vulnerability when there is a fix available in the upstream. For Azure DevOps, you can use third-party extensions to implement similar controls to inventory, analyze and remediate the third-party software components and their vulnerabilities - Use GitHub's native code scanning capability to scan the source code when sourcing the code externally.
Assess the vulnerabilities and malware in the software components using static and dynamic application testing for unknown vulnerabilities. Identify vulnerable container images in your CI/CD workflows: - If applicable, use Microsoft Defender for Cloud to integrate vulnerability assessment for your container image in the CI/CD workflow. DevOps in AWS:
Ensure the vulnerabilities and malware are mitigated using the appropriate approach. This may include source code local or upstream fix, feature exclusion and/or applying compensating controls if the direct mitigation is not available. https://docs.microsoft.com/azure/security-center/defender-for-container-registries-cicd https://aws.amazon.com/devops/
If closed source third-party components are used in your production environment, you may have limited visibility to its security posture. You should consider additional controls such as access control, network isolation and endpoint security to minimize the impact if there is a malicious activity or vulnerability associated with the component.
Azure DevOps Marketplace – supply chain security: Software Bill of Materials:
https://marketplace.visualstudio.com/search?term=tag%3ASupply%20Chain%20Security&target=VSTS https://www.cisa.gov/sbom
DS-3 DevOps Security 18.11 - Use Standard Hardening Configuration Templates for Databases 16.7 - Use Standard Hardening Configuration Templates for Application Infrastructure CM-2: BASELINE CONFIGURATION 2.2 Secure DevOps infrastructure Ensure the DevOps infrastructure and pipeline follow security best practices across environments including your build, test, and production stages. This typically includes the security controls for following scope: As part of applying the Microsoft Cloud Security Benchmark to your DevOps infrastructure security controls, prioritize the following controls: DevSecOps controls overview – secure pipelines: As part of applying the Microsoft Cloud Security Benchmark to the security controls of your DevOps infrastructure, such as GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild and CodeDeploy, prioritize the following controls: AWS Well-architected Framework - security pillar: Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
CM-6: CONFIGURATION SETTINGS 6.3 - Protect artifacts and the underlying environment to ensure the CI/CD pipelines don’t become avenues to insert malicious code. For example, review your CI/CD pipeline to identify any misconfiguration in core areas of Azure DevOps such as Organization, Projects, Users, Pipelines (Build & Release), Connections, and Build Agent to identify any misconfigurations such as open access, weak authentication, insecure connection setup and so on. For GitHub, use similar controls to secure the Organization permission levels. https://docs.microsoft.com/azure/cloud-adoption-framework/secure/devsecops-controls - Refer to this guidance and the AWS Well-architected Framework security pillar to secure your DevOps environments in AWS. https://wa.aws.amazon.com/wat.pillar.security.en.html
AC-2: ACCOUNT MANAGEMENT 7.1 - Artifact repositories that store source code, built packages and images, project artifacts and business data. - Ensure your DevOps infrastructure is deployed consistently across development projects. Track compliance of your DevOps infrastructure at scale by using Microsoft Defender for Cloud (such as Compliance Dashboard, Azure Policy, Cloud Posture Management) or your own compliance monitoring tools. - Protect artifacts and the underlying supporting infrastructure to ensure the CI/CD pipelines don’t become avenues to insert malicious code. Posture management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-posture-management
AC-3: ACCESS ENFORCEMENT - Servers, services, and tooling that host CI/CD pipelines. - Configure identity/role permissions and entitlement policies in Azure AD, native services, and CI/CD tools in your pipeline to ensure changes to the pipelines are authorized. Secure your GitHub organization: - Ensure your DevOps infrastructure is deployed and sustained consistently across development projects. Track compliance of your DevOps infrastructure at scale by using AWS Config or your own compliance check solution.
AC-6: LEAST PRIVILEGE - CI/CD pipeline configuration. - Avoid providing permanent “standing” privileged access to the human accounts such as developers or testers by using features such as Azure managed identifies and just-in-time access. https://docs.github.com/en/code-security/getting-started/securing-your-organization - Use CodeArtifact to securely store and share software packages used for application development. You can use CodeArtifact with popular build tools and package managers such as Maven, Gradle, npm, yarn, pip, and twine. Infrastructure and endpoint security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-infrastructure-endpoint
- Remove keys, credentials, and secrets from code and scripts used in CI/CD workflow jobs and keep them in a key store or Azure Key Vault. - Configure identity/role permissions and permission policies in AWS IAM, native services, and CI/CD tools in your pipeline to ensure changes to the pipelines are authorized.
- If you run self-hosted build/deployment agents, follow Microsoft Cloud Security Benchmark controls including network security, posture and vulnerability management, and endpoint security to secure your environment. Azure DevOps pipeline – Microsoft hosted agent security considerations: - Remove keys, credentials, and secrets from code and scripts used in CI/CD workflow jobs and keep them in key store or AWS KMS Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
https://docs.microsoft.com/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#security - If you run self-hosted build/deployment agents, follow Microsoft Cloud Security Benchmark controls including network security, posture and vulnerability management, and endpoint security to secure your environment. Use AWS Inspector for vulnerability scanning for vulnerabilities in EC2 or containerized environment as the build environment.
Note: Refer to the Logging and Threat Detection, DS-7, and the Posture and Vulnerability Management sections to use services such as Azure Monitor and Microsoft Sentinel to enable governance, compliance, operational auditing, and risk auditing for your DevOps infrastructure.
Note: Refer to the Logging and Threat Detection, DS-7, and the and Posture and Vulnerability Management sections to use services such as AWS CloudTrail, CloudWatch and Microsoft Sentinel to enable governance, compliance, operational auditing, and risk auditing for your DevOps infrastructure.
DS-4 DevOps Security 18.7 - Apply Static and Dynamic Code Analysis Tools 16.12 - Implement Code-Level Security Checks SA-11: DEVELOPER TESTING AND EVALUATION 6.3 Integrate static application security testing into DevOps pipeline Ensure static application security testing (SAST) fuzzy testing, interactive testing, mobile application testing, are part of the gating controls in the CI/CD workflow. The gating can be set based on the testing results to prevent vulnerable packages from committing into the repository, building into the packages, or deploying into the production. Integrate SAST into your pipeline (e.g., in your infrastructure as code template) so the source code can be scanned automatically in your CI/CD workflow. Azure DevOps Pipeline or GitHub can integrate the below tools and third-party SAST tools into the workflow. GitHub CodeQL: Integrate SAST into your pipeline so the source code can be scanned automatically in your CI/CD workflow. Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST and DAST tools: Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
6.5 - GitHub CodeQL for source code analysis. https://codeql.github.com/docs/ https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/
- Microsoft BinSkim Binary Analyzer for Windows and *nix binary analysis. If using AWS CodeCommit, use AWS CodeGuru Reviewer for Python and Java source code analysis. AWS Codepipeline can also support integration of third-part SAST tools into the code deployment pipeline. Posture management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-posture-management
- Azure DevOps Credential Scanner (Microsoft Security DevOps extension) and GitHub native secret scanning for credential scan in the source code. BinSkim Binary Analyzer:
https://github.com/microsoft/binskim If using GitHub, the below tools and third-party SAST tools can be integrated into the workflow.
- GitHub CodeQL for source code analysis.
Azure DevOps Credential Scan: - Microsoft BinSkim Binary Analyzer for Windows and *nix binary analysis.
https://secdevtools.azurewebsites.net/helpcredscan.html - GitHub native secret scanning for credential scan in the source code.
- AWS CodeGuru Reviewer for Python and Java source code analysis.
GitHub secret scanning:
https://docs.github.com/en/code-security/secret-security/about-secret-scanning
DS-5 DevOps Security 18.7 - Apply Static and Dynamic Code Analysis Tools 16.12 - Implement Code-Level Security Checks SA-11: DEVELOPER TESTING AND EVALUATION 6.3 Integrate dynamic application security testing into DevOps pipeline Ensure dynamic application security testing (DAST) are part of the gating controls in the CI/CD workflow. The gating can be set based on the testing results to prevent vulnerability from building into the packages or deploying into the production. Integrate DAST into your pipeline so the runtime application can be tested automatically in your CI/CD workflow set in Azure DevOps or GitHub. The automated penetration testing (with manual assisted validation) should also be part of the DAST. DAST tools in Azure DevOps marketplace: Integrate DAST into your pipeline so the runtime application can be tested automatically in your CI/CD workflow set in AWS CodePipeline or GitHub. The automated penetration testing (with manual assisted validation) should also be part of the DAST. Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST and DAST tools: Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
6.5 https://marketplace.visualstudio.com/search?term=DAST&target=AzureDevOps&category=All%20categories https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/
Azure DevOps Pipeline or GitHub supports the integration of third-party DAST tools into the CI/CD workflow. AWS CodePipeline or GitHub supports integration of third-party DAST tools into the CI/CD workflow. Posture management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-posture-management
DS-6 DevOps Security 5.2 - Deploy System Configuration Management Tools 7.5 - Perform Automated Vulnerability Scans of Internal Enterprise Assets CM-2: BASELINE CONFIGURATION 6.1 Enforce security of workload throughout DevOps lifecycle Ensure the workload is secured throughout the entire lifecycle in development, testing, and deployment stage. Use Microsoft Cloud Security Benchmark to evaluate the controls (such as network security, identity management, privileged access and so on) that can be set as guardrails by default or shift left prior to the deployment stage. In particular, ensure the following controls are in place in your DevOps process: Guidance for Azure VMs: Shared Image Gallery overview: Use Amazon Elastic Container Registry to share and control access to your images by different users and roles within your organization. And Use AWS IAM to ensure that only authorized users can access your custom images. AWS ECR image scanning: Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
5.3 - Securely Store Master Images 7.6 - Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets CM-6: CONFIGURATION SETTINGS 6.2 - Automate the deployment by using Azure or third-party tooling in the CI/CD workflow, infrastructure management (infrastructure as code), and testing to reduce human error and attack surface. - Use Azure Shared Image Gallery to share and control access to your images by different users, service principals, or AD groups within your organization. Use Azure role-based access control (Azure RBAC) to ensure that only authorized users can access your custom images. https://docs.microsoft.com/azure/virtual-machines/windows/shared-image-galleries https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html
5.4 - Deploy System Configuration Management Tools 7.7 - Remediate Detected Vulnerabilities AC-2: ACCOUNT MANAGEMENT 6.3 - Ensure VMs, container images and other artifacts are secure from malicious manipulation. - Define the secure configuration baselines for the VMs to eliminate unnecessary credentials, permissions, and packages. Deploy and enforce configuration baselines through custom images, Azure Resource Manager templates, and/or Azure Policy guest configuration. Define the secure configuration baselines for the EC2 AMI images to eliminate unnecessary credentials, permissions, and packages. Deploy and enforce configurations baselines through custom AMI images, CloudFormation templates, and/or AWS Config Rules. Posture management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-posture-management
5.5 - Implement Automated Configuration Monitoring Systems 16.1 - Establish and Maintain a Secure Application Development Process AC-3: ACCESS ENFORCEMENT - Scan the workload artifacts (in other words, container images, dependencies, SAST and DAST scans) prior to the deployment in the CI/CD workflow How to implement Microsoft Defender for Cloud vulnerability assessment recommendations: https://docs.microsoft.com/azure/security-center/security-center-vulnerability-assessment-recommendations AWS Inspector:
18.1 - Establish Secure Coding Practices 16.7 - Use Standard Hardening Configuration Templates for Application Infrastructure AC-6: LEAST PRIVILEGE - Deploy vulnerability assessment and threat detection capability into the production environment and continuously use these capabilities in the run-time. Guidance for Azure container services: Use AWS Inspector for vulnerability scanning of VM's and Containerized environments, securing them from malicious manipulation. https://docs.aws.amazon.com/inspector/latest/user/getting_started_tutorial.html Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
- Use Azure Container Registry (ACR) to create your private container registry where granular access can be restricted through Azure RBAC, so only authorized services and accounts can access the containers in the private registry. Security considerations for Azure Container:
- Use Defender for Containers for vulnerability assessment of the images in your private Azure Container Registry. In addition, you can use Microsoft Defender for Cloud to integrate the container image scans as part of your CI/CD workflows. https://docs.microsoft.com/azure/container-instances/container-instances-image-security For AWS serverless services, use AWS CodePipeline in conjunction with AWS AppConfig to adopt similar controls to ensure security controls "shift left" to the stage prior to deployment. AWS AppConfig:
https://docs.aws.amazon.com/appconfig/latest/userguide/getting-started-with-appconfig.html
For Azure serverless services, adopt similar controls to ensure security controls "shift-left" to the stage prior to deployment. Azure Defender for container registries:
https://docs.microsoft.com/azure/security-center/defender-for-container-registries-introduction
DS-7 DevOps Security 6.2 - Activate audit logging 8.2 Collect Audit Logs AU-3: CONTENT OF AUDIT RECORDS 10.1 Enable logging and monitoring in DevOps Ensure your logging and monitoring scope includes non-production environments and CI/CD workflow elements used in DevOps (and any other development processes). The vulnerabilities and threats targeting these environments can introduce significant risks to your production environment if they are not monitored properly. The events from the CI/CD build, test and deployment workflow should also be monitored to identify any deviations in the CI/CD workflow jobs. Enable and configure the audit logging capabilities in non-production and CI/CD tooling environments (such as Azure DevOps and GitHub) used throughout the DevOps process. Azure DevOps - audit streaming: Enable and configure AWS CloudTrail for audit logging capabilities in non-production and CI/CD tooling environments (such as AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) used throughout the DevOps process. Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log data: Security operations: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-operations-center
6.3 - Enable Detailed Logging 8.5 Collect Detailed Audit Logs AU-6: AUDIT REVIEW, ANALYSIS, AND REPORTING 10.2 https://docs.microsoft.com/azure/devops/organizations/audit/auditing-streaming?view=azure-devops https://docs.microsoft.com/en-us/azure/sentinel/connect-aws?tabs=s3
6.5 - Central Log Management 8.9 Centralize Audit Logs AU-12: AUDIT GENERATION 10.3 Follow Microsoft Cloud Security Benchmark – Logging and Threat Detection as the guideline to implement your logging and monitoring controls for workload. The events generated from Azure DevOps and the GitHub CI/CD workflow, including the build, test and deployment jobs, should also be monitored to identify any anomalous results. The events generated from the AWS CI/CD environments (such as AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) and the GitHub CI/CD workflow, including the build, test and deployment jobs, should also be monitored to identify any anomalous results. Application security and DevSecOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
6.6 - Deploy SIEM or Log Analytic tool 8.11 Conduct Audit Log Reviews SI-4: INFORMATION SYSTEM MONITORING 10.6 GitHub logging: GitHub Logging:
6.7 - Regularly Review Logs Ingest the above logs and events into Microsoft Sentinel or other SIEM tools through a logging stream or API to ensure the security incidents are properly monitored and triaged for handling. https://docs.github.com/en/organizations/keeping-your-organization-secure/reviewing-the-audit-log-for-your-organization Ingest the above logs and events into AWS CloudWatch, Microsoft Sentinel or other SIEM tools through a logging stream or API to ensure the security incidents are properly monitored and triaged for handling. https://docs.github.com/en/organizations/keeping-your-organization-secure/reviewing-the-audit-log-for-your-organization Incident preparation: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-incident-preparation
6.8 - Regularly Tune SIEM