- Philosophy of integrating security practices within the DevOps process.
- Makes security a responsibility of everyone on the team
- 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
- Injection
- Never trust any user input
- Broken authentication
- Use custom or own authentication system rather than well known authentication systems
- Sensitive data exposure
- XML external entities
- Broken access control
- Roles and permission poorly implemented or not implemented at all
- Injection
- Top 5 from the Top 10
- 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.
- Helps you to
- 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).
- Do not store credentials in code
- Use continuous learning and monitoring
- 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:
- Defining security requirements.
- Creating an application diagram.
- Identifying threats.
- Mitigating threats.
- Validating that threats have been mitigated.
- Whitesource – Open source library vulnerabilities and license
- Black Duck – Open source library vulnerabilities and license
- Checkmarx – Static Application Security Testing (SAST) tool
- BinSkim – A binary static analysis tool that provides security and correctness results for Windows portable executables
- See also penetration testing
- Full name: OWASP Zed Attack Proxy (ZAP)
- 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.
- ❗️ It's replaced by AzTS as of 2021.
- PowerShell cmdlets and guidance for security best practices
- Scans Azure resources (run PowerShell command) and provide CSV file with the scan result and recommendations as fix script.
- Allows running the recommendation fix with command to automatically fix issues
- On Azure DevOps you can use Secure DevOps Kit (AzSK) CICD Extensions for Azure
- Allows for scanning whitelisted/blacklisted ports.
- 👀 Official page
- Cloud security and compliance solution using native security capabilities in Azure
- Scans Azure subscriptions and resource configurations across multiple subscriptions
- Next level AzSK, similar to AzSK Continuous Assurance (CA) in central-scan mode.
- Integrates with Azure/Azure Security Center policies
- Requires installation on Azure with a management identity with reader permissions
- Stores results in Log Analytics Workspace that can be sent to Power BI
- 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
- Centralizes security policy management
- Continuous security assessment
- Actionable recommendations
- Prioritized alerts and incidents
- 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:
- Build
- Static Security Scan
- Package
- Deploy
- 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
- Application CI/CD:
- See also penetration testing tools
-
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:
- 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
- 💡 You can use Static Code Analysis Code Review tools
- 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
- 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
- Verify that there are not any security vulnerabilities in the running application
- When interacting with
- 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.
- 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
- Drift involving 'baseline' configuration
- For more info & scripts, see Secure DevOps Kit for Azure