PASTA Threat Modeling - One Day Training

Walk thru of the Process for Attack Simulation on Risk Analysis at AppSec Cali 2015.

Transcript

1. Risk Centric Threat Modeling Training Process for Attack Simulation &Threat Analysis AppSec Cali 2015
2. Training Agenda   Intro & Primer on Threat Modeling Methods   Risk Centric Threat Modeling  Define Biz Obj  Enumerate Technology  Decompose Application  Enumerate Threats  Identify App Vulns  Model Attacks  Build Countermeasures based upon risk 2
3. Training Goals & Objectives   Begin with a broad coverage of existing approaches/ tools   Understand the value behind risk based threat modeling (PASTA)   Learn how to remediate based upon highest risk issues   Enhance risk analysis skills   Learn how to better understand your application in order to apply security countermeasures responsibly 3
4. Training Flow Concepts   • Conceptual   threat  modeling   background   Risk  Centric   Steps   • Focus  on  the   PASTA   framework   ac>vi>es  for   each  Stage.   Industry   Prac>cal   • Applying  steps  or   threat  modeling   ac>vi>es  to  an   industry  example  
5. Simple Threat Modeling Guidance   Scope is key  Too big will make threat modeling exercises less valuable  Too small will likely miss attacks vectors that go un- tested/reviewed   Collaboration amongst application stakeholders  Sys admins + Devs + BAs + DBAs + Architects   Follow a linear & iterative approach  Let activities in each stage build from one another  Trees are helpful to organize components in risk centric approach
6. THREAT MODELING PRIMER
7. Definition, Terms, Approaches Threat Modeling Potpourri 1/27 7
8. OWASP Definition
9. Microsoft Definition & Process Variations June  2003   May  2005   Threat  iden>fica>on   preserved  by  STRIDE     ‘Rate  the  Threats’  via   DREAD-­‐deprecated.     Impact  considered   (2005)     Some  redundancy   exists.    
10. Wikipedia - Hits & Misses
11. Threat Model & ‘Attack Models’
12. Process  by  which  threats  are  modeled  against  a  target’s   systems  integrated  components.  Aimed  at  iden8fying  viable   a;ack  pa;erns  against  each  component’s  use  case,  layered   technical  func8onali8es,  employed  data  types,  and  overall   architecture.     ! Different  focus  &  perspec>ve  can  be  achieved:   " SoXware  centric     " Suggested  for  places  that  only  make  soXware   " Risk/  Asset  centric   " Enterprises,  Most  ver>cals  where  ‘acceptable  risk’  term  is   used;  Suggested  Service  Providers  (SaaS,  IaaS,  PaaS)   " Security/A[acker  centric   " Suggested  for  nuclear  facili>es,  high  security  military  systems   " Context-­‐Aware  Threat  Modeling  (N.  A.  Malik,  M.  Y.  Javed  and  U.   Mahmud)  –  GE  Systems  SmartGrid  Commercial   Threat Modeling
13. Risk Centric Threat Modeling Securing Against ‘Most Likely’ & ‘Biggest Impact’ 1/27 13
14. 14 Inherency: Security Challenges in Security RM*   Risk Management is an After-Thought   Building Security-In is elusive concept   Developers/ Architects don’t Visualize Threats   Receive scan results from InfoSec   Remediation Happens Post Implementation   Risk Mitigation Strategy is based upon Scanner Scoring   HIGH, MED, LOW Syndrome   No true risk analysis fuels remediation strategy   Adversarial Relationship with Security (me vs. them)   No Risk Management w/o Remediation or Transferance
15. Risk  Analysis   Remedia>on   Reduced  Timeframes   Define  &  Design  SDLC   Phases   Pre-­‐emp>ve   ‘Us’  Mentality   Significance  of  Data   Exposure  of  App   Components   Factors  Business   Impact   Addresses  Probability   of  Threats   15 Solvency via Risk Centric Threat Modeling
16. Data  Flow   Diagramming   (DFDs)   Architectural   Elements   Applica>on   Technology   Enumera>on   Iden>fy   Target   Data   Sources   Applica>on   Components   A[ack  Tree   Development   Iden>fy   Weaknesses   &  Abuse   Cases   Infrastructure   Elements   Define  Use   Cases  &   Actors   Fundamental Threat Modeling Activities Evolving to a Risk Based Approach Apply  Tech   Governance   Integrate   Threat   Intelligence   Apply   Process   Governance   Inherent   Countermeasures   Probabilis>c   Analysis  for   A[acks   Ability  to   Map  to   Control   Frameworks /  Maturity   Models   Residual     Risk     Analysis   Review   impact  of   viable   threats   Enumerate/   Evaluate   Counter-­‐ measures    
17. Synopsis on Risk Based Approach Risk Objectives 1.  Intended as a methodology to reduce risk on areas of application security that have the biggest impact. 2.  Fosters secure design and inherent control inclusion earlier in the SDLC. 3.  Substantiate reason for security countermeasures based upon impact & threat analysis.   Adoption Catalysts: Leverages a maturity model for long term adoption and metrics gathering   Audience: Fosters collaborative activities around Architects, PMs, Developers, SysAdmins, Security Testers, QA, Business, Network Operations, GRC & more   Key Differentiators: Considers more than just the network, infrastructure, platform, and application stack. Attacks can lie at the physical or human layers which are ignored in other methodologies. 17
18. 18 Risk Triangle Probabilistic Analysis via Threat Modeling q  A binary exercise for threat, attacks, vulnerability exercises q  WALK, RUN versions of model suggest weighted probability bands for maturity of threats, attacks, vulns, etc. q  Pen Testing determines value of attacks exploiting vulns via 4 probability bands §  P < 25% §  25% < P < 50% §  50% < P < 75% §  P > 75% Threat   Maturity   (p)   Vuln/ Weakness   exist?  (v)   Successful   A[ack?   (p)   Target   Value  (i)  
19. 19 PASTA Adoption Risk  Centric   Applica>on   Threat   Modeling     Crawl   Walk   Run   q  Provides for a flexible, phased approach for adoption of application threat modeling q  Simplifies threat modeling activities across 7 possible stages q  Integrates with risk management efforts within various product groups q  Informal adoption models: crawl- walk-run q  Can tie to BSIMM or OpenSAMM Phased  Approaches  for  New  En22es  
20. BSIMM to PASTA Mapping Snapshot PASTA  Stage/ Walkthru  Main   Objec2ve   PASTA  Threat  Modeling   Stage/Walkthrough     Goals   BSIMM   Coverage  of   PASTA   BSIMM  Prac2ces   Leveraged  for   execu2ng  Stage/ Walkthru   BSIMM  Ac2vi2es  (*)  that  can  be  Scored  To  Assess  Capabili2es/Maturity   Levels  for  Execu2ng  the  Stage/Walkthrough   Readiness  To  Conduct   Stages  of  PASTA  Using   BSIMM  vs.  4  Scoring   I-­‐Define  Security   and  Risk   Mi>ga>on   Objec>ves   1)  Analyze  the  business  objec>ves   2)  Dis>ll  compliance-­‐regulatory  and  privacy   requirements   3)  Derive  security  requirements   4)  Conduct  preliminary  risk  analysis  to  iden>fy   possible  business  impacts  to  assets  assuming   compromise   5)  Define  the  risk  mi>ga>on  objec>ves   Stage  goals  2   and  3  are   covered  by   BSIMM  that  is   40%  necessary   to  perform  the   stage     Security   Requirements  (SRs)   Security  Strategy   and  Metrics  (SM)   Compliance  and   Policy  (CP)   A[ack  Models   (AM)   AM  1.2    Create  a  data  classifica>on  scheme  and  inventory     CP  1.1  Unify  regulatory  pressures   CP  1.3  Create  policy     SR  1.1  Create  security  standards   SR  1.3  Translate  compliance  constraints  to  security  requirements     SM  1.1  Publish  process  (roles,  responsibili>es,  plan),  evolve  as  necessary   SM  1.6  Require  security  sign-­‐off   AM  1.2  is  31/51  =60%     CP  1.1  is  40/51=78%   CP  1.3  is  36/51=70%     SR  1.1  is  38/51=74%   SR  1.3  is  24/51=47%     SM  1.6  is  35/51=68%   SM  1.1  is  35/51=68%         II-­‐Define  the   Technical  Scope   of  The  Analysis   1)  Iden>fy  the  technical  scope  to  be  assessed/ threat  modeled     2)  Iden>fy  the  main  components  of  the   applica>on,  soXware,  systems  and  network   infrastructure     3)  Define  the  applica>on  dependencies  from  main   components  and  the  data  interface  boundaries   Stage  goals   1,2,3  are   covered  by   BSIMM     Security  Features   and  Design  (SFD)   Architecture   Analysis  (AA)     SFD  1.1  Build  and  publish  security  features   SFD  1.2  Engage  SSG  with  architecture     AA  1.1.  Perform  security  feature  review   AA  1.2.  Perform  design  review  for  high-­‐risk  applica>ons       SFD  1.1  is  44/51  =  86%   SFD  1.2  is  37/51  =  72%     AA  1.1  is  39/51  =  76%   AA  1.2  is  35/51  =  68%     III-­‐Analyze  the   Applica>on  &  The   Func>onality   1)  Analyze  the  applica>on  architecture  and  the   components   2)  Analyze  and  the  data  flows  to/from  data   interfaces   3)  Analyze  the  applica>on/data  trust  boundaries     4)  Analyze  the  users  of  the  applica>on  and  their   role/permissions   5)  Iden>fy  the  data  assets  and  data  processing   func>ons  that  should  be  protected  as  per  security   requirements   Stage  goals  are   covered  by  AA   an  SFD    BSIMM   ac>vi>es   Architecture   Analysis  (AA)   Security  Features   and  Design  (SFD)   SFD  1.1  Build  and  publish  security  features   SFD  1.2  Engage  SSG  with  architecture   SFD  2.1  Build  secure-­‐by-­‐design  middleware  frameworks  and  common  libraries   SFD  2.2  Find  and  publish  mature  design  pa[erns  from  the  organiza>on..   SFD  2.3  Form  a  review  board  or  central  commi[ee  to  approve  and  maintain  secure   design  pa[erns.     AA  1.1.  Perform  security  feature  review   AA  1.2.  Perform  design  review  for  high-­‐risk  applica>ons   AA  1.3.  Have  SSG  lead  review  efforts   AA  1.4.  Use  a  risk  ques>onnaire  to  rank  applica>ons     AA  2.1  Define  and  use  AA  process   AA  2.2  Standardize  architectural  descrip>ons  (include  data  flow).     AA  2.3    Make  SSG  available  as  AA  resource  or  mentor     AA  3.1  Have  soXware  architects  lead  review  efforts   AA  3.2  Drive  analysis  results  into  standard  architectural  pa[erns     SFD  1.1  44/51=86   SFD  1.2  37/51=72   SFD  2.1  25/51=49   SFD  2.2  19/51=37   SFD  2.3  15/51=29     AA  1.1  39/51=76   AA  1.2  35/51=68   AA  1.3  27/51=52   AA  1.4  32/51=62     AA  2.1  10/51=19   AA  2.2  7/51=13   AA  2.3  17/51=33     AA3.1  9/51=17   AA3.2  4/51=7    
21. Process for Attack Simulation & Threat Analysis (Risk Centric)
22. PASTA™ Methodology 1.  Defines what’s important 2.  Defines attack surface by component enum 3.  Maps relationships amongst components 4.  Associates threat patterns to components 5.  Identifies vulns amongst components 6.  Enum & determine viability (p) for attack patterns 7.  Review residual risk/ consider countermeasures Stage  1:  Define  Objec>ves   Stage  7:  Risk  Mi>ga>on/  Countermeasures   Stage  2:  Define  Technical  Scope   Stage  3:  Applica>on  Decomposi>on   Stage  4:  Threat  Analysis   Stage  5:  Vulnerability  &  Weakness  Analysis   Stage  6:  A[ack  Modeling  
23. APPLICATION  THREAT  MODELING  ACTIVITIES  per  STAGE MGT PMO BA ARC DEV SYS QA SOC VA PT RA CMP SA TM STAGE  1  -­‐  DEFINE  BUSINESS  OBJECTIVES R/A A R/A I I I I I I I A A I A Obtain  business  objectives  for  product  or  application   A I R/A I I I I I I I I I I A Identify  regulatory  compliance  obligations I I C I I I I I I I C R/A I A Define  a  risk  profile  or  business  criticality  level  for  the  application I I C I I I I I I I R/A C I A STAGE  2  -­‐  TECHNICAL  SCOPE I A C A R/A R/A C I C C C I C A Enumerate  software  applications/  database  in  support  of  product/  application I I C A R/A R/A C I C C C I C A Identify  any  client  side  technologies  on  endpoints  or  endpoint  software  (Flash,  DHTML5,  etc.) I I C C R/A C C I C C C I C A Enumerate  system  platforms  that  support  product/  application I I C A R/A R/A C I C C C I C A Identify  all  application/  product  actors I I C A R/A R/A C I C C C I C A Enumerate  services  needed  for  application/  product  use  &  management I I C A R/A R/A C I C C C I C A Enumerate  3rd  party  COTS  needed  for  solution I I C A R/A R/A C I C C C I C A Identify  3rd  party  infrastructures,  cloud  based  solutions,  hosted  networks,  mobile  devices I I C A R/A R/A C I C C C I C A STAGE  3  -­‐  APPLICATION  DECOMPOSITION I I I A A A I I I I I I C R/A Perform  Data  Flow  Diagram  of  Application  Environment. I I I C A C I I I I I I C R/A Define  application  Trust  Boundaries  /  Trust  Models I I I A C C I I I I I I C R/A Enumerate  Application/  DB  Users  (non-­‐client) I I I C A A I I I I I I C A Identify  any  stored  procedures/  batch  processing  supportive  of   I I I C A A I I I I I I C A Enumerate  all  application  use  cases  (ex:  login,  account  update,  delete  users,  etc.) I I I A A C I I I I I I C A Identify  and  map  published  application  services  (.NET  WS,  REST,  COM,  etc.) I I I A A C I I I I I I C A STAGE  4  -­‐  THREAT  ANALYSIS I I I I R/A C C C C C R/A Gather/  correlate  relevant  threat  intel  from  internal/  external  threat  groups I I I I R/A C C C C C A Review  recent  log  data  around  application  environment  for  heightened  security  alerts I I I I R/A C C C C C A Gather  audit  reports  around  access  control  violations I I I I R/A C C C C C A Identify  probable  threat  motives,  attack  vectors,  &  misuse  cases I I I I C C C C I C R/A STAGE  5  -­‐  VUNERABILTIY  ASSESSMENT I I I C I I I I I I R/A Review/  correlate  existing  vulnerability  data   I I I I I R/A I I I I A Conduct  targeted  vulnerability  scans  based  upon  threat  analysis I I I C I R/A I I I I A Identify  weak  design  patterns  in  architecture I I I C I R/A I I I I A Map  vulnerabilities  to  attack  tree I I I I I C I I I I R/A STAGE  6  -­‐  ATTACK  ENUMERATION C C I R/A I I I R/A Enumerate  all  inherent  and  targeted  attacks  for  product/  application I I I R/A I I I A Map  attack  patterns  to  attack  tree  vulnerability  branches  (attack  tree  finalization) I I I A I I I R/A Conduct  targeted  attacks  to  determine  probability  level  of  attack  patterns C C I R/A I I I A Reform  threat  analysis  based  upon  exploitation  results I I I C I I I R/A STAGE  7  -­‐  COUNTERMEASURE  DEVELOPMENT  /  RESIDUAL  RISK  ANALYSIS C C C C C C I I I I C C C R/A Review  application/  product  risk  analysis  based  upon  completed  threat  analysis I I I I I I I I I I C I C R/A List  recommended  countermeasures  for  residual  risk  reduction I I I C C C I I I I C C C R/A Re-­‐evaluate  overall  application  risk  profile  and  report. C C C I I I I I I I C C C R/A
25. ! Business  managers  can  incorporate  which   security  requirements  that  impact  business   ! Architects  understand  security/design  flaws   and  how  countermeasure  protect  data   assets   ! Developers  understand  how  soXware  is   vulnerable  and  exposed     ! Testers    can  use  abuse  cases  to  security   tests  of  the  applica>on   ! Project  managers  can  manage  security   defects  more  efficiently   ! CISOs  can  make  informed  risk  management   decisions     PASTA Beneficiaries R i s k   c e n t r i c   t h r e a t   modeling   provides   opp   to   expand   reach   of   threat   modeling   ac>vi>es   in   a   n o n -­‐ a d v e r s a r i a l   a n d   collabora>ve  manner.    
26. Applying PASTA to FAST FOOD 26
27. Threat Modeling Real World Cases   Recent Fast Food Hacks  POS Systems/ Networks  Payment Processors   Multiple Recent Victims  Domino’s Pizza  Dairy Queen  Jimmy John’s (Signature Systems, Inc.)  PF Chang  Chick-Fil-A
28. Chick-Fil-A :: Quick Biz Profile   Successful $5.1B (2013) restaurant fast food chain   Privately held   Stores average $2.85M / store   Don’t do real francishising   Own land, store, and equipment and lease it back to operator for 65% of profits   Heavy focus on social responsibility   Employs wireless POS   Roughly 1,850 units, in 41 states   Stand alone > 1,200 units   Mall-in ~ 300 units   Drive-in ~35
29. STAGE I - DEFINE BUSINESS OBJECTIVES
30. Stage 1 Threat Modeling Activities   S1-A1: Define Business Objectives for the Product Application AND   S1-A2: Identify Regulatory Compliance Obligations   S1-A3: Define a Risk Profile or Business Criticality Level for the Application   S1-A4: Identify the Key Business Use Cases for the Product Application
31. Why You Should Care About Impact Business Objectives   Business subsidizes IT, product, project efforts   Increased sales   Brand awareness   Cross sale opportunities   Businesses are held liable to these goals   Inability to meet metric based objectives is impact   Neglecting components that support processes or technology is impactful. Security & Software Development   Biz Objectives   External influences (regulation, accreditation)   Product Objectives   SW Objectives   Reliable Design Frameworks   Good Design Patterns   Product/ App Use   Functional Use Cases   Key APIs   Key actors   Key Data Sources
32. Impact Analysis   Write-offs due to fraudulent financial activity (Banking/Financial)   Easy to quantify (e.g. - unit sales no longer valid)   Legal representation, lawsuits   Moderately difficult to quantify   Bad press (negligence, loss of confidence)   Difficult to quantify unless tied to client/ customer churn rates   Non-compliance affecting accreditation   FISMA, FedRAMP, PCI-DSS, HIPAA/HITECH   Moderately to quantify OpEx Costs: breach notification, PR, legal counsel, credit monitoring   Easy to quantify CapEx: Sony (new hardware for everyone!)   Easy to quantify (e.g. – HW asset costs, maintenance contracts)   IP Loss   Easy to quantify (e.g. – projected product sales forecasts, sunk R&D costs)
33. Pre-Emptive Security via PASTA – Stage 1 Obj1   Countermeasures   (External   Frameworks)   Countermeasures   (Internal  Standards)   Countermeasures   (External   Regula>ons)   CoBIT,  ISO,  NIST,   SANS  CAG,  CIS   Obj2   Obj3   Crypto,   Authen>ca>on,  .NET   Security,  Java   Security   PCI-­‐DSS,  NERC  CIP,   FIPS  140-­‐2,   FedRAMP   Internal  processes/   ar>facts   Risk  Assessments,   Vuln  Assessments,   SAST/  DAST  Rpts  
34. Project  Business  Objec2ve Security  and  Compliance  Requirement Reduce  financial  risks  associated  with   malware  banking  a[acks Harden  network  architecture  and  network  services  in  order  to  enact  rights   of  least  privilege. Establish  a  reliable  applica>on  architecture   aimed  at  sustaining  a  secure  applica>on   environment  for  financial  apps Maintain  and  abide  by  strict  applica>on  architecture  controls  around   access  control,  authen>ca>on,  audit  &  logging,  iden>ty  management,   crypto  key  storages. Adhere  to  regulatory  requirements  that   affect  sales  growth  or  exis>ng  client  SLAs Review  landscape  of  compliance  requirements  and  ensure  that  a  process   to  measure  compliance  gaps  are  captured  and  remediated  in  a  >mely   manner.   Ensure  confiden>ality  of  client  data   Implement  cryptographic  controls  for  secure  auth  data  security  via   hashing,  PII  storage  via  approved  encryp>on  algorithms  for  both  storage   and  data  transport  mediums.   Ability  to  respond  to  security  incidents  in  a   >mely  and  effec>ve  manner.     Ensure  that  applica>on,  network,  and  3rd  party  solu>ons  have  logging   capabili>es  and  data  points  that  provide  value  in  the  event  of  a  security   incident.   Harmonizing Business Obj to Security Reqs
35. Generic Objectives for Fast Food Retailers (FFR) Biz Objectives 1.  Healthy overall revenue growth a)  3-5% annual sales growth desired 2.  Increase repeat customer sales 3.  High inventory turnover 4.  Increase avg order per customer 5.  Reduce employee turnover 6.  Reduce store originated liabilities Security Implications   Reputation damage (1-5)   Social regard   Boycotts from perpetrated social media falsifications   Malicious spamming on behalf of (FFR)   Major CC breach   Lose confidence from CC holders)   Latency from malware in embedded OS on POS   Affects wait time; possibly reduces   Tainted inventory numbers in POS (3)
36. Relevant Data & Regulatory Impact   Payment data is focal data source   PCI-DSS  Increased audit costs (corporate assumed expenes) Avg compliance costs=$3.5M/yr  Non-compliance costs = 2.65 x compliance costs   PII  Fines & lawsuits
37. POS Objectives Negated by Threats   Security of system, data   Speed   Ease of Use   Uptime   Inventory Management   Accounting
38. OpEx Costs Post Incident - Impact   $201 (US) per record lost   Demand may curb in wake of sales (evident w/ Target)   Procuring new payment processor vendor  Krebs: Suspect payment processor   Increase OpEx costs in customer service  “Customers may call 855-398-6439…”   Credit monitoring costs   “If our customers are impacted, we will arrange for free identity protection services, including credit monitoring.” - http://krebsonsecurity.com/2014/12/ banks-card-breach-at-some-chick-fil-as/
39. ENUMERATE TECHNOLOGY COMPONENTS
40. Stage 2 Activities   S2-A1: Enumerate Software Applications/Databases in Support of the Product/Application AND   S2-A2: Identify any Client-Side Technologies AND   S2-A3: Enumerate System Platforms that Support the Product/Application AND   S2:A4: Enumerate all Application/Product Actors AND   S2:A5: Enumerate Services Needed for Application/ Product Use and Management   S2-A6: Enumerate Third-Party COTS Needed for the Solution AND   S2-A7: Identify Third-Party Infrastructures, Cloud Solutions, Hosted Networks, and Mobile Devices
41. Infrastructure & Server Asset Enum 1/27 41
42. 42 Examples of Assets q  Assets in IT have a strong hardware connotation q  Assets can be physical or virtual, clustered or stand alone q  In-scope assets are those serving as a client, server, or intermediary of data. q  IT Assets can encompass multiple components q  Sample Client Assets: Proprietary Medical Devices q  Sample Presentation Assets: Web Servers (Apache, IIS), Middleware (ISA, Citrix), Tablet iOS, SmartPhone Android q  Sample Network Assets: Load balancer, Firewall, IDS/IPS, WAF q  Sample Application Servers: COM Servers, IIS (again), Java EE, Geronimo, Jboss AS, Webshere, etc. q  Sample Data : Fileshares (Win2012, Win2008), Databases Servers,
43. 43 Asset Enumeration Objectives & Approach q  Identify the assets and components that make up the product application q  Wide breadth of component identification across architecture q  Creates technology scope for which to defend/ attack q  Easiest to tie assets to use cases §  Ex: Login WSVC §  Ex: Daily Data Extract Runs §  Ex: Image Upload q  Table top exercises can help enumerate asset components by arch layer §  Ex: (Presentation Layer) IIS 7.0, WWSAPI (WS-*, .NET-*), Load Balancer, Application Proxy, Firewall, Router, WAF §  Schematic/ network designs good resource q  Technology scans using host detection, application fingerprinting, and port /service enumeration compliment table top exercises §  Ex: Nmap, Lansweeper, WebInspect,Burp Pro, Arachni, Nessus, AppScan, etc.
44. Environment Enumeration via Nmap
45. Plenty of Network Enumeration Tools
46. Enumerating Software via HTTP Headers
47. 47 Targeted Attacks Target Any Component How Good Recon is a Slippery Slope q  Assets can encompass several components §  Drivers, HW Interfaces, O/S, running services, etc. q  Host based component enumeration also useful (installed S/W, packages, embedded systems) q  Smallest component can be backdoor §  Hacker: Fake signed driver update §  End User: ‘It’s a driver update only’   E:\ubuntu_64_hw_sw\ubuntu_64_hw_sw\pci_hardware     00:00.0  Host  bridge:  Intel  Corporation  440BX/ZX/DX  -­‐   82443BX/ZX/DX  Host  bridge  (rev  01)     00:01.0  PCI  bridge:  Intel  Corporation  440BX/ZX/DX  -­‐   82443BX/ZX/DX  AGP  bridge  (rev  01)     00:07.0  ISA  bridge:  Intel  Corporation  82371AB/EB/MB  PIIX4   ISA  (rev  08)     00:07.1  IDE  interface:  Intel  Corporation  82371AB/EB/MB   PIIX4  IDE  (rev  01)     00:07.3  Bridge:  Intel  Corporation  82371AB/EB/MB  PIIX4  ACPI   (rev  08)     00:07.7  System  peripheral:  VMware  Virtual  Machine   Communication  Interface  (rev  10)     00:0f.0  VGA  compatible  controller:  VMware  SVGA  II  Adapter     00:10.0  SCSI  storage  controller:  LSI  Logic  /  Symbios  Logic   53c1030  PCI-­‐X  Fusion-­‐MPT  Dual  Ultra320  SCSI  (rev  01)     00:11.0  PCI  bridge:  VMware  PCI  bridge  (rev  02)     ...     00:18.2  PCI  bridge:  VMware  PCI  Express  Root  Port  (rev  01)     00:18.3  PCI  bridge:  VMware  PCI  Express  Root  Port  (rev  01)     00:18.4  PCI  bridge:  VMware  PCI  Express  Root  Port  (rev  01)     00:18.5  PCI  bridge:  VMware  PCI  Express  Root  Port  (rev  01)     00:18.6  PCI  bridge:  VMware  PCI  Express  Root  Port  (rev  01)     00:18.7  PCI  bridge:  VMware  PCI  Express  Root  Port  (rev  01)     02:00.0  USB  controller:  VMware  USB1.1  UHCI  Controller     02:01.0  Ethernet  controller:  Intel  Corporation  82545EM   Gigabit  Ethernet  Controller  (Copper)  (rev  01)     02:02.0  Multimedia  audio  controller:  Ensoniq  ES1371   [AudioPCI-­‐97]  (rev  02)  
48. 48 Chatty Assets How Seemingly Benign Asset Data Can Spell Misfortune q  Assets reveal what they are, what versions they have, what components they support §  Components: system files, installed s/w, services, named pipes, compiled libraries (binaries) q  Response info fuels attacks if response reveals vulnerable components q  Security begins here: Security Hardening & Network Defenses §  Hardened accounts §  Detect/ prevent network scans §  Divest unnecessary software’   Active  Internet  connections  (servers  and  established)     Proto  Recv-­‐Q  Send-­‐Q  Local  Address                      Foreign  Address                   State                 tcp                0            0  *:microsoft-­‐ds                    *:*                                           LISTEN               tcp                0            0  localhost:mysql                  *:*                                           LISTEN               tcp                0            0  *:netbios-­‐ssn                      *:*                                           LISTEN               tcp                0            0  *:http                                    *:*                                           LISTEN               tcp                0            0  *:ssh                                      *:*                                           LISTEN               tcp                0            0  172.16.219.150:ssh            172.16.219.1:49993             ESTABLISHED     tcp6              0            0  [::]:microsoft-­‐ds              [::]:*                                     LISTEN               tcp6              0            0  localhost:8005                    [::]:*                                     LISTEN               tcp6              0            0  [::]:netbios-­‐ssn                [::]:*                                     LISTEN               tcp6              0            0  [::]:http-­‐alt                      [::]:*                                     LISTEN               tcp6              0            0  [::]:ssh                                [::]:*                                     LISTEN               udp                0            0  *:bootpc                                *:*                                                               udp                0            0  172.16.219.2:netbios-­‐ns  *:*                                                               udp                0            0  172.16.219.1:netbios-­‐ns  *:*                                                               udp                0            0  *:netbios-­‐ns                        *:*                                                               udp                0            0  172.16.219.:netbios-­‐dgm  *:*                                                               udp                0            0  172.16.219.:netbios-­‐dgm  *:*                                                               udp                0            0  *:netbios-­‐dgm                      *:*    
49. Assume Enumeration from Adversaries
50. q  Scanning your environment q  Protocol Header Info (HTTP, SSH, FTP, etc.) q  Botnets q  Sites like http://www.shodanhq.com q  Bartering target information on hacker data clearinghouses q  Your Application Error Messages/ Responses 50 How Attackers Mine Component Information
51. 51 Technology Enumeration Recommendations q Use both manual and automated techniques for asset/ infrastructure discovery q Apply countermeasures to limit information leakage on assets/ components §  Proper error handling, reduced privileges for conducting host based enum, prevent network scans from unauthorized sources, leverage existing schematics, harden asset components (Windows, Unix, hardening guidelines)
52. Service & Software Asset Enum 1/27 52
53. 53 Software Enumeration – Where to Start? q Know software running on hosts q Software components should be part of threat model q Custom scripts can easily gather information q Asset discovery or security scanners can easily enum software q Software components can be easily exploitable q Software related countermeasures can be easily mitigated early in SDLC §  Host based hardening §  Deprecating S/W Privileges §  Uninstalling non-essential software – reduce attack surface §  Generic error handling; safely escaping exceptions
54. 54 Facilitating Software Enumeration System Platforms Make it Enumeration Easy
55. q Table top exercises not as effective q Reliance on platform tools or 3rd party scanners provide greatest benefit q Running both scanner and platform tools allows suggested q Priorities are around Frameworks (content, UI, etc.) and major software components q (RUN) Enumerating more software components than will be covered in threat model is not negative Software Enumeration How To
56. Package Management/ Mis-Management (*nix) Threat Implications of Discovered Software
57. Software/ Process Components Real Time Process / Software Enumeration (Windows)   C:\Users\tonyuv@versprite.com>wmic  process  get  name     Name     System  Idle  Process     System     smss.exe     csrss.exe     csrss.exe     wininit.exe     winlogon.exe     services.exe     lsass.exe     lsm.exe     svchost.exe     svchost.exe     LogonUI.exe     svchost.exe     svchost.exe     spoolsv.exe     WVSScheduler.exe     WVSScheduler.exe     MicrosoX.Ac>veDirectory.WebServices.exe     dfsrs.exe     dns.exe     dsNcService.exe     For>SSLVPNdaemon.exe     IISexpressSVC.exe     ismserv.exe     tomcat7.exe     LansweeperService.exe     pg_ctl.exe     iisexpress.exe     conhost.exe     ruby.exe     postgres.exe     conhost.exe     ruby.exe     capiws.exe     postgres.exe     svchost.exe     nessus-­‐service.exe     nessusd.exe     vmtoolsd.exe     dfssvc.exe     vds.exe     svchost.exe     dllhost.exe     svchost.exe     msdtc.exe     postgres.exe   q  wmic  command  allows  to  query   local  installed  products  and  ac>ve   processes  on  a  Windows  plaworm   q  Windows  sysinternals  suite     q  dpkg  –l     q  rpm  –qa  |  grep  –i  <package   name>  
58. Software/ Process Components   C:\Users\tonyuv@versprite.com>wmic  process  get  name     Name     System  Idle  Process     System     smss.exe     csrss.exe     csrss.exe     wininit.exe     winlogon.exe     services.exe     lsass.exe     lsm.exe     svchost.exe     svchost.exe     LogonUI.exe     svchost.exe     svchost.exe     spoolsv.exe     WVSScheduler.exe     WVSScheduler.exe     MicrosoX.Ac>veDirectory.WebServices.exe     dfsrs.exe     dns.exe     dsNcService.exe     For>SSLVPNdaemon.exe     IISexpressSVC.exe     ismserv.exe     tomcat7.exe     LansweeperService.exe     pg_ctl.exe     iisexpress.exe     conhost.exe     ruby.exe     postgres.exe     conhost.exe     ruby.exe     capiws.exe     postgres.exe     svchost.exe     nessus-­‐service.exe     nessusd.exe     vmtoolsd.exe     dfssvc.exe     vds.exe     svchost.exe     dllhost.exe     svchost.exe     msdtc.exe     postgres.exe     cmd.exe     conhost.exe     nginxr7.exe     nginxr7.exe   q  Real Time Process / Software Enumeration (Windows)   q  wmic  command  allows  to  query   local  installed  products  and  ac>ve   processes  on  a  Windows  plaworm   q  Windows  sysinternals  suite     q  dpkg  –l     q  rpm  –qa  |  grep  –i  <package   name>  
59. Service Detection q  Nmap  –  GUI  &  CLI  port  scanner   q  Multiple  options  to  customize  and  automate  into  scripts   q  Nmap  –O  (OS  Detection)  –sV  (probe  open  ports)  –p  T: 1-­‐65535  (port  option,  TCP,  all  ports)  –T  3  (timing   option)   q  Ideally  run  beyond  FW  boundaries  for  greater  accuracies   q  Fosters  port  (service),  platform,  and  even  rogue  software   detection.  
61. Building Security In Note on inherent threats and pre-emptive security hardening q  Hardening  begins  at  this  step  and   can  parallel  an  SDLC’s  DESIGN   phase   q  Tech  standards  for  security  can  be   applied  here  (Cisco  ASA  Hardening,   W2K8  Hardening,  ESX  Security   Hardening  guides)   q  Hardening  can  be  as  simple  as   dives>ng  of  unnecessary  ports/   services/  soXware   q  Overall  a[ack  surface  reduc>on   q  Threats are sometimes inherent to functionality q  FTP = brute force attacks q  SNMP = network reconnaissance q  HTTP = injection based attacks, session hijacking, data leakage, MITB q  SMB/NFS = pass the hash, MITM
63. Data & Actor Enum 1/27 63
64. Data Enumeration – Tools & Techniques q Application Architectural Reviews q File system find  scripts   v find  –name  *.bat  <file  system  path>   v Various  DLP  solu>ons   q Review  DB  Schema   q DNS  Enumera>on  (DNS  is  a  data  source  to  product  app)  
65. q Data affects risk level in risk equation via impact (R=T*V*I) as well as countermeasure effort q Volume  of  data   q Reten>on  period   q Data  type  (PCI,  PHI,  PII,  IP,  Privacy  related)   q Data  authen>ca>on  model   q Data  use  (privacy  implica>ons  and  related  countermeasures)   q Inherent  countermeasures   Data Focus Data Classification affects Impact
66. Enumerating Actors – Tools & Techniques q Actor enumeration is critical; privileges easily overlooked q Running as root,  system   q CRUD Exercises q *nix: cat  /etc/passwd     q Windows: net  user  /domain  (insert app domain) q CRUD exercises against databases q Database mitigation opportunities
67. CRUD Exercises for Pre-emptive Security
68. Enumerating Components (by Biz Objective) in Fast Food Secure  Payments   •  Secure  PAN  Data   •  POS  SoXware   •  POS  Hardware   (ParTech  POS  HW)   •  Ensure  secure   communica>on   •  Wireless  Service   Provider   •  Wireless  Router     •  3rd  party   interfaces   Inventory   Management   •  Reduce  Fraud   •  Backoffice   SoXware   •  Ensure  Proper   Supply  Thresholds   •  Backoffice   Inventory   Database   Speed  of  Service   •  Ease  of  use   •  POS  SoXware   •  Responsive  system   •  Embedded  system   OS   •  Kitchen  Display   Units  
69. Know Thy Assets
70. Questions Required for Tech Enumeration   What supports app environment?   Hardware? (e.g. – HHD, SD)   Embedded Systems? (e.g. Windows Server 2012 for Embedded Systems, Windows POS Ready 7, etc.)   Frameworks? (.NET 4.5.2, OpenERP Framework (Odoo PoS)   Vendor Tech?  Configurations w/in Vendor Tech?   Network Services?   Interfaces? (e.g – USB, Serial Parallel, Bluetooth,   System, DB, App Level Accts (Actors)   Where are components in app architecture?
71. Easy ways to perform Tech Enum Network Based   Host Discovery (e.g. - host queries)   Service Discovery   Port Mapping   Vulnerability Scanner   Network Sniffer (tcpdump, wireshark)   DNS Lookups   ACL Audit   Network Logs Host Based   Package dump   MBSA (Windows)   Local vuln scan Sysinternals TCPView-active socket cmd line viewer PipeList-displays named pipes on system Htop (Linux)
72. Easy ways to perform Tech Enum (cont.) Application   All previous host based enum techniques   Directory Enum   Dynamic Analysis   Static Analysis   Architecture Review Database/ Filesystem Ediscovery Scripts   Custom Regex   Schema review for POS DB
74. APPLICATION DECOMPOSITION
75. Understanding Data Flow Diagramming (DFD) 1/27 75
76. Data Flow Diagramming (DFD) Primer General Information q  Scoping  is  key   q  Dependencies  (>me,  SMEs)   q  Map  Flows   q  Data  Flows  amongst   components   q  Call  Flows   q  Maps  out  use  of   applica>on  components     q  Visualizes   communica>on   Misconceptions/ Myths q  Too  complicated   q  Takes  too  much  >me   q  Too  technical   q  Too  many  defini>ons   to  learn   q  Only  focuses  on   security  
77. q Build data flow diagrams to map components q Identify where trust boundaries exist q Label calls/ requests in DFD by {data type, protocol} q Identify Use Cases in DFDs q Build DFDs best in teams (group approach) Application Decomposition Key Activities
78.   S3-A1: Define Application Trust Boundaries/Trust Models AND   S3-A2: Perform Data Flow Diagram of Application Environment   S3-A3: Enumerate Actors AND   S3-A4: Identify any Stored Procedures/Batch Processing AND   S3-A5: Enumerate all Application Use Cases (ex: login, account update, delete users, etc.)
79. q  Often times, hardest part q  Weak enum exercises foils rest of model, particularly DFDs q  Coverage is important q  Balance: Comprehensive vs. Oppressive q  Context based DFDs a good start q  Process based DFDs; more advanced q  Enumeration activity preferably done in a group Enumeration: Key to DFD
80. Is this helpful?
81. Types of DFDs High Level ‘Context’ q  Focuses  on  primary   en>>es  that  interact   with  a  product   applica>on   q  Focuses  on  high  level   informa8on  flows   q  Think  of  process  flows  in   applica>on  or  target   scope   q  5,000  foot  view   Low Level Process q  Looks  at  sub-­‐en>>es  or   components   q  Focuses  more  on  data   flows  amongst  sub-­‐en>>es   q  Depicts  processes  of   product  applica>on  itself   q  Think  of  call  flows   q  50  foot  view   q  Builds  off  of  high  level  DFD  
82.   Picturesque way of showing the movement of data between external entities and the processes and data stores within a system   Build from enum exercises   Collaborative developer, architect, biz analyst exercise DFD Definition   DFDs: Keeping it Simple
83. §  Multiple symbols out there §  No incorrect representation §  Use whatever works for the enterprise; governance required §  Multiple symbols for certain terms presented §  Request/ responses intended to reflect use case §  Use numbers in labels to help show sequential order §  Visio makes it easier DFD Legend   Understanding the Symbols
84. §  Data Flow Diagrams reflect data flows that connect…. §  Simple Rule: Don’t connect the rectangles directly Quick Guidelines for DFDs YES   NO   A  process  to  another  process   ü   A  process  to  an  external  en>ty   ü   A  process  to  a  data  store   ü   An  external  en>ty  to  another  external  en>ty   ü An  external  en>ty  to  a  data  store   ü A  data  store  to  another  data  store   ü
85. §  Labels should be action verbs §  Receives Input; Produces Output §  Entity represented as an ‘entity’ icon or ‘actor’ icon §  Inputs can be more than one from an entity §  Process can interact with any other symbol Process doStartOpera>ons..     Star>ng  opera>ons...     NEW  TRANSACTION:   1071     StartOpera>ons::INS ERT_BALANCE     Inserted  the  new   BALANCE  #  156    
86. Data Flow §  Shows a path for data to move from one area of product application to another §  Arrows show direction of data flow §  Can show flows amongst processes, entities, actors, and data sources §  Below shows process giving information from data source
87. §  Shows where the data is located §  Exemplified typically by two parallel bars §  Labels of noun §  Can include sources & sinks (Low Level Threat Modeling) §  /dev/null (sink) §  Function () (source) §  No idle data stores §  Must have one incoming and outgoing data flow §  Can be part of separate use cases or data transactions §  Examples: §  File systems §  File objects (SQLite DBs) §  App manifests (used to read) §  Manifests (Chef, Puppet) §  SVN §  Relational DBs §  Mainframe systems Data Store
88. Identify Entities,Process,Data Stores & Data Flow   Actors/ Entities   Cashier(s), Manager(s) LemonPOS KDE Client LemonPOS MySQL   Use Cases   1.0 Vendor Login (Emp)   2.0 Set Cash Balance (Admin)   3.0 Add Product to Sale   4.0 Finalize Sale   5.0 Vendor Exit (Emp)   Data Stores   D1 Audio Files (MPEGs)   D2 Transcription Database n  Data Flows ¨  Authenticate Employee ¨  Authenticate Supervisor ¨  Authenticate Administrator ¨  Set Cash Bal in DB ¨  Insert Category ¨  Insert Product ¨  Update Price ¨  Request Receipt 1.0 2.0 3.0
89. §  Most legend icons present in MS Visio 2013 §  Drag & drop §  Double click icon to add text to object §  Grid provides for automatic mapping §  Many other tools exist 89 Icons Starter Kit
90. Trust Boundaries (Mobile Example)
91. Trust Boundaries Amongst Asset Components Example
92. LemonPOS Use Cases-Calls-Actors
93. DFD Final Thoughts §  Keep it simple §  Work in teams §  Focus on accuracy not breadth at first §  Use free tools §  Understand your apps better so that you can defend them.
94. THREAT ANALYSIS
95. Stage 4 Threat Modeling Activities   S4-A1: Gather/Correlate Relevant Threat Intelligence from Internal/External Threat Groups   S4-A2: Review Recent Log Data around the Application Environment for Heightened Security Alerts AND   S4-A3: Gather Audit Reports around Access Control Violations   S4-A4: Identify Probable Threat Motives, Attack Vectors, and Misuse Cases
96. Motives Matter   PASTA Stage IV lends from Offender Profiling   Offender profiling - method of identifying the perpetrator of a crime based on an analysis of the nature of the offense and the manner in which it was committed. Various aspects of the criminal's personality makeup are determined from his or her choices before, during, and after the crime.   Hinges on evidence collection   Threat intelligence – external threat data  Subscription based is the way to go  Manually – US Cert, FR-Cert, etc. (Ex: https://www.kb.cert.org/vulfeed)   Threat data – internal threat data  Syslog sources, SIEM & Log Aggregation Tools (Qradar, Tuffin, Sumo, Splunk, ArcSight, etc.)
97. Haktivism   Vigilantes of justice   Code of ethics exists (info decentralization & availability)   Efficient | resource, tool, intel shares   Political | Socio-Economic | Corporate = campaign motives   More persistent   Threat activity = threat intel++
98. 98 Importance of Threat Intel Understanding Generic & Targeted Attacks §  Threat intel provides us information on attack behavior §  Allows organizations to prepare for active attack patterns §  Threat intel provides predictive analysis on current trends on industry based threats. §  Reveals techniques around targeted attack patterns §  Best threat intel comes from within your own environment §  Unusual payloads/ traffic recorded by logging agents in enterprise may give hint to targeted attacks
99. Threat Intelligence Consumption & Analysis Do’s & Don’ts §  DO make your own threat intel; sources can be from your own team’s research or internal logs §  DO know where your threat sources are coming from §  DO ensure that your threat information is always recent and cross-validated. §  DO tie your threat intelligence data to the technology scope defined in Steps 2 & 3 §  DON’T use one source of threat intel data as single defining source. §  DON’T use your competitors threat intelligence as a basis for formulating conclusive industry related threats §  DON’T let the threat analysis reveal assets you didn’t consider from before – this means you did Steps 2 & 3 incomplete.
100. Sample Threat Analysis Blanketed Attacks q  Blanketed attacks look to find ‘easy’ targets, indifferent to industry OR within a target industry. q  Search for targets that exhibit signs of preferred ‘vulnerabilities’, known to be exploitable q  Tech centric based threats (component centric) q  Tend to focus on web application and remote service weaknesses q  Backup tapes/ storage q  Mobile devices q  Web technologies q  FTP sites q  Insecure protocol use q  Administrative use cases q  PHI, PII (ID Theft) q  Embedded systems q  Newly discovered vulnerability research q  DoS Attacks, Application Resliency
101. Sample Threat Analysis Targeted Entity - Covered Entity §  May troll on places like ShodanHQ or simply resort to Google Hacking §  Blanketed attacks look to find ‘easy’ targets, indifferent to industry OR within a target industry. §  Search for targets that exhibit signs of preferred ‘vulnerabilities’, known to be exploitable
102. Evolution of Cyber-related Threats Time Threat Severity 2000 1995 2005 2010 Threats: Script Kiddies, Viruses, Worms Motives: Notoriety and Fame, Profit from renting Botnet for spamming Attacks: DoS, Buffer Overflow Exploits, Spamming, Sniffing Network Traffic, Phishing emails with viruses Threats: Fraudsters, Malware, Trojans Motives: Identity Theft, Online and Credit/Debit Card Fraud Attacks: SQLi, Sniffing Wireless Traffic, Session Hijacking, Phishing, Vishing, Drive by Download Threats: Hacktivists, Cyber crime, Cyber Espionage, Fraudsters, Malware Motives: Political, Stealing Company Secrets and Clients Confidential and Credit Card Information for Fraud Attacks: DDoS, Defacing, Account Take Over/Session Hijacking, SQLi, Spear Phishing, APT, RAT 2012 Threats: Basic Intrusions and Viruses Motives: Testing and Probing Systems and Data Communications Attacks: Exploiting Absence of Security Controls, Sniffing Data Traffic, Defacing WHAT NEXT ?
103. Threat Intel Sources 1/27 103
104. q  Verizon Business Annual Cybercrime report (http:// www.verizonenterprise.com/DBIR/2013/) q  US CERT (http://www.us-cert.gov/mailing-lists-and-feeds) q  McAfee ( http://www.mcafee.com/us/resources/reports/rp-threat- predictions-2013.pdf) q  BackOff POS Malware (https://www.us-cert.gov/ncas/alerts/TA14-212A) q  R-CISC (Retail Cyber Intelligence Sharing Center- http://www.rila.org/rcisc/Home/Pages/default.aspx ) - 3 components §  Retail Information Sharing & Analysis Center (ISAC): brings retailers together for omni-directional sharing of actionable cyber threat intelligence, and functions as a conduit for retailers to receive threat information from government entities and other cyber intelligence sources. §  Education & Training: works with retailers and partners to develop and provide both education and training to empower information security professionals in retail and related industries. §  Research: looks to the future, undertaking research and development projects in partnership with academia, thought leaders, and subject matter experts in order to better understand threats on the horizon..’ External Threat Sources to Consider
105. q Example: Where to find if you’re application is being brute forced for weak and common credentials: §  Apache Access logs: /var/log/httpd-access-log §  Tomcat logs: Access Log Valve - Access Log Valve creates log files in the same format as those created by standard log servers §  ISS logs: c:\inetpub\logs\LogFiles q If the application is using AD to authenticate, check the windows security logs for failed authentication attempts Internal Threat Sources to Consider
106. 1/27 McKesson  Corpora>on  Confiden>al  and  Proprietary   106 Multiple Options from Industry Vendors   A mixed bag is always best.
107. Extracting Meaning Info from Threat Sources Key Retail Related Statistics – VZ DBIR (Source)
108. Things to Consider in Threat Analysis Cyber-­‐ Threats   Mo>va>ons   Threat   Sources   Capabili>es   Targeted   Assets   A[acks   Past   Ac>vi>es   Security  Incidents   Threat  Intelligence  
109. q Institute training and awareness of cyber-threats for: §  Customers (clients-consumers) – value add §  Product development teams §  Education & training via multiple means (newsletters, lunch & learns, CBT, Classroom style, etc.) q Adopt cyber-threat risk analysis processes such as: §  Threat Intelligence – make threat feeds relevant; tie to context (use case) or tech §  Threat Analysis – start with small threat sources to practice the threat analysis §  Attack Modeling – step through attack sequence to substantiate threat viability §  Threat Based Vulnerability Analysis – targeted vuln analysis §  Analysis of Countermeasures q Keep up with managing cyber-threat risks §  Determine relevancy based upon context of app + technology scope Threat Analysis Strategy Steps to Leverage Threat Intel from Varying Sources
110.   Where to find if you’re application is being brute forced for weak and common credentials:   Apache Access logs: /var/log/httpd-access-log   Tomcat logs: Access Log Valve - Access Log Valve creates log files in the same format as those created by standard log servers   ISS logs: c:\inetpub\logs\LogFiles   If the application is using AD to authenticate, check the windows security logs for failed authentication attempts Internal Threat Sources to Consider
111. Threat Analysis Process • Iden>fied  Targets   • Iden>fied  gains   • Iden>fied  risks  (for   a[acker)   • Difficult  to  achieve,  not   essen>al  but  helpful   Perceived   Mo>ve   • Data  extrac>on   • DoS   • A[acking  data  integrity   • STRIDE/  DREAD  men>on   Understood   Threats   • High  Level  Data   • More  Detail  Data  Asset   Enumera>on   • Leads  into  next  phase:   vulnerability  analysis   Asset   Mapping  
112. ENUMERATING APP WEAKNESSES & VULNS
113. Stage 5 Threat Modeling Activities   S5-A1: Conduct Targeted Vulnerability Scans Based upon the Threat Analysis AND   S5-A2: Identify Weak Design Patterns in the Architecture   S5-A3: Review/Correlate Existing Vulnerability Data   S5-A4: Map Vulnerabilities to Threat/ Attack Tree
114. Threat Tree Taking Shape – Now w/ Vulns
115. MODELING ATTACKS
116. User Hacker/Malicious User Brure Force Authentication Enter Username and password Validate Password Minimum Length and Complexity Application/Server Includes Mitigates User Authentication Includes Includes Includes Mitigates Threatens Show Generic Error Message Includes Includes Lock Account After N. Failed Login Attempts Harverst (e.g. guess) Valid User Accounts Dictionary Attack Mitigates Mitigates
117. Attack Tree of CC Compromise
118. 118 Credit Card Data Compromise Man In The Middle/Browser Attack Automated SQL Injection Attack To upload malware Serve malicious IFRAME to victim visiting the web site Phishing Email/ Social Engineering SQL Injection Exploit Alter Query To Get CC data Exploit Weak Session Management Insecure Cryptographic Storage/ Transit Impersonate user to get access to CC data Upload Sniffer To Get CC data Session Fixation to get access to CC data Attack User/ Browser Attack Web Application Clickjacking Serve Invisible Frame that runs malware Take Credentials and CC data from user Capture Non- Encrypted CC Data   #2  Test  for  SQL  injec>on  and  code   injec>on  (Frames)  vulnerabili>es       #4  Test  for  session   fixa>on  and  hijacking       #3  Test   encryp>on  of   sensi>ve  CC  data   in  storage  and   transit       #1  Test  web   applica>on  assuming   browser   compromise    and/or   automa>on  a[acks     Cybercriminal Activity Around Card Data
119. BUILDING COUNTERMEASURES BASED ON RISK
120. Cyber security Considerations – Stage 7   Mitigation driven by Business Impact & Threat Analysis   Countermeasures are developed commensurate to the threat, likelihood and most importantly the value of the data/ service {regulation | branding | SLAs | privacy}   Collaborative, less adversarial than traditional remediation efforts   Focuses on remediation activity based upon likely threats, clear attack paths, existing weaknesses/ vulns, with clear business impact values.
121. 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) 121  Access   Level   External   Access  Level   Internal   Access  Level   Restricted   I.  Spoofing   II.  Repudia2on   I.  Tampering   II.  Repudia2on   III.  Info  Disclosure   IV.  Denial  OF   service   AuthN,   Encryp2on   Digital,   signatures,   HMAC,  TS   I.  AuthN,   Encryp2on   II.  Digital   signatures,   HMAC,   TS,AuthZ   Audit   III.  Encryp2on,   AuthZ   IV.  Filtering,   AuthN   Mapping Countermeasures to Attacks
122. Developing countermeasu res against abuse cases.
123. CLOUD POS THREAT MODEL
125. BlackHole:apktool  TheGriffin$  java  -­‐jar  apktool_2.0.0rc3.jar   d  ../../apps/com.airpointofsale.pos.apk     I:  Using  Apktool  2.0.0-­‐RC3  on  com.airpointofsale.pos.apk   I:  Loading  resource  table...   I:  Decoding  AndroidManifest.xml  with  resources...   I:  Loading  resource  table  from  file:  /Users/TheGriffin/Library/ apktool/framework/1.apk   I:  Regular  manifest  package...   I:  Decoding  file-­‐resources...   I:  Decoding  values  */*  XMLs...   I:  Baksmaling  classes.dex...   I:  Copying  assets  and  libs...   I:  Copying  unknown  files...   I:  Copying  original  files...   Understanding Use Cases…
126. Using Manifest.xml to Understand Use Cases
127. 1.  Inherent   Risk  Profile   2.  Tech  /  Use   Case     Enum:   -­‐  Scanner   integra>on   (ePOS  HW)   -­‐  Varied   client   plaworms   -­‐  Adobe  Air   -­‐  EC2  Shared   Cloud   -­‐  Amazon  S3   Secure   Storage  
129. Prevalent Threats for AWS   Malicious Insider   Poor tenant segregation   Weak isolation criteria   Poorly defined security groups (virtual segmentation)   Insecure authentication storage   Poor change or configuration management   Errors in Elastic IP assignments to ‘accounts’   Non-hardened AMI files   Privilege escalation of shared software services   Compromised host/ service accounts   Data leakage via poor retention/ distruction practices   Insecure key storage DDoS Attacks