DevSecCon Tel Aviv 2018 - End2End containers SSDLC by Vitaly Davidoff

1. Join the conversation #DevSecCon
BY VITALY DAVIDOFF
End2End Containers Secure SDLC

2. $WhoAmI
• Application Security Architect
• 15 years of experience as a developer
• 5+ years experience in application security
• Martial arts instructor and musician

3. • Global software company since 1976
• More than 10,000 employees
• Application Delivery Management and IT
Operations Management tools
• Micro Focus is the first to achieve both ISO
27001 & ISO 27034 security certification
Micro Focus

4. • Introduction and brief overview of SDLC and Containers
• Challenges when moving from regular Apps to containers
• Security through SDLC phases
• Summary
• Q&A
Main Topics

5. SDLC and Waterfall model
• SDLC is a formal process to produce a high-
quality software
• Waterfall model
 Release time is big
 No mid changes allowed
 Good for security

6. Agile model
• Iterative model
• Short release time
• Based on user feedback
• Security?

7. AppSec on DevOps

8. • What containers are?
 Container is primarily focused on providing a
portable, reusable, and automatable way to
package and run apps.
 Container ≠ Virtual Machine
 Container ≠ Application
 Container = A Combination Of Technologies
Containers… what?

9. • Benefits
 Portable
 Fast
 Run Anywhere
 Platform for “micro services”
• Security
 Small attack surface
 Better access control
 Monitoring and change management
 Useful as a security tools
Containers… why?

10. • Classical vs New AppSec point of view
 OWASP TOP 10 vs Multilayer security
 Unclear borders
• Challenges of containers based architecture
 Security considerations for containers technologies
 Security for containers lifecycle
Challenges when moving to containers

11. • Gap in technologies
 Absence of complete security solution
• Mixed Responsibilities
 Addition responsibilities for developers
 Security expectation from R&D
Challenges when moving to containers (Cont.)

12. • Security awareness
• Knowledge sharing
• Security Champions
 Technical focal point
 Security driven
 Code referee
Security Collaboration

13. Security Lifecycle Management (SLM)
Secure coding
SDL for managers
Security QA
Security for designers
& champions
Secure coding
Basic security QA
Automatic Security Tools
Security documentation
Security Risk Assessment
Comprehensive security testing
Mitigation strategies
Root cause analysis
Final security review
Release Sign-off
Responsible disclosure
Security intelligence
Vulnerability analysis
Security updates & patches
Design guidelines
Design review
Threat Modeling
Attack surface
Analysis/ASA
Initial threat assessment
Security Plan
Security Release Criteria
Compliance requirements
Design Implement
Verify
Deployment
Education
Requirements
& planning
Release Response

14. “Engage security early and often and be sure to have it included in
your definition of done” (Laura Bell)
• Be part of Kickoff meeting
• Technologies evaluation
• Define security standards for containers
“Requirements” Phase: what changed for containers

15. • Secure Design Review
• Create hardening guidelines
• Security best practices when building your container-based system
Ship Deploy Run DestroyBuildPlan
“Design” Phase: what changed for containers

16. • Plan and review the data types managed by the container
• Access level for the container (both in/out)
• Segmentation – the container sensitivity and relevant grouping
• Compliancy requirements
• Applicable scanning tools
• Applicable monitoring tools
• Retention policy
• Incident response strategy ( logs, events, metrics required for
forensic research) etc.
Ship Deploy Run DestroyBuildPlan

17. Ship Deploy Run DestroyBuildPlan
• Provide security best practices for containers
• Enforce security standards
• Enforce the use of trusted or private container image
repositories
• Ensure developers are only using trusted images
• Use "secrets management" tools to protect most sensitive
data

18. Ship Deploy Run DestroyBuildPlan
• Sign every new container to ensure authenticity
• Ensure all relevant scans performed before container signing:
 Application static code analysis
 Image scan for known CVEs on every layer
 Malware scan
 Configuration/hardening validation
• Image should be labeled according to organization convention:
 Version
 Purpose

19. Ship Deploy Run DestroyBuildPlan
• Configure network segmentation to create security layers between
containers
• Harden the host OS
• Enforce namespace permissions to isolate resources
• Restrict paths of inbound and outbound network connections at the
host and cluster level
• Grant only administrator roles the ability to change or remove
containers

20. Ship Deploy Run DestroyBuildPlan
• Use only trusted images and repositories
 Verify signatures to make sure that container what's been
developed and approved is the same as what's been
deployed and run in production
• Monitor container operations to perform proper intrusion
detection
• Prevent privilege escalation attempts in real time on the
network, the host OS, and each container

21. Ship Deploy Run DestroyBuildPlan
• Change management process should be in place.
• Ensure appropriate mechanisms are in place to satisfy their
data retention policies.
• Clean-up of irrelevant images/containers
 Secure destroy container/image including
dependencies/external connections/cleanup storages
securely
• Define and restrict compromised containers strategy.

22. • What is Threat Modeling
• Differences when conducting Threat Modeling
for micro-services applications
• Component based vs Flow based
Threat Modeling

23. Classical Threat Modeling Flow

24. Threat Modeling for containers

25. • TOP 5 Security concerns for R&D
 Usage of root or high-privileged user and permissions (privilege
escalation)
 Insecure storage of sensitive information
 Usage of vulnerable or unnecessary 3rd party packages and
tools
 Sensitive files and folders are world readable (least privilege
violation)
 Missing default security configuration (Insecure configuration)
• Static code analysis for code and for containers!
• Involve “Security Champions”
“Development” Phase

26. Weighted
Risk Analysis
Dynamic
Scan
3rd Party
Scan
Infrastructure
Scan
Static
Analysis
Automatic, continuous, software security testing in agile development lifecycle, with
integration into existing DevOps environments
“Test”: Implementing comprehensive test approach

27. • Images signing and validation
• Upgrades and patch policy
• Security training for DevOps
• Hardening guides for platform
• Monitoring and Intrusion detection systems
“Operation” Phase: what changed for containers
Notary’s client-server-signer architecture (Source)

28. Requirements
• Technology and
frameworks validation
• Security Champions
Design
• Best Practices
• Hardening guidelines
• Design Review
• Threat Modeling
Implement
• Secure coding
• Static code analysis
• TOP 5
Test
• Static test
• Dynamic Test
• Penetration Test
Release
• Images validation
• Patches automation
• Monitoring
Summary

29. Join the conversation #DevSecCon
Thank You
vitaly.davidoff@microfocus.com
LinkedIn: https://www.linkedin.com/in/vitaly-davidoff-07039a1