Building  a  Rube  Goldberg  Applica3on  Security  Program  

SOURCE  Boston  2011    Wendy Nather The 451 Group

451  Research  is  focused  on  the  business  of  enterprise  IT  innova3on.  The  company’s  analysts  provide  cri3cal  and  3mely  insight  into  the  compe33ve  dynamics  of  innova3on  in  emerging  technology  segments.  

The  451  Group  

Tier1  Research  is  a  single-­‐source  research  and  advisory  firm  covering  the  mul3-­‐tenant  datacenter,  hos3ng,  IT  and  cloud-­‐compu3ng  sectors,  blending  the  best  of  industry  and  financial  research.    

The  Up3me  Ins3tute  is  ‘The  Global  Data  Center  Authority’  and  a  pioneer  in  the  crea3on  and  facilita3on  of  end-­‐user  knowledge  communi3es  to  improve  reliability  and  uninterrup3ble  availability    in  datacenter  facili3es.  

TheInfoPro  is  a  leading  IT  advisory  and  research  firm  that  provides  real-­‐world  perspec3ves  on  the  customer  and  market  dynamics  of  the  enterprise  informa3on  technology  landscape,  harnessing  the  collec3ve  knowledge  and  insight  of  leading  IT  organiza3ons  worldwide.  

ChangeWave  Research  is  a  research  firm  that  iden3fies  and  quan3fies  ‘change’  in  consumer  spending  behavior,  corporate  purchasing,  and  industry,  company  and  technology  trends.    

The  Platonic  Ideal  of  an  applica3on  security  program  

The  Platonic  Ideal  of  an  applica3on  security  program  

The  Platonic  Ideal  of  an  applica3on  security  remedia3on  project  

The  Platonic  Ideal  of  an  applica3on  security  remedia3on  project  

The  Platonic  Ideal  of  an  applica3on  security  remedia3on  project  

How  it  really  happens  

  Training  • Onsite  classes  are  expensive  • Offsite  classes  are  even  more  expensive  •  You  can’t  pay  to  train  contractors  •  The  most  important  developers  can’t  make  it  to  the  classes  • Nobody  fires  up  the  e-­‐learning  applica3on  •  E-­‐learning  doesn’t  teach  developers  half  of  what  they  need  to  know  

How  it  really  works  

  Threat  modeling  and  security  requirements  •  It’s  not  in  any  story  •  Security  isn’t  just  in  the  applica3on  design  • Developers  make  bad  assump3ons  about  the  environment  for  their  applica3ons  

•  YOU  try  wri3ng  down  every  single  security  requirement  •  Security  requirements  are  new  and  can  be  every  bit  as  disrup3ve  as  new  func3onality  

•  Func3onal  requirements  change  mid-­‐project;  threat  modeling  and  security  requirements  have  to  be  re-­‐visited  

• Developers  will  ask  for  excep3ons  to  security  requirements  and  you  have  to  grant  them  and  track  them  

How  it  really  works  

  Peer  review  and  scanning  in  development  • Not  every  tool  will  scan  an  app  that  isn’t  built  •  Itera3ve  scanning  is  what  the  developer  wants  to  do,  but  it  takes  too  long  

•  The  development  environment  is  different  from  produc3on  •  The  security  team  becomes  a  bo\leneck  as  they  field  ques3ons  and  help  write  the  code  

•  There  are  s3ll  dependencies  on  other  insecure  applica3ons  and  insecure  libraries  

• Here  There  Be  Deadlines  

How  it  really  works  

  QA  tes3ng  •  They  don’t  want  security  tes3ng  messing  with  their  tes3ng  results  •  Itera3ve  scan-­‐fix-­‐rescan  cycle  too  short  for  many  tools  • QA  thinks  that  “security  tes3ng”  means  tes3ng  to  see  if  the  login  works  

• Verbose  error  messages  are  needed  for  troubleshoo3ng  •  Test  environment  s3ll  isn’t  the  same  as  in  produc3on  •  Those  short  deadlines  again  

How  it  really  works  

  The  Budget  Issue  • Once  a  project  is  done,  it’s  done  • Nobody  keeps  staff  siang  around  wai3ng,  in  case  there’s  an  applica3on  that  needs  remedia3ng  

• Remedia3on  of  an  app  can  be  a  full  project  in  and  of  itself  •  The  CIO  never  intended  to  touch  that  applica3on  again  •  Project  managers  rarely  budget  for  QA  3me,  much  less  for  security  tes3ng  

  Bo\om  line:    they  don’t  see  the  risk  

Scanner  1    

Scanner  2  

Scanner  3  

Scanner  1  

Scanner  2  

The  environment  

Single  sign-­‐on  

Roles  and  en3tlements  

App1   App2  

Roles  and  en3tlements  

App60  

Scanner  3  

Story  of  a  legacy  applica3on  

The  moral  of  the  story  

  Budget  isn’t  enough  (even  when  there’s  enough  budget)    Have  your  pieces  placed  in  the  right  order    Timing  is  everything    A  “15-­‐minute  fix”  –  isn’t    Running  an  applica3on  security  program  is  as  much  about  social  engineering  as  it  is  about  the  technical  side  

Thank  You