From DevOps to DevSecOps - SDLC

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market. (from AWS)

History

Prior to 2010,

• Structured Development methodologies
• Clent-server
• Waterfall Model

Now,

• Moved from structured development methodologies to object-oriented paradigm
• Moved from client-server to service-oriented architecture
• Moved from the waterfall model to agile methods

Agile & DevOps

Continuous Integration and Continuous Delivery (CI/CD) relies on the automation of routine work.

Agile and DevOps

Basic SDLC has not changed .
Requirements ->Design->Development (Implementation)->Testing->Operations

Microsoft Security DLC

Reference: 

• Application Security
• Engineering more secure software with the Microsoft Security Lifecycle (SDL)

How to Develop a Security Strategy within DevOps

Tools and Framework:

• Culture: Collaboration and Contribution. Everyone is responsible for security. Goal is equal to safely distributing security decisions
• Processes: Significant changes to existing workflows & processes. Team communication, collaboration, reporting, measurements, security, development, operations, end to end, implementing changes, continuous loop. 
• Technologies: Threat modeling, attack surface evaluation, static & dynamic analysis, penetration testing, fuzz testing

Five Principles for Securing DevOps

• Automate Security in: automated invocation security testing with Comprehensive API.
• Integrate to Fail Quickly: Integrating security CI/CD pipeline for application security.
• No False Alarms
• Build Security Champions: train developers in security coding, a force multiplier, reduce culture conflict, embed app security knowledge into team
• Keep Operational Visibility: application security continues, closed loop feedback, security incidents

SAST vs DAST

SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing)

Continuous Security:

Continuous Testing:

• Test Driven Security (TDS)
• Write tests that represent desired behavior
• Test will fail and that is expected. 
• Implement controls to pass TDS tests
• Security teams help developers and IT operation teams  to implement controls

Security Architecture and Design Review

• Product Requirements
• Early Designs
• Add security based on threat models
• Architecture is reviewed
• Security controls proposed

Security Code Review:

• Review code
• Verify security controls
• Verify architecture requirements

Security testing

• Can the product withhold a simulated attack?
• Manual testing
• Automated tools

Monitoring and Key Performance Indicators

Logging Pipeline includes:
Collect->Stream->Analyze->Store->Access

Incident Management:
NIST 800-61

For Detection & Analysis

• Blended approach  to detection
• Business-focused Metrics
• Data-driven investigations

For Containment Eradication & Recovery

• Actionable alerts
• ChatOps for Communication
• Runbooks for remediation
• Adopt infrastructure as Code (IaC)

For Post-Incident Activity:

• Keep post-mortems actionable
• Analysis phase is worthless if little or no action is taken
• Lessons learned must be reflected in incident management runbook

KPI (Key Performance Indicators) based on business needs and compliance requirements

• Availability
• Change Failure
• Change Lead Time
• Change Volume
• Customer Issue Resolution Time
• Customer issue volume
• Defected Burn Rate
• Deployment Frequency
• Logging Availability
• Mean Time Between Failures (MTBF)
• Mean Time to Failure (MTTF)
• Mean Time to Recovery (MTTR)
• Number of False Positives
• Number of False Positive
• Number of Functional/Acceptance Tests
• Number of Passed /Failed Security Tests
• Number of unit/integration Tests
• Security Benchmark Deviation
• Security Controls
• Test Coverage
• Time to Patch
• Time to Value
• Vulnerability Patching Frequency
• Vulnerability Patching Lead Time

DevSecOps on Azure Kubernetes Service (AKS)

 

Process flow

DevSecOps lifecycle 

Security team

The security team is responsible for developing security standards and enforcing them. Some teams might be responsible for creating and selecting Azure Policy that's enforced in the subscriptions and resource groups holding the clusters. They monitor security issues, and together with the other teams, ensure that security is brought to the forefront of every step of the DevSecOps process.

References

• https://learn.microsoft.com/en-us/azure/architecture/guide/devsecops/devsecops-on-aks