Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Attack-driven defense

44,034 views

Published on

Published in: Technology, Business

Attack-driven defense

  1. 1. A"ack-­‐Driven  Defense       zane@signalsciences.com     @zanelackey  
  2. 2. Who  am  I?   •  Co-­‐Founder/CSO  @  Signal  Sciences   •  Previously  built/led  the  Security  Engineering   group  @  Etsy   •  Prior  to  that,  offensive  research/pentesJng  @   iSEC  Partners      
  3. 3. This  talk  simply  isn’t  possible  without  a  number  of   people:   –  Ben  Hughes   –  Brendan  Adamson   –  Corey  Benninger   –  Kai  Zhong   –  Ken  Lee   –  Kyle  Barry   –  Marcus  Barczak   –  Mike  Arpaia   –  Omar  Ahmed        
  4. 4. Also  a  shout  out  to  secteams  we’ve  enjoyed   collaboraJng  with:     Facebook/GitHub/Google/Square/Twi"er  
  5. 5.   What  is  Etsy?        
  6. 6.      
  7. 7.   Etsy?  Security?  …  Why!?      
  8. 8.   Advanced  Persistent  Tapestries        
  9. 9.       This  talk  is  about  shiXing  from  historically                 un-­‐contextualized  defensive  approaches      
  10. 10.       To  building  defenses  around  real  world  a"ack   pa"erns        
  11. 11.       Un-­‐contextualized?        
  12. 12. Historically  defense  has:       – Focused  on  the  perimeter       – Deployed  commodity  security  products  that  don’t   address  real  a"ack  scenarios     – Treated  vulnerability  enumeraJon  (or  worse,   compliance)  as  “pentesJng”    
  13. 13.        These  don’t  address  modern  a"ack  behavior        
  14. 14.       What  should  we  be  doing?        
  15. 15. Fundamentally  we  have  three  goals:     1)  Raise  cost  to  a"ackers   2)  Increase  the  odds  of  detecJng  compromise   3)  Iterate  defenses  based  on  real  a"ack  pa"erns          
  16. 16.   Increasing  detecJon  
  17. 17.       Build  your  defenses  from  an  offensive  mindset        
  18. 18. Instrument  detecJon  mechanisms  around  key  areas  of   the  a"ack  chain:     •  IniJal  compromise   –  Defensive  rootkicng     •  Persistence/C2   –  Host  level   –  OrganizaJonal  level   •  Lateral  Movement   –  Network/systems  discovery     –  InformaJon  discovery  
  19. 19. IniJal  compromise  
  20. 20.       Rootkit  your  endpoints  before  your  a"ackers  do      
  21. 21.     Focus  on  the  combinaJon  of  system  behaviors   and  commands  executed  
  22. 22.     Specifically,  log  commands  executed  on   endpoints  and  analyze  this  data        
  23. 23.     Analyze  the  data  and  build  automaJc  alerJng   from  anomalies    
  24. 24.       Anomalies?    
  25. 25.     From  a  macro  level,  bucket  users  into     technical  vs  non-­‐technical    
  26. 26.   Pa"erns  then  break  down  into:       – Anomalous  if  by  a  non-­‐technical  user     – Anomalous  if  by  technical  user     – Always  anomalous      
  27. 27. Non-­‐Technical  bucket:     –  Alert  off  any  commands  which  show  technical  capabiliJes   •  It’s  either  an  a"acker  or  your  IT  team     Technical  bucket:     –  Treat  individual  commands  and  behaviors  as  low  quality   signals   •  Aggregate  commands,  look  for  unique  combinaJons  and  bursts   Always  anomalous  (both  buckets):     –  Analyze  a"ack  pa"erns  and  idenJfy  commands/behaviors   strongly  indicaJve  of  compromise   •  We’re  looking  at  you,  `uname  -­‐a`        
  28. 28. Non-­‐Technical  bucket:     –  Alert  off  any  commands  which  show  technical  capabiliJes   •  It’s  either  an  a"acker  or  your  IT  team     Technical  bucket:     –  Treat  individual  commands  and  behaviors  as  low  quality   signals   •  Aggregate  commands,  look  for  unique  combinaJons  and  bursts   Always  anomalous  (both  buckets):     –  Analyze  a"ack  pa"erns  and  idenJfy  commands/behaviors   strongly  indicaJve  of  compromise   •  We’re  looking  at  you,  `uname  -­‐a`        
  29. 29. Non-­‐Technical  bucket:     –  Alert  off  any  commands  which  show  technical  capabiliJes   •  It’s  either  an  a"acker  or  your  IT  team     Technical  bucket:     –  Treat  individual  commands  and  behaviors  as  low  quality   signals   •  Aggregate  commands,  look  for  unique  combinaJons  and  bursts   Always  anomalous  (both  buckets):     –  Analyze  a"ack  pa"erns  and  idenJfy  commands/behaviors   strongly  indicaJve  of  compromise   •  We’re  looking  at  you,  `uname  -­‐a`        
  30. 30.      Persistence    
  31. 31. Host  level  persistence:       – Look  for  common  pa"erns  of  persistence  via   programs  executed  on  boot,  kernel  modules   loaded,  etc  
  32. 32. Host  level  persistence:       – Look  for  common  pa"erns  of  persistence  via   programs  executed  on  boot,  kernel  modules   loaded,  etc   – Understand  that  in  pracJce  sophisJcated   persistence  mechanisms  won’t  be  detected     •  Aim  to  detect  the  basics,  and  increase  a"acker  cost  by   forcing  use  of  custom  persistence  mechanisms        
  33. 33.     Shout  out  to  @mimeframe  and  the  FB  secteam   for  their  work  on  BigMac:     h"p://www.slideshare.net/mimeframe/ ruxcon-­‐2012-­‐15195589    
  34. 34.     PresenJng  the  Etsy  version  of  a  host  IDS:    
  35. 35.     PresenJng  the  Etsy  version  of  a  host  IDS:     Tripyarn  
  36. 36.     Tripyarn’s  goal  is  to  alert  off  real  world  pa"erns   of  compromise  and  persistence  
  37. 37.     Lessons  learned  from  detecJng  hosJle   persistence  mechanisms  
  38. 38.     First,  find  the  legiJmate  OS-­‐provided   mechanisms  you’re  interested  in  instrumenJng  
  39. 39.     Treat  addiJons  to/modificaJon  of  these   mechanisms  as  an  event    
  40. 40. For  rare  events,  alert  on  every  occurrence   – Low  false  posiJve  cost       Ex:     – New  SSH  keys  being  added  to  a  host   – Crontabs  being  created     – etc  
  41. 41.     For  events  that  happen  oXen,  use  data   aggregated  across  the  organizaJon  to  detect   anomalies  
  42. 42.       Example:  Kernel  modules  
  43. 43. Goal:  Detect  a  malicious  kernel  module  loading   on  an  endpoint       – We  thought  kernel  modules  loading  would  be   fairly  rare  aXer  boot  and  we  could  alert  off  that   alone.  We  were  wildly  wrong.     – WhitelisJng/blacklisJng  kernel  module  names   wouldn’t  be  effecJve   – Instead,  analyze  a  kernel  module  being  loaded  for   organizaJonal  uniqueness      
  44. 44. Goal:  Detect  a  malicious  kernel  module  loading   on  an  endpoint       – We  thought  kernel  modules  loading  would  be   fairly  rare  aXer  boot  and  we  could  alert  off  that   alone.  We  were  wildly  wrong.     – WhitelisJng/blacklisJng  kernel  module  names   wouldn’t  be  effecJve   – Instead,  analyze  a  kernel  module  being  loaded  for   organizaJonal  uniqueness      
  45. 45. Goal:  Detect  a  malicious  kernel  module  loading   on  an  endpoint       – We  thought  kernel  modules  loading  would  be   fairly  rare  aXer  boot  and  we  could  alert  off  that   alone.  We  were  wildly  wrong.     – WhitelisJng/blacklisJng  kernel  module  names   wouldn’t  be  effecJve   – Instead,  analyze  a  kernel  module  being  loaded  for   organizaJonal  uniqueness      
  46. 46. Goal:  Detect  a  malicious  kernel  module  loading   on  an  endpoint       – We  thought  kernel  modules  loading  would  be   fairly  rare  aXer  boot  and  we  could  alert  off  that   alone.  We  were  wildly  wrong.     – WhitelisJng/blacklisJng  kernel  module  names   wouldn’t  be  effecJve   – Instead,  analyze  a  kernel  module  being  loaded  for   organizaJonal  uniqueness      
  47. 47.     “Did  module  X  that  just  got  loaded  on  endpoint  Y   get  loaded  on  less  than  N  systems  across  the   organizaJon  in  the  last  D  days?”          
  48. 48.     Use  a"ack  post-­‐exploitaJon  techniques  in  a   defensive  context  by  separaJng  your  objecJves   from  your  tooling        
  49. 49.     Specifically,  collect  data  on  the  endpoints  and   analyze/alert  from  that  data  on  the  server-­‐side      
  50. 50.     When  an  a"acker  discovers  and  analyzes  your   endpoint  security  mechanisms  they  shouldn’t  be   able  to  automaJcally  learn  all  alerts  in  place        
  51. 51. OrganizaJonal  level  persistence:     –  LegiJmate  remote  access  mechanisms  or  cloud   systems  with  data  desired  by  a"acker     •  Ex:  VPN  and  GMail         –  Use  a  mixed  approach  of  manual  and  automated   anomaly  detecJon  for  these  systems     •  GeneraJng  daily  rollups  of  new  accounts/keys  created   •  AlerJng  off  account  creaJon/modificaJon  at  unusual  Jmes,   from  unusual  locaJons,  etc        
  52. 52. OrganizaJonal  level  persistence:     –  LegiJmate  remote  access  mechanisms  or  cloud   systems  with  data  desired  by  a"acker     •  Ex:  VPN  and  GMail         –  Use  a  mixed  approach  of  manual  and  automated   anomaly  detecJon  for  these  systems     •  GeneraJng  daily  rollups  of  new  accounts/keys  created   •  AlerJng  off  account  creaJon/modificaJon  at  unusual  Jmes,   from  unusual  locaJons,  etc        
  53. 53.       Example:  GMail        
  54. 54. Goal:  Instrument  GMail  to  detect  compromise  of  domain   admin  accounts     –  GMail  provides  logs  of  interesJng  acJons  via  Admin  Audit   API  and  Email  Audit  API   –  Pull  down  logs  via  these  APIs,  store  them  locally  so  you   have  a  record  of  acJons     –  Perform  alerJng  on  strong  signals  of  compromise  and   persistence:   •  Signins  from  unusual  locaJons/Jmes   •  CreaJon  of  new  admin  level  accounts   •  CreaJon  of  new  mail-­‐forwarding  filters   •  Any  change  to  2FA  secngs     •  Etc    
  55. 55. Goal:  Instrument  GMail  to  detect  compromise  of  domain   admin  accounts     –  GMail  provides  logs  of  interesJng  acJons  via  Admin  Audit   API  and  Email  Audit  API   –  Pull  down  logs  via  these  APIs,  store  them  locally  so  you   have  a  record  of  acJons     –  Perform  alerJng  on  strong  signals  of  compromise  and   persistence:   •  Signins  from  unusual  locaJons/Jmes   •  CreaJon  of  new  admin  level  accounts   •  CreaJon  of  new  mail-­‐forwarding  filters   •  Any  change  to  2FA  secngs     •  Etc    
  56. 56. Goal:  Instrument  GMail  to  detect  compromise  of  domain   admin  accounts     –  GMail  provides  logs  of  interesJng  acJons  via  Admin  Audit   API  and  Email  Audit  API   –  Pull  down  logs  via  these  APIs,  store  them  locally  so  you   have  a  record  of  acJons     –  Perform  alerJng  on  strong  signals  of  compromise  and   persistence:   •  Signins  from  unusual  locaJons/Jmes   •  CreaJon  of  new  admin  level  accounts   •  CreaJon  of  new  mail-­‐forwarding  filters   •  Any  change  to  2FA  secngs     •  Etc    
  57. 57. Lateral  movement  
  58. 58. Focusing  on  two  areas  of  lateral  movement:     1.  Network/systems  discovery     2.  InformaJon  discovery          
  59. 59.     Use  endpoint  firewalls  as  a  detecJon   mechanism  (NOT  a  blocking  one)      
  60. 60.     Build  alerts  around  services  unused  on  your   network  but  likely  interesJng  to  a"ackers      
  61. 61.     By  alerJng  on  (but  not  blocking!)  traffic  you   don’t  immediately  signal  there’s  a  detecJon   mechanism  in  place      
  62. 62.     Also  endpoint  firewalls  counter  Jming-­‐based   evasions  
  63. 63.     Any  traffic  to  targeted  service,  no  ma"er  how   slow,  causes  alerts    
  64. 64. InformaJon  Discovery  
  65. 65.     What  internal  systems  provide  informaJon  that   help  an  a"acker  achieve  their  goals?  
  66. 66.              -­‐  Wikis              -­‐  Source  control                -­‐  Bug  tracking              -­‐  Etc      
  67. 67.     Instrument  these  systems  the  way  you  would   other  high-­‐value  pieces  of  infrastructure    
  68. 68. Alert  off  behavioral  anomalies  such  as:   –  Usage  outside  of  normal  hours     •  Your  a"ackers  are  rarely  in  your  Jme  zone   –  Bursts  of  acJvity     •  Viewing  all  security  Jckets  in  the  bug  tracker  isn’t  even  done   by  the  security  team   –  Etc      
  69. 69. Increasing  a"acker  cost  
  70. 70. Make  compromise  more  expensive     – We’ll  discuss:   •  Reducing  trusted  CA  roots   •  Removing  cheap  exploitaJon  vectors     •  Forcing  updates  without  the  force   •  LimiJng  drive-­‐by  exposure     •  PracJcal  goals  for  security  awareness  training        
  71. 71. How  can  you  reduce  the  likelihood  of  a   DigiNotar-­‐like  MITM  happening  against  your   organizaJon?    
  72. 72. If  you  remove  unused  CAs,  when  one  is   compromised  it  can’t  silently  MITM  your   endpoints  
  73. 73. We  performed  several  months  of  anonymized   traffic  analysis  to  record  what  CAs  were  seen   during  our  employees  Internet  usage  
  74. 74. We  found  less  than  29%  of  SSL  CerJficate   AuthoriJes  trusted  by  our  endpoints  were   actually  used  
  75. 75. 21.29%    EQUIFAX  SECURE  CERTIFICATE  AUTHORITY   10.37%    ENTRUST.NET  SECURE  SERVER  CERTIFICATION  AUTHORITY   10.07%    DIGICERT  HIGH  ASSURANCE  EV  ROOT  CA   8.97%      GO  DADDY  CLASS  2  CERTIFICATION  AUTHORITY   7.91%      GEOTRUST  GLOBAL  CA   7.23%      ADDTRUST  EXTERNAL  CA  ROOT   6.48%      HTTP://WWW.VALICERT.COM/   6.04%      GTE  CYBERTRUST  GLOBAL  ROOT   4.45%      VERISIGN  CLASS  3  PUBLIC  PRIMARY  CERTIFICATION  AUTHORITY  -­‐  G5   4.08%      CLASS  3  PUBLIC  PRIMARY  CERTIFICATION  AUTHORITY   3.82%      BALTIMORE  CYBERTRUST  ROOT   3.22%      CLASS  3  PUBLIC  PRIMARY  CERTIFICATION  AUTHORITY  -­‐  G2   1.37%      THAWTE  PRIMARY  ROOT  CA   1.36%      THAWTE  PREMIUM  SERVER  CA   1.33%      ENTRUST.NET  CERTIFICATION  AUTHORITY  (2048)   0.65%      GLOBALSIGN  ROOT  CA     [The  CAs  which  had  <  0.5%  traffic  have  been  edited  out  for  brevity.     More  info  here:  h"p://codeascraX.com/2013/07/16/reducing-­‐the-­‐roots-­‐of-­‐some-­‐evil/]   Our  raw  results:    
  76. 76.   By  removing  only  unused  CAs  you  don’t  teach   users  to  click  through  SSL  errors     ConJnue  traffic  analysis,  add/remove  trusted   CAs  as  appropriate  
  77. 77.                            in  the  browser  is:  cheap,  reliable,  and   efficient  (pick  three!)        
  78. 78.                            in  the  browser  is:  cheap,  reliable,  and   efficient  (pick  three!)                                  …for  a"ackers      
  79. 79. What  did  we  learn  when  we  removed  Java  web   plugins  from  the  enterprise?    
  80. 80. •  Hardly  any  groups  actually  needed  it     – Network  OperaJons,  for  legacy  networking   equipment     •  For  them,  we  built  dedicated  Java  jump  boxes      
  81. 81. Benefits:     1.  No  Java  on  any  laptops/desktops   2.  Boxes  with  Java  can’t  hit  Internet   3.  Able  to  frequently  re-­‐image  jump  boxes   4.  Only  a  few  boxes  to  patch    
  82. 82.   But…     Java  shows  back  up  when  you  apply  Apple   patches.    
  83. 83.   But…     Java  shows  back  up  when  you  apply  Apple   patches.     Remove  it  on  an  ongoing  basis        
  84. 84.    
  85. 85.         Browser  updates      
  86. 86.       We  wanted  a  less  heavy  handed  approach  to   ensuring  up  to  date  browsers      
  87. 87.       Built  browser  detecJon  logic  into  our  internal   SSO  point      
  88. 88.     UX  is  key:     Show  in  screenshots  how  quick  it  is  to  update,   provide  a  bypass  mechanism        
  89. 89.       Simply  asking  users  to  update  works  shockingly   well        
  90. 90.    
  91. 91.   Funny  story,  users  will  install  malware  because   an  ad  popup  told  them  to.    
  92. 92.   Funny  story,  users  will  install  malware  because   an  ad  popup  told  them  to.     O8en.        
  93. 93.   You  can  almost  enJrely  kill  this  source  of   compromise  (for  free!)  by  pushing  adblocker   plugins  to  the  organizaJon      
  94. 94. Security  awareness  training  
  95. 95.     Historically  we’ve  focused  on  reducing  the   number  of  people  who  fall  for  phishing  
  96. 96.     Historically  we’ve  focused  on  reducing  the   number  of  people  who  fall  for  phishing   This  is  the  wrong  goal  
  97. 97.     If  you  go  from  being  36%  on  fire  to  27%  on  fire   you’re  s;ll  on  fire      
  98. 98.   Instead,  focus  on  incenJvizing  users  to:          
  99. 99.   The  metric  to  track/increase  is  the  likelihood  of   phishing  emails  being  reported  to  security       Even  if  36%  sJll  fall  for  phishing,  as  long  as  one   in  the  group  reports  it  IR  can  begin  
  100. 100. XXX               Running  effecJve  a"ack  simulaJons      
  101. 101.     Problems  with  “pentesJng”  are  well  understood   in  the  offensive  community  but  not  as  well  in   the  defensive  community    
  102. 102.     Pentests  typically  result  in  a  list  of  enumerated   known  vulnerabiliJes  to  be  patched,  not  data  on   how  a  real  a"acker  would  operate  against  a   given  environment      
  103. 103.   A"ack  simulaJons  should  be  done  to  learn  how   a"ackers  are  likely  to  achieve  goals  against  your   organizaJon     NOT  to  show  compromise  is  possible   (spoiler  alert:  it  is.)    
  104. 104.     Use  this  a"ack  data  to  focus  where/how  to  build   detecJon  mechanisms  
  105. 105.     From  an  organizaJonal  side,  a"ack  simulaJons   compliment  vulnerability  enumeraJon/ compliance/etc    
  106. 106.     Vulnerability  enumeraJon/compliance  are   checklists  to  make  sure  you’re  covering  the   basics    
  107. 107.     But  checklists  aren’t  owning  you,  a"ackers  are  
  108. 108. Four  keys  to  effecJve  a"ack  simulaJons:     –  Goal  oriented   •  “Obtain  domain  admin”,  “read  the  CEOs  email”,  “view  credit  card  data”,  …     –  Full  organizaJon  in  scope   •  Have  a"ack  team  call  a  contact  if  they’re  about  to  do  something  risky   –  Simulate  realisJc  compromise  pa"erns     •  Start  the  a"ack  team  on  a  standard  laptop/desktop  endpoint  inside  the   organizaJon  to  simulate  phishing/clientside  compromise     •  Start  the  a"ack  team  on  a  database  or  web  server  to  simulate  SQL  injecJon/ RCE   •  A"ack  team  should  be  encouraged  to  use  0days   –  Break  simulaJon  down  into  iteraJons:   •  Don’t  spend  the  full  engagement  Jme  on  only  round  of  tesJng,  once  one  team   achieve  goal(s),  then  swap  in  new  a"ack  team  to  achieve  the  same  goal(s)     –  Ex:  We  try  to  run  3-­‐4  iteraJons  per  several  week  simulaJon  
  109. 109. Four  keys  to  effecJve  a"ack  simulaJons:     –  Goal  oriented   •  “Obtain  domain  admin”,  “read  the  CEOs  email”,  “view  credit  card  data”,  …     –  Full  organizaJon  in  scope   •  Have  a"ack  team  call  a  contact  if  they’re  about  to  do  something  risky   –  Simulate  realisJc  compromise  pa"erns     •  Start  the  a"ack  team  on  a  standard  laptop/desktop  endpoint  inside  the   organizaJon  to  simulate  phishing/clientside  compromise     •  Start  the  a"ack  team  on  a  database  or  web  server  to  simulate  SQL  injecJon/ RCE   •  A"ack  team  should  be  encouraged  to  use  0days   –  Break  simulaJon  down  into  iteraJons:   •  Don’t  spend  the  full  engagement  Jme  on  only  round  of  tesJng,  once  one  team   achieve  goal(s),  then  swap  in  new  a"ack  team  to  achieve  the  same  goal(s)     –  Ex:  We  try  to  run  3-­‐4  iteraJons  per  several  week  simulaJon  
  110. 110. Four  keys  to  effecJve  a"ack  simulaJons:     –  Goal  oriented   •  “Obtain  domain  admin”,  “read  the  CEOs  email”,  “view  credit  card  data”,  …     –  Full  organizaJon  in  scope   •  Have  a"ack  team  call  a  contact  if  they’re  about  to  do  something  risky   –  Simulate  realisJc  compromise  pa"erns     •  Start  the  a"ack  team  on  a  standard  laptop/desktop  endpoint  inside  the   organizaJon  to  simulate  phishing/clientside  compromise     •  Start  the  a"ack  team  on  a  database  or  web  server  to  simulate  SQL  injecJon/ RCE   •  A"ack  team  should  be  encouraged  to  use  0days  throughout  engagement   –  Break  simulaJon  down  into  iteraJons:   •  Don’t  spend  the  full  engagement  Jme  on  only  round  of  tesJng,  once  one  team   achieve  goal(s),  then  swap  in  new  a"ack  team  to  achieve  the  same  goal(s)     –  Ex:  We  try  to  run  3-­‐4  iteraJons  per  several  week  simulaJon  
  111. 111. Four  keys  to  effecJve  a"ack  simulaJons:     –  Goal  oriented   •  “Obtain  domain  admin”,  “read  the  CEOs  email”,  “view  credit  card  data”,  …     –  Full  organizaJon  in  scope   •  Have  a"ack  team  call  a  contact  if  they’re  about  to  do  something  risky   –  Simulate  realisJc  compromise  pa"erns     •  Start  the  a"ack  team  on  a  standard  laptop/desktop  endpoint  inside  the   organizaJon  to  simulate  phishing/clientside  compromise     •  Start  the  a"ack  team  on  a  database  or  web  server  to  simulate  SQL  injecJon/ RCE   •  A"ack  team  should  be  encouraged  to  use  0days  throughout  engagement     –  Break  simulaJon  down  into  iteraJons:   •  Don’t  spend  the  full  engagement  Jme  on  only  round  of  tesJng,  once  one  team   achieve  goal(s),  then  swap  in  new  a"ack  team  to  achieve  the  same  goal(s)     –  Ex:  We  try  to  run  3-­‐4  iteraJons  per  several  week  simulaJon  
  112. 112.     The  project  output  should  be  a>ack  chains  showing   how  a"ack  team  went  from  A-­‐>B-­‐>C  to  achieve   goals,  what  steps  they  took  and  why    
  113. 113.     Just  as  importantly,  what  steps  they  didn’t  take     Ex:  “We  didn’t  try  to  find  internal  network  diagrams  on   your  wiki  because  zone  transfers  were  enabled  so  we   could  got  enough  data  about  your  network  from  that”        
  114. 114.     Remember,  the  goal  is  to  simulate  realisJc   a"ack  behaviors  and  pa"erns  that  can  be  used   to  enhance  detecJon  
  115. 115.     In  addiJon,  simulate  varying  a"ack  profiles  from   quick  &  noisy  to  quietly  maintaining  persistence      
  116. 116.     Over  mulJple  iteraJons  learn  what  behaviors   overlap  between  a"ackers  and  what  strong   signals  of  lateral  movement  in  your  environment   look  like    
  117. 117. TL;DR   (The  secJon  formerly  known  as  “Conclusions”)        
  118. 118. Defend  like  an  a"acker      
  119. 119.     Where  should  defense  focus?       –  Increase  a"acker  cost  by  reducing  cheap  compromise   vectors   –  Build  detecJon  mechanisms  around  real  a"ack   pa"erns   •  Analyze  past  compromises,  new  offensive  research,  and   conduct  realisJc  a"ack  simulaJons  to  obtain  data   –  Depending  on  scale,  have  true  offensive  capabiliJes  on  staff  or  a   call  away   –  Have  product/tooling  development  capabiliJes  within   your  security  team   •  Roughly  one  quarter  of  our  team  is  soXware  engineers  who   focus  on  building  internal  security  products  
  120. 120. Thanks!   zane@signalsciences.com                      @zanelackey    

×