Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

DevSecCon London 2018: Whatever happened to attack aware applications?

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 38 Anzeige

DevSecCon London 2018: Whatever happened to attack aware applications?

Herunterladen, um offline zu lesen

MATTHEW PENDLEBURY
Today’s security detection and response capabilities are usually focused on endpoints and network devices. Applications are often considered a distant cousin, more of a potential liability whose logs should be ingested into remote monitoring solutions such as SIEMs. Projects such as OWASP AppSensor however have loads of promise, putting the application back at the heart of attack detection and response, plus offering a really exciting opportunity to development teams. But these ideas have been around for more than 10 years, and AppSensor itself is getting close to this age, yet they still aren’t commonplace, why might this be? An attack aware application is one that can detect and report suspected malicious events, evaluate a series of events and take action if it suspects that series of events, that when considered together are malicious in nature. Examples of events may be a high number of login attempts over a period, a forceful browsing attempt or an obvious XSS string. Many of these events are routinely intercepted today by inline security appliances such as a Web Application Firewall (WAF). However, suspicious events may also be a lot more contextual to the application such as a change to a parameter that should not be changed. This context may not be available to an external device such as a WAF but it is to the application and this leads to the ability to generate very high-fidelity security alerting and opens the possibility of the application itself making pragmatic defensive choices.

MATTHEW PENDLEBURY
Today’s security detection and response capabilities are usually focused on endpoints and network devices. Applications are often considered a distant cousin, more of a potential liability whose logs should be ingested into remote monitoring solutions such as SIEMs. Projects such as OWASP AppSensor however have loads of promise, putting the application back at the heart of attack detection and response, plus offering a really exciting opportunity to development teams. But these ideas have been around for more than 10 years, and AppSensor itself is getting close to this age, yet they still aren’t commonplace, why might this be? An attack aware application is one that can detect and report suspected malicious events, evaluate a series of events and take action if it suspects that series of events, that when considered together are malicious in nature. Examples of events may be a high number of login attempts over a period, a forceful browsing attempt or an obvious XSS string. Many of these events are routinely intercepted today by inline security appliances such as a Web Application Firewall (WAF). However, suspicious events may also be a lot more contextual to the application such as a change to a parameter that should not be changed. This context may not be available to an external device such as a WAF but it is to the application and this leads to the ability to generate very high-fidelity security alerting and opens the possibility of the application itself making pragmatic defensive choices.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie DevSecCon London 2018: Whatever happened to attack aware applications? (20)

Anzeige

Weitere von DevSecCon (20)

Aktuellste (20)

Anzeige

