Azure-in-bullet-points

DevSecOps (Security)

• Philosophy of integrating security practices within the DevOps process.
• Makes security a responsibility of everyone on the team

Best Practices

• Provide training
• Define requirements
  • Minimum-security baseline that takes account of both security and compliance controls
  • Ensure these are baked into the DevOps process and pipeline
  • Check at least for OWASP Top 10, SANS Top 25
    • Top 5 from the Top 10
      1. Injection
         • Never trust any user input
      2. Broken authentication
         • Use custom or own authentication system rather than well known authentication systems
      3. Sensitive data exposure
      4. XML external entities
      5. Broken access control
         • Roles and permission poorly implemented or not implemented at all
• Define metrics and compliance reporting
• Use software composition analysis (SCA) and governance
  • Evaluate third party components for security & licensing
• Perform threat modeling
  • Helps you to
    • More effectively and less expensively identify security vulnerabilities
    • Determine risks from those threats
    • Make security feature selections and establish appropriate mitigations
  • At the very least, threat modeling should be used in environments where there is meaningful security risk.
• Use tools and automation
  • Integrate Static Application Security Testing (SAST) into your IDE
  • Integrate Dynamic Analysis Security Testing (DAST) tools into CI/CD
  • Choosing tools:
    • Tools must be integrated into the CI/CD pipeline.
    • Tools must not require security expertise.
    • Tools must avoid a high false-positive rate of reporting issues.
• Keep credentials safe
  • Do not store credentials in code
    • Consider using a bring-your-own-key (BYOK) solution that generates keys using a hardware security module (HSM).
• Use continuous learning and monitoring

Threat Modeling

• Do it as soon as and often as possible
  • Not only when releasing a new feature because single line of code can change everything
• Microsoft Threat Modeling tools is a tool for threat modeling.
• Steps:
  1. Defining security requirements.
  2. Creating an application diagram.
  3. Identifying threats.
  4. Mitigating threats.
  5. Validating that threats have been mitigated.

Security tools

• Open source library vulnerabilities and license
  • Whitesource – Open source library vulnerabilities and license
  • Black Duck – Open source library vulnerabilities and license
• Static security testing
  • Checkmarx – Static Application Security Testing (SAST) tool
  • BinSkim – A binary static analysis tool that provides security and correctness results for Windows portable executables
• Penetration testing
  • OWASP ZAP – penetration testing
    • 💡 passive tests with CI and active tests with nightly build
    • Better to use the OWASP Zap/Weekly docker container within Azure Container Services to get latest updates.
  • Azure DevOps Security Kit (AzSk)
    • PowerShell cmdlets and guidance for security best practices
    • Scans your Azure resources (run PowerShell command) and provide CSV file with the scan result and recommendations as fix script.
    • You can run the recommendation fix with command to automatically fix issues
    • With Azure DevOps Security Kit (AzSk) (VSTS extension), you can scan whitelisted/blacklisted ports.
• Secret management
  • Azure Key Vault
• Governance & compliance
  • Azure policy
    • Natively create policies, e.g, you create a policy from Azure (portal/CLI/REST API) to prevent creation of VM with high cost or specific region
  • Azure Blueprints (Polices, RBAC, ARM)
    • Container above resource group / subscriptions.
    • Helps to apply roles & ARM templates in a repeatable configuration manner
  • Azure Artifacts to stay in control of the dependencies that are consumed
• Azure Security Center
  • Centralizes security policy management
  • Continuous security assessment
  • Actionable recommendations
  • Prioritized alerts and incidents

Penetration testing

• To find out weaknesses in the system
• Passive Tests or Passive Scan
  • Scan the target site as is but don’t try to manipulate the requests to expose additional vulnerabilities.
  • Runs fast and good candidate for CI as they complete in minutes
• Active Tests or Active Scan
  • Also called as dynamic or fuzz tests because
  • Used to simulate many techniques that hackers commonly use to attack websites
  • Tries a large number of different combinations to see how the site reacts to verify that it doesn’t reveal any information
  • CI/CD pipeline should run within a few minutes, so you don’t want to include any long-running processes.
    • Nightly tests are a good idea.
