AppSec, Risk, Compliance Convergence

CSX North America Conference, October 2015 discusses how risk centric threat modeling can help unify disparate security efforts across Application Security, Risk Management, and Regulatory Compliance drivers.

Transcript

1. AppSec, Risk, Compliance Convergence Tony UcedaVelez CEO, VerSprite CSX North American Conference, October 2015
2. 2  Tony UcedaVélez (“Tony UV”)  CEO, VerSprite Security  Chapter Leader – OWASP Atlanta  Author, “Risk Centric Threat Modeling – Process for Attack Simulation & Threat Analysis”  Follow me @t0nyuv Speaker Bio
3. 3 3 Users Request Responses DMZ (User/Web Server Boundary) Message Call Account/ Transaction Query Calls Web Server Application Server Application Calls Encryption + Authentication Encryption + Authentication Financial Server Authentication Data Restricted Network (App & DB Server/Financial Server Boundary) Database Server Application Responses Financial Data Auth Data Message Response SQL Query Call Customer Financial Data Internal (Web Server/ App & DB Server Boundary) <SCRIPT>alert(“Cookie”+ document.cookie)</SCRIPT > Injection flaws CSRF, Insecure Direct Obj. Ref, Insecure Remote File Inclusion ESAPI/ ISAPI Filter Custom errors OR ‘1’=’1—‘, Prepared Statements/ Parameterized Queries, Store Procedures ESAPI Filtering, Server RBAC Form Tokenization XSS, SQL Injection, Information Disclosure Via errors Broken Authentication, Connection DB PWD in clear Hashed/ Salted Pwds in Storage and Transit Trusted Server To Server Authentication, SSO Trusted Authentication, Federation, Mutual Authentication Broken Authentication/ Impersonation, Lack of Synch Session Logout Encrypt Confidential PII in Storage/Transit Insecure Crypto Storage Insecure Crypto Storage "../../../../etc/passwd %00" Cmd=%3B+mkdir+ha ckerDirectory http://www.abc.com? RoleID Phishing, Privacy Violations, Financial Loss Identity Theft System Compromise, Data Alteration, Destruction
4. Focus on the application as business- asset target Risk !=t * v * i Risk! = t * v * i * p Attack simulation enhances (p) probability coefficients Considers both inherent countermeasures & those to be developed Focused on minimizing risks to applications and associated impacts to business The PASTA™ Risk Recipe Rrisk =[(tp * vp )/c] * i
5. 5 Security Convergence is Overdue
6. Security Island Analogy - Isolation Islands of Security Disjointed AppSec, Risk Mgt, Compliance • Isolated groups w/ little to no process integration • Deliverables are rarely shared – Risk assessments – Compliance audits – Dynamic analysis, web application assessments
7. Security Island = Isolation  Compliance  After years, still ‘checkbox’ driven  Time consuming  Never integrate to other *Sec efforts  Risk Management  Framework driven  Frameworks are for benchmarking, not risk analysis  Results in a binary exercise (basic level)  AppSec  Many AppSec programs don’t even exist  Those that do, test post implementation  Few integrate into the SDLC  OpSec  Risks don’t factor into threat Intel  Signatures run your security monitoring
8. False Sense of Workflow Across Security Islands •Pen Testing •Static Analysis •Dynamic Analysis •Vuln assessments •Multiple Tools (CMMI 1-2) AppSec Workflows •PCI-DSS Audits •Yearly HIPAA Assessments •SOX Readiness Assessments/Audits •Spreadsheet Mayhem (CMMI 1-2) Compliance Workflow •Social Engineering* •Enterprise Risk Assessment •Spreadsheet Mayhem (CMMI 1-2) •GRC Tool (CMMI 2-3) Security Risk Management  Informally, belief has been that some form of knowledge sharing could be done AFTER each group finished a given project  Realistically, little to no time for integration  Competing objectives, resource limitations have all affected ability to collaborate  If collaboration is present, more adhoc and not a linear workflow
9. Security Island Analogy - Unification Natural Joining of Two Islands Natural Alignment of Overlapping Objectives Risk Management • Risk reduction • Achieve acceptable risk Compliance • Meet regulatory requirements • Manage compliance gaps AppSec • Tech testing • Software Assurance Volcanic activity begins to adjoin two islands in Pacific Control Gaps
10. 10 Security Convergence : Incentive #1 via Risk Based Threat Modeling
11. Visualizing Security Convergence Compliance & Audit Vulnerability & Risk Management Application Vulnerability Assessments Attack Analysis Cybercrime Intelligence Architectural Risk Analysis Risk Based Testing Risk and Business Impact Analysis Security Incidents & Fraud Reporting Threat Analysis Threat Intelligence Domains (unknown threats) Traditional Security Domains (Security controls no threats) Application Risk Domains (known threats and risks)
12. Definition/Requirements Design Construction Implementation Post-Impl Validation High Level IS Risk Analysis of Business Concept Information Security Risk Analysis IS Test Cases Defined IS Functional Test IS Readiness Review IS Lessons Learned SIRT Root Cause Reviews Mandatory Inputs Process Detailed Design Documents & Standard Format IS Testing & Validation Update Threat Model Project Charter/ Change Information Interviews and Brainstorm SRS/Regulatory Req/ Internal Standards Use-Cases Security Requirements Engineering Optional Input IS Test Cases/Scripts Security Requirements IS Test Cases Process New Threat Modeling Ex. Based on Incidents, new research, etc Attack Trees Output Security Implementation Guidelines Update Security Arch Business Requirements Threat Modeling Security Architecture Process IS Design Review Convergence & Operationalizing in SDLC Compliance Audits Risk Assessments Compliance Reporting Missed Convergence Compliance requirements considered Inherent risk profiling based upon: tech, data, architecture, 3rd parties Risk profiles can substantiate threat claims. Compliance requirements can serve as pre-emptive mitigating controls.
13. How Convergence via Threat Modeling Works  Compliance  Privacy requirements become addressed as part of project life cycle or SDLC  Data type (e.g. – PHI, MassPrivacy, EU Privacy Directive)  Data usage rights  Compliance requirements equally become addressed in Definition stage of SDLC  PCI-DSS, HIPAA/HITECH, NERC CIP, FedRAMP, FISMA  Risk Management  Address risk issues early in the SDLC (address the risk profile early)  Outstanding risk issues around network/ application architecture, 3rd party software, lack of controls  Results in a binary exercise (basic level) or maturity modeling driven (intermediate level)  Security (AppSec, NetSec, etc.)  Many existing vulnerabilities in remediation queues can be reviewed, correlated, and addressed.  Inventoried weaknesses, vulns substantiate presence; pen test results substantiate viability  Converging Security, Compliance, and Risk management objectives with threat modeling catalyzes remediation
14. Otherwise….  How will risk assessment efforts become integrated to compliance?  What about with security testing (AppSec, NetSec, Static Analysis, Mobile Testing, Dynamic Testing?  How does compliance mitigate threats?  Is your compliance factoring in threat intelligence? Harvesting threat data?  What cross-functional efforts will help Risk and Compliance professionals elevate their low technology acumen?  Stigma around Risk and Compliance professionals around technology proficiency  Not just a J2EE, .NET, and RACF world out there anymore  Emerging technologies are less self-sustaining and more integrated than ever.
15. Risk Based Application Threat Modeling Benefits  Risk analysis driven: analyze a threat’s likelihood and technical and business impacts to identify countermeasures for risk mitigation;  Threat focused: Looking first at cyber threat mitigation as a business problem, integrate threat information (e.g. – external provided services) and threat data (e.g. – SecOps log information)  Attack modeling centered: conceptualize likely attacks based upon motives and identified attack vectors, building from threats  SDLC Integrated: leverage security risk and governance and application security processes  Collaboration among stakeholders (compliance officials, risk assessors, architects, security practitioners, 3rd party security firms) is inherent to the process:
16. Overlapping Domains Source: Risk Centric Threat Modeling, UcedaVelez, Morana 2015, Chapter V, Threat Modeling & Risk Management ,Wiley
17. 17 Threat Analysis : Incentive #2 Doing more with Less via Threat Analysis
18. What Threat Are You Protecting Against?  Do you know who may attack you?  Do you know why they may attack you?  Do you know what evidence support your threat claims?  Why Not?
19. Threat Modeling’s Threat Analysis Threat Dissection Targeted Analysis • Focused on understanding targeted threats • Focus on attacks that are supported via viable threat patterns • Threat motives may be data (e.g. - PII, IP) focused, disruption based (hacktivism), IP
20. Threat Threat. A threat is an undesired event. A potential occurrence, often best described as causal factors that may manifest into attacks that compromise an asset or objective. Relative to each site, industry, company; more difficult to uniformly define.
21. Attack Attack. An attack is an exploit taken that utilizes one or more vulnerabilities to realize a threat. Attacks influence risk in the compliance and risk management context.
22. Asset Asset. An asset is a resource of value. It varies by perspective. To your business, an asset might be the availability of information, or the information itself, such as customer data. It might be intangible, such as your company's reputation because it affects assets used to .
23. Compliance mitigate Threats/ Attacks? (via Risk Based Threat Modeling)  PCI-DSS  Protect stored cardholder data  Encrypt transmission of cardholder data  HIPAA  Must protect ePHI from being altered or destroyed improperly  Decryption tools should be stored in a separate location from the data  NERC CIP (via Critical Controls)  Critical Control 16: Account Monitoring and Control  Critical Control 16: Account Monitoring and Control  Provides the ability to factor in pre-emptive controls to application environments and networks  Compliance requirements, (although vague) can help to factor in pre-emptive controls into SDLC’s Definition or Design phase  These pre-emptive controls can provide defense in depth controls against identified threats/ attacks Examples Compliance Implications
24. Threats & Attacks Influence on Risk Management Risk Management  Needs to substantiate risks  No one believes your risk scores  Substantiate vulnerable findings w/ threat modeling  S3 - app decomposition  S4 - threat analysis  S5 - vuln detection  S6 - exploitation  Giving ‘meaning’ to risks Attack Tree B2B Portal (Asset) (I) Low Impact Asset Value (Target) Benign data set, small data scope (V) SQLi found on portal via tech app assessment (Target)) Admin hash compromised Network Asset in DMZ (V) Exposed hash of admin password Impact High
25. Vulnerability (Weakness) Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an exploit possible. Vulnerabilities can exist at the network, host, or application levels and include operational practices.
26. Attack Tress Attack Tree. Helpful diagram of relationship amongst asset- actor-use case- abuse case- vuln-exploit- countermeasur e
27. 27 Threat Analysis : Incentive #3 Secure What’s Most Likely & Do It Earlier
28. Impact Impact. Value of [financial] damage possibly sustained via attack. Is relative to each organization so these studies need to be calibrated to each org.
29. Countermeasures Countermeasure . Countermeasur es address vulnerabilities to reduce the probability of attacks or the impacts of threats. They do not directly address threats; instead, they address the factors that define the threats.
30. Use Case Use Case. Functional, as designed function of an application.
31. Abuse Case Abuse Case. Deliberate abuse of functional use cases in order to yield unintended results
32. What is PASTA? What is PASTA? A True Methodology  Process for Attack Simulation & Threat Analysis – Risk centric threat modeling methodology – Collaborative – Differentiators: Business Impact, Threat Intel, Residual Risk Analysis  Aimed at addressing most viable threats & building security in  Correlates to Identify, Protect, & Detect stages of NIST CSF Risk/ Impact Analysis (PROTECT) Attack Enumeration (IDENTIFY|DETECT) Vuln Detection (IDENTIFY|DETECT) Threat Analysis (IDENTIFY|DETECT) App Decomposition (IDENTIFY|PROTECT) Define Tech Scope (IDENTIFY|PROTECT) Define Biz Objectives (IDENTIFY|PROTECT)
33. 33 Methodology Breakdown
34. Stage 1 – Understand Biz Objectives behind Security, Compliance
35. Baking in GRC • Serve as inherent countermeasures in the form of people, process, technology – Policies (for people) – Standards (for technology) • Prior risk assessments help build app risk profile – Historical RAs provide prior risk profile of app • Regulatory landscape taken into consideration, but not the driver – Key here is to not retrofit compliance; more costly • Web Related Example: – Tech: Using Nessus OWASP template to audit for PHP & ColdFusion hardening guidelines – OWASP Input Validation Cheat Sheets – CIS Web Technology Benchmarks
36. Converging Security into Requirements Project Business Objective Security and Compliance Requirement Perform an application risk assessment to analyze malware banking attacks Risk assessment need to assess risk from attacker perspective and identify on-line banking transactions targeted by the attacks Identify application controls and processes in place to mitigate the threat Conduct architecture risk analysis to identify the application security controls in place and the effectiveness of these controls. Review current scope for vulnerability and risk assessments. Comply with FACT Act of 2003 and FFIEC guidelines for authentication in the banking environment Develop a written program that identifies and detects the relevant warning signs – or “red flags” – of identity theft. Perform a risk assessment of online banking high risk transactions such as transfer of money and access of Sensitive Customer Information Analyze attacks and the targets that include data and high risk transactions Analyze attack vectors used for acquisition of customers’ PII, logging credentials and other sensitive information. Analyze attacks against user account modifications, financial transactions (e.g. wires, bill-pay), new account linkages Identify a Risk Mitigation Strategy That Includes Detective and Preventive Controls/Processes Include stakeholders from Intelligence, IS, Fraud/Risk, Legal, Business, Engineering/Architecture. Identify application countermeasures that include preventive, detective (e.g. monitoring) and compensating controls against malware-based banking Trojan attacks
37. Threat Modeling Stage 1 Artifact Application Profile: Online Banking Application General Description The online banking application allows customers to perform banking activities such as financial transactions over the internet. The type of transactions supported by the application includes bill payments, wires, funds transfers between customer’s own accounts and other bank institutions, account balance-inquires, transaction inquires, bank statements, new bank accounts loan and credit card applications. New online customers can register an online account using existing debit card, PIN and account information. Customers authenticate to the application using username and password and different types of Multi Factor Authentication (MFA) and Risk Based Authentication (RBA) Application Type Internet Facing Data Classification Public, Non Confidential, Sensitive and Confidential PII Inherent Risk HIGH (Infrastructure , Limited Trust Boundary, Platform Risks, Accessibility) High Risk Transactions YES User roles Visitor, customer, administrator, customer support representative Number of users 3 million registered customers
38. Stage 2 Walkthrough – Define Tech Scope
39. 39 The Application Architecture Scope
40. Technical Scope Definition Enumeration Exercise  Application components (Presentation| Application | Data)  Network topology  Protocol/Service Ports  Use case scenarios Pre-Emptive Risk Mitigation  Applied Governance  Compliance Considerations  Data Requirements  Privacy Requirements  Technical Standards  3rd Party Interfaces
41. Stage 3– App Decomposition
42. Data Flow Diagramming (DFD) On-line Banking Application Example 42 User/ Browser HTTPs Request HTTPs Responses DMZ (User/Web Server Boundary) Message XML/JMS Web Server Application Server Application Calls (.do) Messaging Bus Authentication Credential Store Restricted Network (App & DB Server/Financial Server Boundary) Application Responses Auth Data Service Message Response SQL Query Call/ JDBC Internal (Web Server/ App & DB Server Boundary) Financial Transaction Processing MainFrame Financial Transactions (ACH, wires external transfer) MFA RBA/ Fraud Detection XML/HTTPS XML/HTTPS
43. Know Thy Use Cases 43
44. Stage 4 Threat Intelligence/ Analysis
45. Threat Intelligence is Golden Brainstorm Your Threats  Start w/ your own people  Tabletops  Things that feed good intelligence  Prior assessments  3rd party vendor assessments  SIEM feeds, Syslog logs, etc  Security incident/ event reports  Security incident/ event reports  Threat Intel Subscription Common Threat Motives  IP Theft  Data Theft  CnC Proliferation  Ransomware/ IT Hostage  Hactivism*  Personal beliefs*
46. When Too Much Threat Intel is Ineffective to AppSec, Compliance, & Risk Mgt  Temper threat Intel ‘hype’ w/ some basic principles  Does the threat Intel support my threat model?  Does this threat Intel realize actionable & operational security efforts?  Does the Intel support my risk formula?
47. Tailored Threat Intel Stands Out  Supported by a threat model  Substantiates risk analysis  Fulfills spirit of compliance around monitoring  Allows for actionable OpSec measures to take place
48. Stage 5 Walkthrough – Vuln Analysis
49. SecOps Convergence of Vulnerability Mgt.
50. Linking Vuln Analysis to Threat Analysis Vulnerabilities/ Weaknesses  Server side vulns  Application flaws  Race conditions  Command Injection  DOM Flaws  Coding Flaws  Injection flaws  Session Hijacking  Poor Network Security Architecture Vulns/ Weaknesses to Threats  Defacement  FTP Brute Force attacks  iFrame Injection attacks  Defacement/ Server Takeover  CMS exploits to web application  PII theft  XSS  SQL Injection  Sabotage driven threats  Malware upload 50
51. Stage 6 Walkthrough – Attack Enumeration
52. Analysis Of Attacks Using Attack Trees 52 Fraudster Drive-by Download/ Malicious Ads Man In The Browser Phishing Email, FaceBook Social Engineering Upload Malware on Vulnerable Site Attack Victim’s Vulnerable Browser Steals Keystrokes with Key-logger Modifies UI Rendered By The Browser Phish User To Click Link With Malware Upload Banking Malware on Customer’s Pc Harvest Confidential Data/ Credentials From Victim Steal Digital Certificates For Authentication Sends Stolen Data to Fraudster’s Collection Server Money Transferred From Mule to Fraudster Use Stolen Banking Credentials/ Challenge C/Q Remote Access To Compromised PC Through Proxy Logs into Victim’s Online Bank Account Fraudster Perform Un- authorized Money Transfer to Mule Redirect Users To Malicious Sites Delete Cookies Forcing to Login To Steal Logins
53. Attack Vectors Used By Different Types of Malware
54. Analysis of Web App Use and Abuse Cases 54 User Fraudster Login With UserID password over SSL Includes Includes Enter Challenge Question (C/Q) to authenticate transaction Includes Threatens Enter One Time Password (OTP) to authenticate transaction Includes Capture C/Qs in transit and authenticate on behalf of user Threatens Key logger/From grabber captures keystrokes incl. credentials Includes Drops Banking Malware on victims/PC Includes Threatens Includes Communicate with fraudster C&C Includes Capture OTP on web channel and authenticate on behalf of the user Trust connection by IP and machine tagging/browser attributes Threatens Includes Includes Man In The Browser Injected HTML to capture C/Q Threatens Set IP with Proxy/MiTM to same IP gelocation of the victim Hijacks SessionIDs, Cookies, Machine Tagging Includes Threatens
55. Stage 7– Residual Risk Analysis
56. 56 Risk Determines Remediation • Unacceptable risks give way to countermeasure development • Develop countermeasures based upon the net risk of an application environment at multiple levels – Baseline configuration – Design and programmatic controls – 3rd party software/ COTS
57. SDLC Convergence  Risk centric threat model is able to address inherent risks  Pen Tests, Risk Assessments, Compliance Audits, etc  Business Risk Mitigation Key  GRC leaders inject compliance requirements during Define/Design phase  PMs, business analysts, business owners devise functional requirements (Definition Phase)  Architects speak to enterprise controls usage earlier (Design Phase)  Threat Intel (SOC/ NOC fed) > depict attack sequence in DFDs > introduce trust boundaries > consider countermeasures Define •Biz Objectives •Compliance Objectives • Level-set on Impact Design •Security Arch •Security Frameworks •Cloud APIs •Use of Micro-Services Develop •OWASP Top 10, Dev Guide •Factor in countermeasures based upon threats Test (QA) • ASVS (3rd Party Dev) • OWASP Testing Guide (Internal) 57 ^ ^ ^ T h r e a t M o d e l v v v
58. Q U E S T I O N S A N S W E R S tonyuv@versprite.com @t0nyuv @VerSprite