Operationalizing Security Controls: Getting Your Security Program to Shift Left

This presentation will focus on how DevSecOps efforts are changing how we govern security controls via greater automation tools that are readily available to leverage. In addition, this presentation will show how the future can support for more cost effective governance models, regardless of industry or size of IT environment.

Transcript

1. Operationalizing Security Controls Getting Your Security Program to Shift Left
2. Tony UcedaVélez CEO & Founder | VerSprite – Global Security Firm (www.versprite.com) OWASP Atlanta Chapter Leader (past 10 years) Author, “Risk Centric Threat Modeling – Process for Attack Simulation & Threat Analysis”, Wiley June 2015 • Passionate global, threat modeling evangelist • ~25 years of diverse IT/ Security experience in software development, architecture, pen testing, threat modeling, sys admin, security operations • Dreams of bankrupting #infosec with intelligent, threat inspired DevSecOps automation • Twitter: @t0nyuv • Linkedin: www.linkedin.com/tonyuv • Email: tonyuv@versprite.com
3. Beyond the Theoretical DevSecOps Beyond the Whiteboard
4. What’s Said… • Usually led by overzealous technologist(s) • Multiple technologies downloaded • Limited in-house expertise • Automation utopias promised • 80% cost saving projections
5. vs. What Actually Happens • Orphaned technologies • Unmaintained repos, VMs, containers, VPCs, etc. • Account sprawl across environments • Lost time, money & credibility
6. What are we solving via DevSecOps? • Reducing security control gaps across the stack • Reducing time associated w/ manual configurations • Improving recovery efforts for security incidents • Accelerating common security abuse case testing • Increasing security assurance levels per environment • Assurance vs. Patch Management approaches • Building security requirements into products & platforms • Moving security ‘left’ of implementation SDLC stages • Eliminating vulnerabilities in deployment pipeline • Operationalizing governance Traditional IT Activities Alleviated w/ Automation
7. Planning the Shift DevSecOps Beyond the Whiteboard
8. Goals of Shifting Left • Ensure that lower Dev environments receive security configurations; not just Prod • Helps reduce environmental discrepancies around security, privacy, and other control factors • Shifting Left can also related to introducing security earlier in a software development lifecycle • Goals are to operationalize or automate security efforts via code and Continuous Integration & Continuous Delivery
9. Layers of Need • Assurance • Certifying Platforms & Overall Environments • Validating 3rd party libraries • Governance & Compliance • Building security controls in • Alignment to regulatory requirements • Agile Security Testing • Testing use cases faster, fixing faster Speed, Accuracy, & Assurance – Tomorrow’s New Security Paradigm
10. DevSecOps Landscape
11. Building an AppSec Pipeline • An AppSec pipeline integrates activities like SAST, DAST as part of process to test, validate, fix and deploy • OWASP has a sample pipeline schematic denoting where integrated testing can occur (see right) • Tools such as OWASP Glue are interesting and still supported to help security efforts in CI/ CD • Ruby Gems project that is fairly well maintained. • Similar to StackStorm in the sense you are also automating AppSec pipeline • https://www.owasp.org/index.php/O WASP_Glue_Tool_Project
12. Planning DevSecOps Defining Goals & Leveraging Threat Modeling to Implement DevSecOps Activities
13. Threat Models as Blueprints • Threat Modeling not just a point in time activity • Application Threat models provide blueprint for S-SDLC activities • PASTA as a Risk Centric Approach • Full stack • Threat integration • Exploit testing automation • Building Security-In • Building Compliance-In • Provides a collaborative approach to make DevSecOps a planned success vs. ad hoc wish. Source: RSA 2018, CERT, Hasan Yasar Mapping Automation Opportunities into the DSc
14. 14 APPLICATION THREAT MODELING ACTIVITIES per STAGE MGT PMO BA ARC SWE QA SYS SOC RL PC SA EA CTO VA PT STAGE 1 - DEFINE BUSINESS OBJECTIVES - Est. New TM = 2-4 hours | Est. Repeat TM = < 1 hour A R R A I I I − I R I I R − − M GT Product M gmt Obtain business objectives for product or application A I R A I I I − I − − I I − − P M O Project M gmt Identify regulatory compliance obligations A I I A I I I − I R − I I − − B A Business Analyst Define a risk profile or business criticality level for the application A I I A I I I − I C I I R − − A R C Architect Identify the key business use cases for the application/product A R R A I I I − I − − I I − − SWE Software Engineer STAGE 2 - TECHNICAL SCOPE - Est. New TM = 3-4 hours | Est. Repeat TM = 1-3 hours I I C A R/A C I − I − I C I − − QA Quality Assurance Enumerate software applications/database in support of product/application I I C A R/A C I − − − − C I − − SYS SysAdmin Identify any client-side technologies (Flash, DHTML5, etc.) I I C A R/A C I − − − I C I − − SOC Security Operations Enumerate system platforms that support product/application I I C A R/A C I − − − I C I − − R L IT Risk Leader Identify all application/product actors I I C A R/A C I − − − I C I − − P C Product Compliance Enumerate services needed for application/product use & management I I C A R/A C I − − − I C I − − SA Software Assurance Enumerate 3rd party COTS needed for solution I I C A R/A C I − − − I C I − − EA Enterprise Architect Identify 3rd party infrastructures, cloud solutions, hosted networks, mobile devices I I C A R/A C I − I − I C I − − C T O Administration STAGE 3 - APPLICATION DECOMPOSITION - Est. New TM = 8 hours | Est. Repeat TM = 4 hours I I I A R C C − I − − C − − − VA Vuln Assessor Perform data flow diagram of application environment I I I A R I C − − − − C − − − P T Pen Tester Define application trust boundaries/trust models I I I A R C C − − − − C − − − Enumerate application actors I I I A R C C − − − − C − − − C o rpo rate F unctio ns Identify any stored procedures/batch processing I I I A R C C − − − − C − − − Office of the CTO Enumerate all application use cases (ex: login, account update, delete users, etc.) I I I A R C C − − − − C − − − Compliance STAGE 4 - THREAT ANALYSIS - Est. New TM = 6 hours | Est. Repeat TM = 2 hours I I R/A A R/A R/A C C − − − I − − − Security (ISRM ) Gather/correlate relevant threat intel from internal/external threat groups I I R/A A C I C C − − − I − − − Review recent log data around application environment for heightened security alerts − − I A R R/A I C − − − I − − − Gather audit reports around access control violations − I I A R C I C − − − I − − − R Responsible Identify probable threat motives, attack vectors & misuse cases I I I A R/A C I C − − − I − − − A Accountable STAGE 5 - VULNERABILITY ASSESSMENT - Est. New TM = 12 hours | Est. Repeat TM = 6 hours I I I A R C I C I − − C − R/A R C Consulted (2 way) Conduct targeted vulnerability scans based upon threat analysis − − − A R C I C I − − I − R R I Informed (1 way) Identify weak design patterns in architecture − − − A R C I − − − − C − R C Review/correlate existing vulnerability data I I I A R I I C − − − I − R/A I Map vulnerabilities to attack tree − I I A R I I − − − − C − C I STAGE 6 - ATTACK ENUMERATION - Est. New TM = 10 hours | Est. Repeat TM = 5 hours I I I A R R − − I − − C I I R/A Enumerate all inherent and targeted attacks for product/application I I I A R C − − I − − C I I R/A Map attack patterns to attack tree vulnerability branches (attack tree finalization) − − − A R C − − I − − C − I A Conduct targeted attacks to determine probability level of attack patterns − − − A C R − − I − − C − I R/A Reform threat analysis based upon exploitation results I I I A R C − − I − − C I I C STAGE 7 - RESIDUAL RISK ANALYSIS - Est. New & Repeat TM = 5 days (inc. countermeasure dev.) C I I A R C C C I I C C I I R Review application/product risk analysis based upon completed threat analysis I I I A R C I C I I C C I I R List recommended countermeasures for residual risk reduction I I I A R C C C I I C C I I R Re-evaluate overall application risk profile and report. C I I A R C I I I C C C I I I BU/Product Groups Corporate Functions R o les Legend R A C I Legend 3rd Party
15. PASTA Threat Modeling Methodology 1. Define Business Objectives Revenue Compliance (Data Security) Market growth Operational goals Privacy (Data Use, Retention) 2. Technology Enumeration List server side tech List client side tech List 3rd party technology List frameworks List infrastructure layer tech 3. Application Decomposition Map out internal/ external APIs Identify calls to data repositories Identify actors Identify data flows Enumerate protocols 4. Threat Analysis Identify threat actors, motives Threat Data Threat Intel Threat Tabletops 5. Vuln Analysis Identify system vulnerabilities Identify software/ architecture weaknesses Identify Process Gaps 6. Attack Modeling Identify Abuse Cases Build Attack Trees Exploit vulnerabilities Probabilistic Analysis 7. Residual Risk Analysis Correlate tech risk to biz risk Identify business impact Develop countermeasures Incorporate Security Earlier in the SDLC Process Defining Security Requirements • Controls from framework • Regulatory requirements • Implement at env build-out • App, System, and Network Level • PASTA extend beyond app tier Know Your Attack Surface • Enum 3rd party libs • Diff open ports to security baseline • Identify & harden web frameworks • Know what supports key use cases • Baseline your level of segregation Threat Integration Sources • Oppty to test network/ sys env earlier • Threat feeds to attack surface checks • From Alerting to Checking(e.g.. - StackStorm) • Privacy threats based upon DLP checks • STRIDE is static, threats are not Vuln & Weakness Testing • OnDemand Vuln Scans to certify env • Automate Patching against CVEs found • Instrument DAST testing post code releases • Identify app weaknesses at code level w/ SAST • Funnels to Ticket Queues or Auto-Remediation
16. Planning Automation • STAGE 1 can define pre-emptive mitigation strategies via hardening, control adherence • STAGE 2 identifies risks stemming from vuln components from attack surface • STAGE 3 understand security context of callers in application architecture. • STAGE 4 can identify threats that can be addressed earlier in SDLC • STAGE 5 & 6 can audit code, app configs, & app responses • STAGE 7 identifies residual risks & determines pass/fail criteria for app acceptance Source: RSA 2018, CERT, Hasan Yasar All Phases are Left of SDLC Deployment Phases Stage 1 Stage 2 Stage 7 Stage 5 ,6 Stage 4 Stage 3
17. Automation Cases Configuration, Audit, and Implementation Use Cases
18. Automation Feature: StackStorm • Platform for integration and automation across services and tools • Allows you to take actions in response to events • Server-agent architecture • Define your own ‘Triggers’ • Open source, Apache 2.0 licensed • Primarily targeted towards DevOps It's all code! (and some YAML) • Orchestrates info from security tools • Orchestration logging/ alerting (Sensu) • Infrastructure monitoring(Nagios)
19. Remediation Workflows – Information Collection • Retrieve logged users (actor inventory, security context) • Retrieve open files • Retrieve listening ports (security hardening objectives) • Retrieve established connections (PASTA Stage 3) • Retrieve running processes (baseline configurations, NIST CM) • Retrieve file hashes (data integrity) • Retrieve logs from /var/log/* (logging, auditing) • Upload information to Rackspace CloudFiles (archiving)
20. Operationalizing Governance • 12.3 Use cryptographic controls to protect your information • There are multiple ways to ‘comply’ with a control • Automate checks with Puppet, Chef, Ansible, Vagrant, Terraform • Checks can sometimes run natively on native platforms Auditor GRC 3rd Party Audits NetSec SysSec DB Sec AppSec (subjective control presence) (subjective control presence) (subjective control presence) Ex: CA Signing, encryption algorithm Ex: Disk encryption status Ex: Field vs. Table Encryption Ex: employing proper TLS levels for in- transit Mapping Automation Opportunities into the SDLC
21. 12.3 Use Cryptographic Controls … • Automatically issue TLS certs • Vault feature can be used to automate TLS certs to TLS clients & servers • Validate TLS presence • Provide assurance to client-server environments across desired environments • PROD|STAGE|UAT|QA|TEST • Terraform scripts interface w/ Vault to generate CSR, issue certs • Chef, Puppet, Ansible all have similar variants for secret/ key management NetSec Control Implementation Example Using Vault Provider
22. 12.3 Use Cryptographic Controls … • Simple powershell script can be checked into any config management tool • Can be run as a service account • Can be run when configuring VMs for any environment • Provides assurance to encrypted file systems • Output can be stored automatically via interfaces to Sharepoint, Confluence, GRC platforms SysSec Control Validation Example Using Native Capabilities
23. 12.6 Establish Technical Vulnerability Management • Integrating SAST via automation tools like OWASP Glue • Linting or static code analysis can be carried out by various tools • Bandit is one for Python • Automatic linting for Python can be automated via tools like OWASP Glue • Targets can include: file systems, git repos, dockerfiles, iso files, etc.) • Series of tasks that can be defined • Bandit task for SAST on python codebase • DAST tasks can be defined w/ ZAP • ruby bin/glue -t zap --zap-host http://localhost --zap-port 1234 –z p-passive-mode http://juice- shop -z • TeamCity Integration Example • ruby bin/glue -t zap --zap-host http://localhost --zap-port 1234 --zap-passive-mode http://juice-shop -f teamcity
24. 11.2.2 Control the Management of System Privileges • Another ISO Control Implementation (ISO 27002 11.2 Domain) • Ensuring the security context of actors running 3rd party software or internal software is not elevated • Chef automation scripts can validate Apache web server environments that are in scope • Multiple baselines exist and can be code as checks using Ansible, Chef, Puppet • Great resource: https://dev- sec.io/baselines/apache/
25. Moving Foward Resources & Practical Advice
26. Did you know? • Security product vendors want to have customers that use their products. • DevSecOps can leverage many security, compliance products today; find the ones that work. • DevSecOps can increase TCO for current solutions and help create workflows via integration
27. Leveraging PASTA to Encompass Goals & Scope 1. Define Goals: Compliance? Improved Security Posture? Security Cost Reduction? IP Preservation 1. Regulatory landscape for application(s) 2. Identify Attack Surface 1. This will be the object of DevSecOps automation 3. Understand Flows via App Decomposition 1. Static API Calls, 2. SAST/ DAST reports 3. Actors & their Security Context 4. Threat Analysis 1. Harvest alerts that feed triggers on OWASP Glue, StackStorm 5. Vuln/ Weakness Detection 1. Go beyond the AppStack (concern for integrated dependencies) 2. CVE, CWE to CAPEC mapping 6. Attack Modeling 1. Automated & Integrated SAST / DAST 2. Queuing for manual exploits (vFEED) 7. Residual Risk | Countermeasure Development 1. Getting to remediation quicker 2. Eliminating time spent on FPs ISO Controls for Automation 12.4 - Protect Source Code 11.4.2 Auth remote user connections 13.1.2 – DAST Automation via Jenkins & Zed Attack Proxy 12.1.1 Identify InfoSec requirements
28. Cloud Security Auditing • Low-touch high-value assessments for your Cloud environment ideal for baseline, testing and monitoring remediation. • Utilize control guidance defined by CSA 3.1, CIS benchmarks, Microsoft and Amazon. • Automated checks continually evolving; Combination of VerSprite developed, CSP provided, and Open Source tooling • Key areas covered: • Public attack surface • Identity & Access Management • Networking • Virtual Compute (VM) • Application Containers • Storage • Database • Logging and Alerting • Security Center (Azure) • Security Hub/GuardDuty (AWS) Assessment and Remediation
29. Cloud Security Auditing • Focus coverage of HIPAA/HITECH, ISO 27001, FedRAMP. • Cloud controls (automated checks) mapped directly to compliance control domains. • Example mappings: • CIS Benchmarks for AWS 1.1-1.16 (IAM) => ISO 27001 control domain 9.x • CIS Benchmarks for Azure 5.1- 5.13 (Logs) => HIPAA 164.308 • Data encryption (S3, Database) => FedRAMP SC-13 Control Domains and Compliance • Monthly audit drives evidence collection supporting audits for baseline and deltas. • Integrate control results into Azure Security Center and AWS Security Hub (in preview) for central dashboard.
30. Thank you. tonyuv@versprite.com https://www.linkedin.com/in/tonyuv/ @t0nyuv