Slide 1

Slide 1 text

AppSec, Risk, Compliance Convergence Tony UcedaVelez CEO, VerSprite CSX North American Conference, October 2015

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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) alert(“Cookie”+ document.cookie) 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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 Security Convergence is Overdue

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

10 Security Convergence : Incentive #1 via Risk Based Threat Modeling

Slide 11

Slide 11 text

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)

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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:

Slide 16

Slide 16 text

Overlapping Domains Source: Risk Centric Threat Modeling, UcedaVelez, Morana 2015, Chapter V, Threat Modeling & Risk Management ,Wiley

Slide 17

Slide 17 text

17 Threat Analysis : Incentive #2 Doing more with Less via Threat Analysis

Slide 18

Slide 18 text

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?

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

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 .

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

Attack Tress Attack Tree. Helpful diagram of relationship amongst asset- actor-use case- abuse case- vuln-exploit- countermeasur e

Slide 27

Slide 27 text

27 Threat Analysis : Incentive #3 Secure What’s Most Likely & Do It Earlier

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

Use Case Use Case. Functional, as designed function of an application.

Slide 31

Slide 31 text

Abuse Case Abuse Case. Deliberate abuse of functional use cases in order to yield unintended results

Slide 32

Slide 32 text

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)

Slide 33

Slide 33 text

33 Methodology Breakdown

Slide 34

Slide 34 text

Stage 1 – Understand Biz Objectives behind Security, Compliance

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Stage 2 Walkthrough – Define Tech Scope

Slide 39

Slide 39 text

39 The Application Architecture Scope

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Stage 3– App Decomposition

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Know Thy Use Cases 43

Slide 44

Slide 44 text

Stage 4 Threat Intelligence/ Analysis

Slide 45

Slide 45 text

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*

Slide 46

Slide 46 text

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?

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Stage 5 Walkthrough – Vuln Analysis

Slide 49

Slide 49 text

SecOps Convergence of Vulnerability Mgt.

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Stage 6 Walkthrough – Attack Enumeration

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Attack Vectors Used By Different Types of Malware

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Stage 7– Residual Risk Analysis

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Q U E S T I O N S A N S W E R S [email protected] @t0nyuv @VerSprite