DevSecCon London 2018: Whatever happened to attack aware applications?

  1. 1. LONDON 18-19 OCT 2018 What happened to Attack Aware Applications? MATTHEW PENDLEBURY
  2. 2. LONDON 18-19 OCT 2018 Agenda • What do I mean “Attack Aware Applications?” • Where has the idea come from? • What is happening in this space? • What can you do with this? • Future thoughts
  3. 3. LONDON 18-19 OCT 2018 I am known by many names… …but you may call me • Applications Responding to Security Events • Reactive Applications • Attack Aware Applications • Real Time Event Detection and Response • Incident Detection and Automated Response • Self Defending Applications • OWASP AppSensor
  4. 4. LONDON 18-19 OCT 2018 An application that can detect malicious behaviour and respond to it
  5. 5. LONDON 18-19 OCT 2018 The Application – what could it possibly know?
  6. 6. LONDON 18-19 OCT 2018 Your application • Smart teams have designed it • It took a lot of hard work • It has a lot of thinking invested in it • It has the best CONTEXT
  7. 7. LONDON 18-19 OCT 2018 Credential Stuffing
  8. 8. LONDON 18-19 OCT 2018 Credential stuffing Image : https://www.troyhunt.com/the-111-million-pemiblanc-credential-stuffing-list/
  9. 9. LONDON 18-19 OCT 2018 Credential stuffing - What to do? • Log: <App> reports that it has been subject to credential stuffing from <IP address/Session>
  10. 10. LONDON 18-19 OCT 2018 Credential stuffing - What to do? • Log: <App> reports that it has been subject to credential stuffing from <IP address/Session>. It has responded by saying “unavailable”.
  11. 11. LONDON 18-19 OCT 2018 Credential stuffing - What to do? • Log: <App> reports that it has been subject to credential stuffing from <IP address>. It has responded by asked firewall to drop traffic from <IP Address> for 30 mins.
  12. 12. LONDON 18-19 OCT 2018 Credential stuffing - What to do? • Log: <App> reports that it is probably suffering a credential stuffing attack from <IP address> future successful attempts from this address will require additional 2FA challenge.
  13. 13. LONDON 18-19 OCT 2018 Credential stuffing - What to do? • Log: <App> reports that it is suffering a credential stuffing attack from <IP address> and that future successful attempts will give an “invalid credentials” response but will send the user to a password reset journey via the call centre.
  14. 14. LONDON 18-19 OCT 2018 Honey values
  15. 15. LONDON 18-19 OCT 2018 Honey values or Canary tokens/fields • Something that shouldn’t be modified/visited • userid=987654 • https://www.example.com/admin • Very high fidelity alert
  16. 16. LONDON 18-19 OCT 2018 What to do? • Tell your SOC • Drop traffic • Present a static site • Route to sandboxed copy of the site – no live data • Application specific response
  17. 17. LONDON 18-19 OCT 2018 The sum of small suspicions
  18. 18. LONDON 18-19 OCT 2018 The sum of small suspicions • Kali user agent • Spidering the site • Not following a recognized user journey
  19. 19. LONDON 18-19 OCT 2018 That’s not right!
  20. 20. LONDON 18-19 OCT 2018 That’s not right • Web banking application • User is authenticated as Alice • Transfer $$$ from Bob to Mallory
  21. 21. LONDON 18-19 OCT 2018 That’s not right • Implemented as a code check • Pseudo code: if (source_account.owner != current_user) { flag_alert(“Transfer attempted from wrong user…!”); } else { transfer_funds(source_account, destination_account, amount); }
  22. 22. LONDON 18-19 OCT 2018 Origins
  23. 23. LONDON 18-19 OCT 2018 Origins • 2010 ish • Michael Coates • Director of Security Assurance Mozilla • CISO Twitter • OWASP Board • AppSensor project
  24. 24. LONDON 18-19 OCT 2018 OWASP AppSensor • OWASP Project • Reference implementation • Estate of applications • Central analysis • https://www.owasp.org/index.php/OWASP_AppSensor_Project
  25. 25. LONDON 18-19 OCT 2018 AppSensor model App estate Analysis engine SOC Attacker Events Alerts Response
  26. 26. What’s happening with this idea • RASP and Next Gen WAF, behavioural analysis, ML…
  27. 27. LONDON 18-19 OCT 2018 So what happened? • Cannibalisation? • RASP & WAF • COTS • Can detect unusual behavioural patterns or traffic • Tuning with fast delivery & false positives
  28. 28. LONDON 18-19 OCT 2018 RASP & WAF - characteristics • Quicker to deploy • Known technology • Secure SDLC not needed • May be good enough?
  29. 29. LONDON 18-19 OCT 2018 Attack Aware Apps - characteristics • Deeper insight through context • Requires building in • Relatively unknown
  30. 30. LONDON 18-19 OCT 2018 But what can you do with it?
  31. 31. LONDON 18-19 OCT 2018 But what can you do with it? • Rallying cry for developers • Consolidates security thinking • Generate momentum
  32. 32. LONDON 18-19 OCT 2018 Think of the responses • Adversarial relationships with pen testers • Play with their minds • Applications that aren’t consistent
  33. 33. LONDON 18-19 OCT 2018 Advice • Standardise on/start with the AppSensor detection points • Thinking has already been done • In the future there may be more things in this space • https://www.owasp.org/index.php/AppSensor_DetectionPoints
  34. 34. LONDON 18-19 OCT 2018 Attack Aware Applications as part of a future Active Defence? • In military terms active defence means offensive measures to deny advantage or position to the enemy • In the cyber domain, it is taken to cover offensive actions within and beyond corporate network • UK National Security Strategy and US Active Defense Certainty Act indicate government policy and legal position is changing
  35. 35. LONDON 18-19 OCT 2018 Thank you