• OWASP ZAP is a free penetration testing tool for beginners to professionals
  • OWASP Zap/Weekly docker container within Azure Container Services ensures the image is always updated.
• Example pipelines:
  • Application CI/CD:
    1. Build
    2. Static Security Scan
    3. Package
    4. Deploy
    5. Passive Pentest: Pull OWASP Zap Weekly => Start Container => Run Baseline (1 to 2 min) => Report Results => High alerts - Fail, Release, All Alerts - Create bugs
  • Nightly OWASP ZAP Pipeline
    • Nightly Schedule
    • Application Full Active Scan: Pull OWASP Zap Weekly => Start Container => Spider Site => Run Active Scan => Report Results => High Alerts - Fail, Release, All Alerts - Create Bugs

Continuous Security Validation

• Should be done at every point in application lifecycle:

  Stage	Application CI / CD	Feedback	Nightly Test Runs
  IDE / Pull request	• Static Code Analysis • Code Review • Work Item Linking	• Code Review Comments • Static Code Rule Warnings	-
  CI	• Static Code Analysis • OSS Vulnerability Scan • Unit Tests • Code Metrics	• OSS Library Vulnerabilities • OSS License Violations • Failed Unit Tests • Static Code Rule warnings	-
  Dev	• Passive Pen Test • SSL Scanner • Infrastructure Scan	• Pen Test Issues • SSL Issues • Performance Issues • Regression Bugs	• Load and Performance Testing • Automated Regression Testing • Infrastructure Scan
  Test	• Infrastructure Scan	• Pen Test Issues • Infrastructure Issues	• Active Pen Test • Infrastructure Scan

• CI/CD steps:

  1. When interacting with master branch.
     • Can be pull request / code commits / code merges…
     • PR to master should require a code review
       • Possible with a branch policy in Azure Repos
     • Commits should be linked to work items for auditing why the code change was made and require a CI.
     • Should have a PR-CI (Pull Request Continuous Integration)
       • 💡 You can use Static Code Analysis Code Review tools
         • Highlights any security / vulnerability issues in code
  2. Continues integration through e.g. Jenkins
     • Difference from PR-CI => it does packaging also.
     • Should do Static Code Analysis with e.g.
       • Visual Studio Code Analysis and the Roslyn Security Analyzers
       • Checkmarx - A Static Application Security Testing (SAST) tool
       • BinSkim - Binary static analysis tool that provides security and correctness results for Windows portable executables
       • See other tools
     • Many tools integrate into the Azure Pipelines build process.
     • Scan for 3rd party packages for vulnerabilities & OSS (open-source) license usage
       • See WhiteSource, Black Duck
     • Also run unit tests & report code metrics
  3. Promoting to development & test (QA) stage
     • Verify that there are not any security vulnerabilities in the running application
       • = Automated Penetration testing
     • Infrastructure scanning
       • Is your hardware up-to-date? Are all tools installed on development machine? Are all tools patched with latest security patches?
       • E.g. Azure Security Center to report and Azure Policies to prevent.
       • E.g. Both immediate & nightly runs of port scanning to check against blacklisted/whitelisted ports
     • Load and Performance testing, Automated Regression Testing

Container Security

• Container security best-practices: (whitepaper)
  • Scan for vulnerabilities before pushing images to registry.
  • Continue scanning in the registry because new vulnerabilities are discovered all the time.

Continuous Assurance

• Tracks configuration drift
  • Checks for “drift” from what is considered a secure snapshot of a system
• Treat security truly as a ‘state’ as opposed to a ‘point in time’ achievement
  • important in today’s context when ‘continuous change’ has become a norm.
• 2 types of drift:
  • Drift involving ‘baseline’ configuration
    • Often pre-defined/statically determined ones
    • E.g. SQL DB can have TDE encryption turned ON or OFF
  • Drift involving ‘stateful’ configuration
    • Cannot be constrained within a finite set of well-known states.
    • E.g. the IP addresses configured to have access to a SQL DB
• For more info & scripts, see Secure DevOps Kit for Azure

This site is open source. Improve this page.