Streamlining AppSec Policy Definition.pptx


Published on

This presentation offers insight on defining appsec policies, highlighting the differences from InfoSec policy, attributes of effective policy and how to make policies actionable so they map to an organization's overall security and business processes.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Streamlining AppSec Policy Definition.pptx

  1. 1. Managing Software Security Risktreamlining AppSec Policy Definition and Implementati For Chicago Security Meetup April 18, 2013 m  Bain   ector,  Product  Marke4ng  curity  Innova4on  
  2. 2. ector,  Product  Marke0ng,                                  curity  Innova0on   merly  with  Q1  Labs  (an  IBM  Company)  d  Applica0on  Security,  Inc.  0ve  blogger,  presenter   ,  Communica0ons,  RIC;  MS,  Interna0onal   a0ons/Public  Affairs,  UMASS   Thomas  Ba
  3. 3. Why  SoOware  Security?     ts/Trends    vs  IT  Sec  Need   portance  of  Priori0zing  AppSec   ifferences  Between  App  &  IT  Sec   olicy   remental  policy  construc0on   al-­‐world  policy  improvement   escrip0ve  mapping  to  compliance  Map  AppSec  to  Compliance  Ac0vity   ecommenda0ons   eps  you  should  consider  
  4. 4. plication Security Experts +  Years  vulnerability  research    curity  Tes0ng  Methodology  adopted  by  SAP,                crosoO,  Symantec   thors  of  8+  books   ducts and Services andards  -­‐  Best  Prac0ces   uca0on  -­‐  CBT  &  Instructor-­‐Led  sessment  -­‐  SoOware  and  SDLC  ducing Application Security Risk 0cal  Vulnerability  Discovery  cure  SDLC  Rollout  
  5. 5. I. Why Software Security
  6. 6. Secure at the Protect in Find and Fix Source Production Ø  Education Ø  Vulnerability Scanning Ø  Firewalls Ø  Remediation Ø  Manual Assessments Ø  Whitelisting Ø  Secure Coding Ø  “Whack-A-Mole” Ø  “Band Aid” Standards
  7. 7. • 97% of breaches were avoidable through the use of simple controls. • 2012: 174M records breached. • Cost of a breach: $214/record, and $7.2M average overall cost to organization.
  8. 8. We Still Need to Bridge this Ga 71% 57% 53% Sec 41% Dev 36% 21%Process in place for building Little or no collaboration between Have no formal mandate in place security into applications the two groups for fixing vulnerable code
  9. 9. Software Apps Are Vulnerable d their company has experienced between 1-10 data breaches oveast 24 months as the result of an application(s) being compromised
  10. 10. s  lose  autonomy  with   rity  policies  that  aren’t  well-­‐ ned.   ormance  +  capabili0es  oOen  mp  security  =  IT  headache.     s  expect  an  always-­‐on,   re  connec0on  and   0onality   e  to  market  pressures  hurt   rity:  But  good  architecture   backend  systems  can  help.    frameworks  can  help  you   o  market  quickly  can  
  11. 11. II. AppSec vs InfoSec Policy
  12. 12. The CIA Triad th  have  policies,  standards,  procedures  orma0on  Security  revolves  around  the  mous  CIA  triad  Maintain  the  confiden0ality,  integrity,  and   vailability  of  informa0on  stored  in  networks   nd  data    communica0ons  infrastructure     ny  so.ware  to  be  considered  secure  it  must  conform  to  these  broad  and  high  level  characteris7cs  Vague  industry  standards  that  integrate  these  three  security  characteris0cs  in  an  iden0fiable  and  auditable  manner  for  soOware  SoOware  applica0ons  access  informa0on  unencrypted,  so  policy  around  protec0on  has  to  be  even  more  prescrip0ve  
  13. 13. Information Security Application Security Based Receptionist, IT Manager, • Architect, Developer, Tester etc • Application Roles and Privileges w to Rollout and Rollout of web application firewall and secure ement configuration of servers, development best practices databases, anti-virus, • Application Authentication checks communications, • Secure Design components certificates, etc. • Attack surface reduction • Code hardening • Data Encryption • Input validation ertise IT networking, database • How applications interact with environment ded to and computer/OS • How applications function and fail with respeement configuration skills security • Software development skills w/ security over
  14. 14. SQL Injection Policy ✔  MINIMUM   uild  web  applica0ons  that  defend  against  SQL  injec0on  agacks.  ✔✔  BETTER   uild  web  applica0ons  that  defend  against  SQL  injec0on  agacks  by  sani4zing  all  use put.    ✔✔✔  GOOD   uild  web  applica0ons  that  defend  against  SQL  injec0on  agacks  by  sani0zing  all  use put  using  this  approved  sani4za4on  rou4ne.  ✔✔✔✔  EXCELLENT  …   •  SoOware  Developers  do  X   •  SoOware  Testers  do  Y    
  15. 15. Protect Sensitive Data  MINIMUM  otect  sensi0ve  data.     ✔  BETTER  otect  sensi0ve  data  by  using  this  approved  encryp4on.   ✔✔  GOOD  otect  sensi0ve  data  by  using  this  approved  encryp0on  in  databases  that  store  and  ring  transmission  of  sensi4ve  data.   ✔✔✔ EXCELLENT  plus  •  Architects  define  algorithms.  •  Developers  never  write  their  own  crypto.  •  Test/QA  verifies  XYZ.  
  16. 16. Cross-Site Forgery MINIMUM  ate  applica0ons  that  are  resilient  to  Cross-­‐Site  Request  Forgery.     BETTER  ate  soOware  applica0ons  that  are  resilient  to  CSRF  agacks  by  using  the  OWASP  TopRF  Cheat  Sheet.”    ✔✔  GOOD  ate  soOware  applica0ons  that  are  resilient  to  CSRF  agacks  by  using  the  OWASP  Top CSRF  Cheat  Sheet”  and  implement  a  language-­‐appropriate  framework.    ✔✔✔ EXCELLENT   us   Use  challenge-­‐response.   QA  check  reference  headers.  
  17. 17. App Pen Testing icy:  Conduct  annual  tests  of  internet  facing  applica0ons.”  w  to  improve  it  pecify  the  type  of  test,  e.g.,  web  vulnerability  can,  source  code  review,  paper  audit,  etc.   ow  deep  should  it  go  /  What  should  be  tested?  Ø OWASP  Top  10  vulnerabili0es   efine  the  key  assets  you  are  trying  to  protect.  pecify  which  agacks  should  be  conducted.  Ø Threat  modeling  in  advance  can  guide  you  here.  
  18. 18. icy   Ensure  applica0ons  processing  data  properly  authen0cate   sers  through  central  authen0ca0on  systems  where  possible.”   If  addi0onal  func0onality  is  needed,  coordinate  development  with  Informa0on  Technology  Services.”     w  to  improve  it   ere  is  our  approved  authen0ca0on  library  URL.   emove  ambiguity.      “Coordinate  with  ITS.”  Rather,  obtain  wrigen  excep0on  for   using  any  authen0ca0on  mechanism  not  explicitly  approved   by  InfoSec  Office    Ø “where  possible”  
  19. 19. cy   QL  Injec0on  vulnerabili0es  must  be   evented.”   e  OWASP  QL_Injec0on_Preven0on_Cheat_Sheet    for   commenda0ons.    to  improve  it   e  Parameterized  SQL  statements  and  stored   ocedures.   e  white-­‐lis0ng  to  constrain  user  input.   e  company-­‐approved  sanita0on  library,     und  here  URL.  
  20. 20. III. Map AppSec to Compliance Initiatives
  21. 21. terprise  Risk  Management,  HR,  and  Legal  define  the  global   pe,  objec7ves  and  requirements  for  corporate  vernance  Applicable  legisla0on  (Sarbanes-­‐Oxley,  HIPAA,  California  SB   386)  ndustry  standards  (ISO  2700x,  FISMA/NIST  standards)   ompliance  mandates  (PCI  DSS)  egal  and  human  resources  requirements  (data  privacy  aws)   oten0al  impacts  of  security  breaches   osts  of  security  breaches  and  agacks  
  22. 22. M,  GRC    Security  teams  add  detail  to  create  policies  igh-­‐level  guidelines  for  opera0onal  security  and  compliance  c0vi0es  an  be  contextualized  for  specific  business  units  and  func0onaloles   ical  tasks  include:  tudying  the  applicable  regula0ons  and  standards  onduc0ng  a  threat  assessment  to  determine  the  security  breaoten0ally  most  damaging  to  the  enterprise  lassifying  data  assets  to  define  levels  of  data  sensi0vity   efining  concrete  applica0on  security  objec0ves  
  23. 23. curity    Compliance  teams  define  specific  development   ocesses,  coding  prac7ces,  and  procedures  for  compliance  ocumenta7on   Ensures  they’re  relevant  to  local  requirements  and  technology and  consistent  with  corporate  security  and  compliance  policie Address  regional  and  business-­‐unit  specific  regula0ons  and  th technologies  used  by  each  team  ontextualizing  policies  for  each  team  can  be  a  labor-­‐intensivend  deeply  technical  process   Saves  a  TON  of  0me  long-­‐term   Reduce  risk  over  0me  with  specific    prac0cal  the  guidance  
  24. 24. The Compliance Matrix vel Other Standards Selected Coding Practices ent (Partial List)lity SOX, HIPAA, ISO - Appropriate use of strong encryption for data in databases. 27002,, GLBA, - Encrypting confidential data in memory. No custom or untrusted encryption routines FFIEC, Basel l I, - Encrypting data in motion, especially for wireless transmissions. CA SB 1386, FIPS - Masking confidential data that needs to be viewed in part 199, NISTty SOX, ISO 27002, - Robust integrity checks to prevent tampering with data. HIPAA, GLBA, - Input validation and comprehensive error handling to prevent injection attacks, privil FIPS 199, NIST escalation, and other hacking techniques. - Output encoding. Use of least privileges. - Hashing for confidential data that needs to be validated (e.g. passwords)ion SOX, ISO 27002, - Support for strong passwords two-factor authentication where appropriate. HIPAA, II, NIST - Role-based access control and revocation of rights, with clear roles mapped to perm SP - Locked down file access and database roles. No guest accounts. - Passwords and encryption keys encrypted before storage and transmission.d SOX, ISO 27002, - Detailed audit trails of users accessing data and resources. HIPAA, SB 1386, - Detailed logging of systems that process sensitive data, including shutdowns, restar NIST SP unusual events. No confidential data exposed in logs. - Event logs and audit trails available only to system admins and protected from unau modifications.
  25. 25. IV. Streamline AppSec PolicyDevelopment to Fit Your Busines
  26. 26. onsider  risk  scenarios.   dapt  from  proven  or  trustworthy  models.  Measure  percep0on.   nderstand  roles/privileges.   et  granular.   gure  out  a  strategy  for  tes0ng  your   pplica0ons.     onsider  BYOD.     olicy  enforcement.   aise  awareness/required  training.  
  27. 27.  an  inventory  of  your  high-­‐risk   ica0ons.  ermine  business  cri0cality.     t’s  your  agack  probability?    do  you  define  the  agack  surface?  sider  overall  business  impact.   re  does  compliance  factor  in?   t  are  the  security  threats?  
  28. 28. njec0on   •  A6  Sensi0ve  Data  ExposureBroken  Authen0ca0on  and   (merged  from  former     ion  Management     •  A7  Insecure  CryptographicCross-­‐Site  Scrip0ng  (XSS)  (was   Storage  merly  A2)   •  A8  Cross-­‐Site  Request  Forgnsecure  Direct  Object   (CSRF)  erences   •  A9  Using  Known  Vulnerabl ecurity  Misconfigura0on  (was   Components  merly  A6)   •  A10  Unvalidated  Redirects Forwards  
  29. 29. tudes  of  general  popula0on  toward  urity  (suppor0ve,  antagonis0c,  fferent?)  tudes  of  general  popula0on  toward  nagement  (suppor0ve,  antagonis0c,  fferent?)    w  does  management  view  the  c0on  of  security?  at’s  the  percep0on  of  current  cy?  e  there  been  related  security  dents?    
  30. 30. h  departments/groups/individuals    been  most  ac0ve  in  developing  ies?     ous  collabora0on  between  policies  authors?  n0al  champion(s)  to  support?    s  of  agreement  in  commonly  emented  controls  re:  policies?  ort  docs,  materials  and  related  ies  should  be  cited  in  mobile  device  y.    to  understand  user  access  and   eges.  
  31. 31. hich  applica0ons  would  be  used?   w  will  web  applica0ons  be  used?  hat  will  access  and  levels  of  privilege  look  like?    hat  informa0on  is  accessible  through  web  applica0ons?    hat  informa0on  will  be  stored  on  web  applica0ons?     w  will  data  be  shared  to/from  web  applica0ons?    ho’s  ul0mately  responsible  for  applica0on  security?    hich  applica0ons  are  acceptable  to  use?    hich  applica0ons  should  not  be  used?  hat  levels  of  support  are  expected?    
  32. 32.  sensi0ve  is  your  data?   t  kind  of  data  is  it?  PII,  customer   ,  credit  card  data,  proprietary,  IP,  subject  to  regulatory  mandates?  ch  ones?  you  encryp0ng  data?  At  rest?  In  sit?  duct  a  threat  model:   termine  threats  en0fy  poten0al  agacks  nderstand  the  frequency    severity   th  which  they  are  executed.  
  33. 33. Application Criteria hreat Sensitive Compliance Custo Lifespan ating Data Stringency Faciier 1 Restricted Long High Yeier 2 Private Mid Medium Yeier 3 Public Short N/A No
  34. 34. Depth, Breadth, Frequency reat Static Dynamic Manual Pen Threting Analysis Analysis Test Mode Complete/ Complete/ Complete/ Compl Frequency Frequency Frequency Freque Required/Major Required/Major Required/Per Requireer 1 code changes code changes Milestone Relea Suggested/ Required/ Required/Per Suggesteer 2 Monthly Quarterly Release Relea Optional/ Required/ Optional/As Optioner 3 Quarterly Annually Needed Need
  35. 35. ile  devices  help  employees  increase  uc0vity  –  staying  connected  is  not  y  op0onal  anymore!  ge  has  experienced  a  massive  up0ck:    of  today’s  workforce  is  using  a  rtphone  specifically  for  business  use.   struggling  to  keep  up  with  device   agement.   ility  by  its  nature  opens  up  a  larger  ck  surface  with  more  points  of  entry.  cult  to  measure  business  need  ugh  IT  Security  lens.  
  36. 36. %  use  the  same  smartphone  for  rk  and  for  personal  usage.  %  of  employed  adults  use  at  st  one  personally  owned  ctronic  device  for  business   rris  Interac0ve  survey,   ruary  2012)  %  of  employees  surveyed  use  bile  devices  to  run  line-­‐of-­‐ iness  applica0ons  (Ibid)  %  of  companies  allow  BYOD   ge  in  some  manner  (Aberdeen   up,  February  2011)  
  37. 37. %  of  companies  have  experienced  ata  breach  due  to  inadequate   ice  security  (Ponemon  survey,   2)  %  don’t  have  a  password  on  their  bile  phone.  %  stated  their  companies  couldn’t   cute  a  remote  wipe  if  lost  or   en.  %  said  mobile  security  has  not   n  addressed  with  them  by  IT.  
  38. 38. Why is BYOD a Security Problem evice  turn-­‐over:  What  happens  to  the  old  device?     ew  devices:  Default  or  customized  se|ngs?   ow  can  you  know  everything  about  every  device?   Oware  updates  –  user  vs  IT.   pp  Stores:  Approved  apps?     pplica0ons:   What  data  is  on  your  device?   What  enterprise  applica0ons  can  you  connect  to?   Which  apps  are  connected  to  other  apps?  EX:  Your  blog  app  is connected  to  your  CMS,  which  feeds  to  Twiger,  etc.    
  39. 39. Device Security consistent  security  policies   ptop  encryp0on  bypass  mode  nmanageable  devices   ared  media  leakage   inimal  device  management  eadable  data  on  disposed-­‐of  evices  ter-­‐applica0on  data  leakage  
  40. 40. bile Traditionalnerabilities Vulnerabilities
  41. 41. scribes  contextual,  technical  guidelines  on  how  security  shou integrated  within  the  SDLC   y  phase,  role,  technology,  applica0on  type   everages  internal  secure  development  champion(s)  for  input   ps  to  compliance  mandates  nsiders  cri7cality  of  applica7on  and  data   equirements,  ac0vi0es  and  level  of  detail  needed  will  differ  s  a  clear  excep7on  policy  What  if  minimum  standards  can’t  be  met?  What  is  considered   cceptable?  Who  approves?   ludes  internally  built  and  third  party  applica7ons  flects  current  maturity  and  secure  development  skills  
  42. 42. u  need  management  buy-­‐in!  oad  strategy  vs  Targeted  strategy  roll-­‐out  n-­‐boarding:    Require  policy  training  up  front   quire  training  for  various  departments:  General  popula0on  receives  awareness  training  Technical  employees  receive  in-­‐depth  training  onitor  for  effec0veness  –  EX:  Deliver  training  or  reminder  hen  employee  is  out  of  compliance.    
  43. 43. Thank You!!   TwiTer:  @tmbainjr1