Hinweis der Redaktion

  • Been developer and run development for 17 years
    Security Consultant at MWR for the past 4 years

    VERSION 1 2018-10-16

  • I am known by many names… …but you may call me
  • Quote – Monty Python Holy Grail – “Tim”
    I thought I’d call it Applications Responding to Security Events but the acronym isn’t business approrpiate
  • Why the application? It’s the thing under attack, it has most context, why should it be passive?
    WAF and RASP
    Detect whilst attacker probing, react before exploit weakness
    Layered on top of a normal secure appl design
  • Context
    Normal looks like
    User journeys
  • Not trying to go super deep on technique more to illustrate the point
  • Breach happens – elsewhere
    Login page assailed by volume
    Single connection/session pushing attempts

  • Raise a log event. To the soc
    Not leaving it to the soc to figure it out, if they even get logs that fine grained.
  • Not necessarily the most appropriate action
  • Or rate limit.
    Naïve response
  • Probably
    The
  • Application is the only thing that can do this.
    You may already be doing this

    Reflection – could you do this by RASP, SOC or by WAF?
  • Something that should not be accessed or touched
  • admin=false
    Tripwire
    Browser should pass back fields
    Honey URLS /admin
    URL in comment
  • Raising the bar. The attacker will detect this.
  • Reputations – treat authenticated users slightly differently
    Persistence for reps – time based?


  • This time we are looking at internal sanity checks



  • Apparently banking applications are a bit more complicated than this

    This may occur if there is a logic flaw.
    Regardless in production it means something is going wrong
  • Back in 2010, Michael Coates was bitten by a radioactive spider

    Academic papers, there are significant contrinbutions to AppSensor
  • My first contact with this idea
    Detection points ~50
  • May also add firewalls or other devices.
    Detection points ~50
    Policy driven analysis rules
    High fidelity alerts
    Normal app logs as well
    Application has to respond to analysis engine – changes flow

  • Tumbleweeds
    AppSensor is a “reference implementation”
    ESAPI etc.

    Technology that needs to be built in.
    Some of this capability is taken by Application Layer firewalls WAFs
    RASP
    RASP and Next Gen WAF, behavioural analysis, ML…
  • RASP - Realtime Application Security Protection – Veracode, Prevoty, Signal Sciences etc.
    Instrument runtime – use behavioural ML learn what’s normal
    WAF Web Application Firewall – “next gen” - behavioural ML
    Both products – are still having to learn, despite marketing
    Moving at the speed of DevSecOps – many releases – TRAINING MODE adapting to constant code changes




  • Building it in would seem to require a level of maturity in a development team.
  • Spend time coaching and working with organisations improving secure development processes
    Use it as an aspirational state for development teams
  • Fight back against the evil pen testers
    Act of integrating detection points works like a fine grained threat model
  • Opportunity to talk to pen testers or security folk.
    Application context
    Hands on with security.
    Black box – increases the bar, takes time
  • Indications government position on active defence changing:
    2018 NSA and Cyber Command argued for greater freedom to attack than current rules of engagement. For example legal sign off.
    President Trump has sent a cyberwarfare policy to Congress outlining issues such as this including launching hacking operations. Not made public. <https://www.cyberscoop.com/donald-trump-white-house-cybersecurity-strategy/>
    Late 2017 USA Active Defence Certainty bill b4 congress exemptions from the computer fraud and abuse act.
    UK National Cyber Security Strategy 2016–2021, “government will draw on its capabilities and those of industry to develop and apply active cyber defence measures to significantly enhance the levels of cybersecurity across UK networks.” From <http://carnegieendowment.org/2017/06/14/private-sector-cyber-defence-can-active-measures-help-stabilize-cyberspace-pub-71236>
    Compare this with the aftermath of the sony attack, when the Obama administration clearly expected private organizations to defend themselves.
  • Happy to take questions. I can’t answer the one I asked which is where have all the attack aware applications gone, but I’d be interested if anyone knows the answer…

×