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.

A journey into Application Security

A journey into application security will cover the relation and evolution of application security with the different approaches to development from Waterfall to Devops.

  • Login to see the comments

A journey into Application Security

  1. 1. A  Journey  into  Application   Security Christian  Martorella ISACA  Italy  2014 Venezia,  3rd October
  2. 2. Who  am  I • Principal  Program  Manager,  Product  Security Skype  – Microsoft • Edge-­‐Security:  Wfuzz,  theHarvester,  Metagoofil,  Webslayer • Presented  in  many  Security  conferences:,  BlackhatArsenal,   Source,  OWASP  Summit,  OSIRA • CIS(A,M,SP),  OPS(T,A)  
  3. 3. My  background • Started  as  internal  security  auditor  (Offensive) • System  and  network  security  responsible  of  a  small  ISP  (Defensive) • Penetration  tester  -­‐>  Team  leader  (Offensive) • Practice  lead  for  Threat  and  Vulnerability  in  EMEA  (Offensive) • Product  Security  Analyst  in  Skype  (Defensive)
  4. 4. Introduction This presentation is about the evolution of software development and the relation with Applicationsecurity. How application security teams adapted over time and the challenges we are facing
  5. 5. Waterfall  development
  6. 6. Waterfall  development • Originated  from  the  manufacturing  and  construction  industries.   • Hardware  oriented  model  adapted  to  Software  development • Sequential  design  process • Introduced  by  Winston  Royce  in  the  ’70
  7. 7. Waterfall  development • Make  sure  each  phase  is  100%  complete  and  absolutely  correct   before  proceeding  to  the  next  phase • Emphasis  on  documentation • Project  span  across  long  period  of  time • Time  spent  early on  making  sure  requirements and  design are  correct saves  much  time  and  effort  later.
  8. 8. Application  Security Microsoft  Secure  Development  Lifecycle  (SDL) Set  of  software  development  process  improvements Born  in  2002  and  established  in  2004,  as  result  of  MS  Trustworthy  Computer   (TWC)  initiative. More  than  50%  less  vulnerabilities  in  shipped  code
  9. 9. SDL  Methodologies
  10. 10. SDL  evolution
  11. 11. Security  approach Influence  in  the  Design  phase: • All  functional  and  design  specifications,   regardless  of  document  size,  should   contain  a  section  describing  how  the  component  impacts  security • Threat  Modeling:  Understand  assets  to  protect,  threats  and  vulnerabilities   to   the  product  and  how  will  be  mitigated.  Critical  to  create  a  secure  software Most  important  phase  in  Waterfall
  12. 12. Security  approach Development  phase: Implement  security  tools:   • Static  analysis,  Banned  Apis,  FxCop,  /Analyze Implement  security  checklist Secure  coding  best  practices Verification  /  Release  phase: Fuzzing Verify  /  validate  Threat  Model Final  security  review  (FSR) Security  testing  by  another  team  or  third  party
  13. 13. Challenges • Lack  of  security  requirementsin  design  phase  will  make  it  difficult  to  add   them  in  later  stages • Non  iterative  nature  makes  difficult  to  fix  issues  identified  in  advanced   stages  of  development • Issues  detected  in  the  Final  review,  will  be  expensive  to  fix
  14. 14. Agile  development
  15. 15. Agile  development • Cross  functional  teams,  self  organizing • Short  time  boxed  development  iterations • Delivery  of  small  functional  stories • Listen  to  customer  needs  and  adapt • Usually  low  in  documentation
  16. 16. Agile  Manifesto Individuals  and  interactionsover  processes  and  tools Working  software  over  comprehensive  documentation Customer  collaboration  over  contract  negotiation Responding  to  change  over  following  a  plan That  is,  while  there  is  value  in  the  items  on the  right,  we  value  the  items  on  the  left  more.
  17. 17. Challenges • SDL  too  complex  to  fit  in  each  release/Sprint • Design,  requirements  evolve  over  time • New  interactions  with  third  parties  are  not  known  in  advance • Teams  usually  don’t  have  an  Application  Security  specialist • Teams  move  faster  than  Waterfall • New  code  is  being  pushed  to  production  every  week  or  even  days. • Low  on  documentation
  18. 18. SDL  for  Agile
  19. 19. SDL  for  Agile The  categorization  of  SDL  requirements  into: • every-­‐sprint • one-­‐time • Three  bucket  groups  (Verification,  design,  Response) is  the  SDL-­‐Agile  solution  for  dealing  with  SDL  in  Agile  environments
  20. 20. Recommendations • Training  the  teams  and  providing  them  with  tools  is  the  most   important  aspect  in  order  to  implement  SDL  in  Agile  teams • Security  specialist  assigned  to  a  few  teams,  to  provide  consultancy • Useful  to  participate  in  Sprint  planning  to  understand  what  is  going   on • Sprint  Security  Checklist  (FSR),  after  Sprint  planning • Get  familiar  with  Agile  tools,  backlog.
  21. 21. SDL  for  Agile • Continuous  Integration  (Automation):   Secure  Code  analysis Security  unit  test Vulnerability  scanning Secure  configuration
  22. 22. Happiness
  23. 23. Cloud  fotos
  24. 24. Cloud • “We  want  to  start  using  Cloud  services”
  25. 25. Challenges • Security  of  the  data • Security  of  the  servers • Who  is  responsible  for  the  servers • Where  is  the  data  located • Encryption  at  rest • Disks  reutilization
  26. 26. Security  Approach • New  Security  policy  for  Cloud  services • Security  Onboarding  for  teams • Inventory  of  cloud  services
  27. 27. DEVOPS
  28. 28. Why  Devops? • Continuous  software  delivery   • Faster  delivery  of  features • Faster  resolution  of  problems • Less  complex  problems  to  fix More  Deploys  Means  Faster  Time  to  Market  and  Continual  Improvement
  29. 29. Challenges • Rapid  releases  cycles  (every  day,  multiple  times  a  day) • Autonomous  teams   • Teams  are  doing  development  and  operations  now • Infrastructure  also  changes  fast
  30. 30. Development  cycles Waterfall Agile Devops
  31. 31. Surviving  Devops • Providing  security  training  to  teams • Provide  security  policies,  guidelines • Security  and  abuse  stories,  driven  by  business • Situational  awareness:   • What  do  we  have? • Changes,  alerts. • Attack  surface,  priorities
  32. 32. Surviving  Devops • Automation: • Integrate  testing  into  continuous  integration  and  release  process  (Chef  &   Puppet) • Integrate  and  extend  production  configuration  monitoring • Develop  your  own  security  testing  tools,  more  focused  and  adapted  to  your   particular  needs
  33. 33. Surviving  Devops Situational  awareness  &  Automation  example: -­‐Source  code  Product  attack  surface  analyzer,  alerts,  prioritization  of   efforts.   -­‐Internet  footprint,  scanning  and  inventory.  Updated  every  hour.
  34. 34. Surviving  Devops • Integrate  InfoSec  and  IR  into  the  Ops/Devs escalation  process • Harden  the  production  environment • Provide  guidelines/baselines   on  what  is  a  hardened  environment • Automate  hardening  (Chef/Puppet) • Tolerate  failure  in  production  environments  (Chaos  Monkey)
  35. 35. Surviving  Devops • Metrics:   • Identify  if  teams  are  repeating  certain  type  of  vulnerabilities,   train  them  to   prevent  repeating  again.   • Prioritize  training • Modify  policies  and  baselines • Tune  tools • Interact  more  closely  with  teams,  attend  to  standups • Be  more  flexible  and  adapt  to  team  processes   • mesh  with  the  unique  development  cultures  of  individual  teams
  36. 36. The  Future? Rugged  software “Rugged”  describes  software  development  organizations  which  have  a   culture  of  rapidly  evolving  their  ability  to  create  available,  survivable,   defensible,  secure,  and  resilient  software Rugged  is  NOT  a  technology,  process  model,  SDLC,  or  organizational   structure.  It’s  not  even  a  noun.
  37. 37. Rugged  software Rugged  describes  staying  ahead  of  the  threat  over  time “We  are  convinced  that  negative  and  reactive  approaches  to   application  security  cannot  scale  and  are  doomed  to  fail.  These   approaches  primarily  rely  on  finding  vulnerabilities  and  fixing  them.”
  38. 38. Rugged  Manifesto I  am  rugged  and,  more  importantly,  my  code  is  rugged. I  recognize  that  software  has  become  a  foundation  of  our  modern  world. I  recognize  the  awesome  responsibility   that  comes  with  this  foundational  role. I  recognize  that  my  code  will  be  used  in  ways  I  cannot  anticipate,  in  ways  it  was  not  designed,   and  for  longer  than  it  was  ever  intended. I  recognize  that  my  code  will  be  attacked  by  talented  and  persistent  adversaries  who  threaten   our  physical,  economic  and  national  security. I  recognize  these  things  – and  I  choose  to  be  rugged. I  am  rugged  because  I  refuse  to  be  a  source  of  vulnerability  or  weakness. I  am  rugged  because  I  assure  my  code  will  support  its  mission. I  am  rugged  because  my  code  can  face  these  challenges   and  persist  in  spite  of  them. I  am  rugged,  not  because  it  is  easy,  but  because  it  is  necessary  and  I  am  up  for  the  challenge.
  39. 39. Conclusion • Development  methodologies  and  processes  changed  considerably   over  time • More  things  happening  in  shorter  period  of  time • Security  tools  and  techniques  needs  to  adapt  to  this  situation • Automation  is  key  in  Devops environment • Security  professionals  need  to  be  flexible  and  engage  more  than  ever   with  development  teams
  40. 40. ?
  41. 41. Thank  you cmartorella@edge-­‐
  42. 42. Resources • Microsoft  SDL  -­‐ • Rugged  Software  -­‐ •­‐2/the-­‐cultural-­‐challenges-­‐of-­‐ application-­‐security/ •­‐unexpected-­‐benefits-­‐of-­‐devops/ •­‐of-­‐devops