Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

C days2015

626 Aufrufe

Veröffentlicht am

Security for Startups

Veröffentlicht in: Internet
  • Als Erste(r) kommentieren

C days2015

  1. 1. Este documento é propriedade intelectual da PT e fica proibida a sua utilização ou propagação sem expressa autorização escrita Building a Secure Startup Nuno Loureiro SAPO Security Team 07.10.2015 C-Days 2015 nuno@co.sapo.pt
  2. 2. 2 Who am I? Timeline •Dez 2009: Got a dual Masters degree: MSIT-IS from CMU and MSI from FCUL • Jan 2010-now(): Founded and lead SAPO’s Security Team •2012-now(): Head of Security and Fraud at PT Pay (Meo Wallet) •1997-2002: System and Network administrator, Programmer, a little of Security, Student, Entrepreneur … •2002-2008: Web Programmer at SAPO,Technical Lead of SAPO’s Email Platform
  3. 3. 3 Summary • Security  Awareness   • Steps  to  improve  Security  within  your  organization   • Security  Culture   • Risk  Analysis   • Secure  Infrastructure   • Application  Security  
  4. 4. 4 Context Let’s  imagine  John  co-­‐founded  a  small  Startup.     Between  founders  and  employees  there’re  10  people.   They’re  focused  on  a  single  product: A  collaborative  and  integrated  project  management  platform Their  Business  Model  is  SaaS. They’re  on  a  tight  budget.
  5. 5. 5 Invest in Security? We’re  too  small  to  be  an  attractive  target…   Why  should  I  care?   Should  I  invest  in  Security  from  the  beginning?  
  6. 6. 6 Invest in Security? The  problem  is…  
  7. 7. 7 Invest in Security?
  8. 8. 8 Invest in Security?
  9. 9. 9 Invest in Security?
  10. 10. 10 Invest in Security?
  11. 11. 11 Invest in Security?
  12. 12. 12 Invest in Security?
  13. 13. 13 Invest in Security? IPO? Fraud Suicides Divorces
  14. 14. 14 Invest in Security? You  can  argue  about  the  probability  of  a  successful     attack  but  the  impact  of  just  one  attack  can  put  you   out  of  business… Conclusion
  15. 15. 15 Invest in Security? Are  you  willing  to  take  that  risk?
  16. 16. 16 Steps to improve Security Tips  to  embrace  Security  in  your  startup
  17. 17. 17 Steps to improve Security
  18. 18. 18 Security  should  be  part  of  your  culture • Starts  at  the  C-­‐level   • 2nd-­‐factor  for  VPN,  email  (from  new  devices)  and  critical  operations/ accounts Steps to improve Security
  19. 19. 19 Security  should  be  part  of  your  culture • Setup  VPN  (e.g.  OpenVPN)  for  remote  accessing  your  infrastructure   • Adopt  “corporate  network  =  home  network”  model,  no  privileged  access   from  corporate  network  to  your  infrastructure Steps to improve Security
  20. 20. 20 Security  should  be  part  of  your  culture • Use  Full  Disk  Encryption  on  your  laptops   • Use  password  managers Steps to improve Security FileVault
  21. 21. 21 Security  should  be  part  of  your  culture • Give  periodic  security-­‐awareness  sessions  (phishing,  do’s  and  don’ts,  …)   • Invest  on  E-­‐mail  security  (to  prevent  malware,  phishing,  etc)   • Don’t  forget  Periodic  updates,  AV,  Firewall,  Screensaver  with  password   • Use  strong  cryptography  on  your  wifi,  VPN,  HTTPS  sites   Steps to improve Security
  22. 22. 22 Access your risk Risk  Analysis • There  are  many  frameworks  to  perform  Risk  Management:   • ISO27005     • OCTAVE     • NIST  SP  800-­‐37   • There  are  many  frameworks  to  perform  Threat  Modeling:   • Stride   • Dread • For  the  purpose  of  this  talk  we’ll  do  a  very  basic  approach
  23. 23. 23 Risk  Analysis • What  are  your  main  assets?   • Customer’s  data:  code,  project  ideas,  status  of  development,  business  plan,   employee’s  information,  confidential  information     • Business  Information:  Sales,  business  plan,  list  of  customers,  etc   • Availability  of  the  service   • What  are  the  main  threats  you  want  to  prevent?   • (account,  customer,  business)  Data  breach:  could  lead  to  bankruptcy   • DDoS  attacks:  Availability  is  core  to  our  business;  customer  churn   • What  vehicles  (vulnerabilities)  could  be  used  to  turn  threats  into  successful  attacks?   • Vulnerabilities  in  the  Web  Application   • Vulnerabilities  in  the  systems   • Public  IP  addresses   • Employee  PC   • Employee   • Email   • Physical  access  to  systems   •  (…) Access your risk
  24. 24. 24 Secure your Infrastructure Infrastructure  Security Vs On-­‐Premises In  the  Cloud
  25. 25. 25 Infrastructure  Security:  On-­‐Premises  or  In  the  cloud • Setup  different  subnets  for  each  one  of  the  layers  of  your  infrastructure  (at  least  one  for   Web  frontend  servers  and  one  for  backend  servers)   • Control  all  traffic  between  the  subnets  with  firewall  ACLs  (also  inbound/outbound)   • If  there’s  traffic  that’s  not  allowed  between  a  frontend  and  a  backend  server  then  have   your  Intrusion  Detection  System  raise  an  alarm   • Use  GRSecurity  if  you  run  Linux,  use  EMET  if  you  run  Windows   • Update  all  your  systems  periodically   • Install  a  Host  Intrusion  Detection  (HIDS),  e.g.  OSSEC Secure your Infrastructure
  26. 26. 26 Infrastructure  Security:  On-­‐Premises  or  In  the  cloud • If  you  decide  to  go  to  the  cloud:   • Be  careful  with  the  account  with  admin  privileges,  choose  a  strong  and  unique   password  plus  2-­‐FA  or  if  possible  require  VPN  to  access  the  management  console.   • Choose  one  of  the  top  cloud  providers,  where  security  has  been  scrutinized     • Cloud  providers  offer  some  sort  of  network  DDoS  protection   • Can  offer  email  protection  (malware,  spam,  phishing)  too     • You  can  have  a  mixed  solution  (cloud  and  on-­‐premises)   • Weigh  the  Pros  and  Cons  of  each Secure your Infrastructure
  27. 27. 2 Build Secure Software Adopt  SSDLC My  advice  from  almost  6  years  of  experience  in  this  area:   • If  you  have  a  security  team,  they  should  be  close  to  developers.  When  developers   go  to  the  security  team  ask  for  advice  on  a  regular  basis  you  know  you  got  it  right.   • Training  developers  on  Secure  Programming  really  works   • Introducing  security  early  in  the  project  saves  everyone  time  at  the  end   • Do  Pentesting  before  going  live  and  periodically  (at  least  1x  year)  
  28. 28. 28 Build Secure Software Take  into  consideration  OWASP  TOP10
  29. 29. 29 Build Secure Software
  30. 30. 30 Build Secure Software • A  significant  part  of  Data  Leaks  today  are  due  to  SQLi  vulnerabilities   • If  you  use  Prepared  Statements  when  writing  your  SQL  queries,  say   bye-­‐bye  to  SQLi   • Encrypt  your  sensitive  data  before  storing  it  in  the  database  (do  not   store  the  encryption  key  there!)   • There’s  no  excuse  these  days  for  introducing  new  SQLi  vulnerabilities   in  code
  31. 31. 31 Build Secure Software
  32. 32. 32 Build Secure Software Some  advice: • Use  HTTPS   • Hash  the  password  before  storage  (hint:  HMAC)   • If  authentication  fails  don’t  say  that  it’s  the  username  that  does  not   exist  or  that  it’s  the  password  that  is  wrong,  give  a  generic  message   instead   • Re-­‐authentication  should  be  required  before  any  application-­‐ specific  sensitive  operations  are  permitted,  such  as  for  changing  the   password Authentication  et  al.
  33. 33. 33 Build Secure Software Some  advice: • Do  you  allow  “a  single  account  tested  against  all  possible  passwords”?  (vertical   bruteforcing)   • What  about  “all  accounts  tested  with  the  same  password  e.g.  123456”?   (horizontal  bruteforcing)   • Use  an  outbound  channel  for  account  recovery  and  apply  the  same  security   controls  as  for  authentication  (like  when  storing  the  recovery  token,  throttling,   re-­‐authentication  for  changing  the  recovery  elements,  etc)   • Avoid  using  security  questions  for  account  recovery   Authentication  et  al.
  34. 34. 34 Build Secure Software Always  check  if  the  user  is  authorized  to  access  the  required  object!
  35. 35. 35
  36. 36. Este documento é propriedade intelectual da PT e fica proibida a sua utilização ou propagação sem expressa autorização escrita. SAPO Security Team The  END Nuno  Loureiro nuno@co.sapo.pt

×