Technical Discovery: RASP

Technical discovery to determine our technical direction to go in for RASP. This issue will precede the MVC for RASP

Gartner defines RASP as:

Runtime application self-protection (RASP) is a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.

Several problem spaces to explore about attacks:

  1. SQL injection
    • Be able to identify & detect when a SQL injection attack is being attempted or has happened
  2. Cross-site scripting (XSS)
    • Be able to identify & detect when an XSS attack is being attempted or has happened

Several problem spaces to explore about how to respond to attacks:

  1. Drop a request
    • How can we drop / remove a request to the app once an attack has been identified?
  2. "Sanitize" a request
    • Is it possible to "sanitize" a request, to make it safe to continue running, after being identified as a potential attack? Is that even worth doing? Sam: Initial impression says no, we shouldn't sanitize and should just drop
  3. User-specified callbacks
    • How can we allow users to specify app-specific logic to be called? A user may use this to block an account or force step-up authentication, for example.

Several solution ideas to explore:

  1. Filter between app router & business logic
    • Decision:
    • Intercept, process, and either pass/user callback/block the request/response pair
  2. Custom ORM library and throw exceptions
    • Decision:
    • Identify DB calls and pass/user callback/block anomalous behavior
    • Raise exceptions into app logic. Users could write code to handle if desired or use a pre-provided exception handler, which likely just blocks the traffic.
  3. Determine what language we want to support with RASP, based on current and predicted future customer need (since RASP is generally implemented on a per-language basis. Use TIOBE index to assist.
  4. Custom agent/instrumentation library without requiring source changes
  5. Integration with Jaeger and building off of the Tracing vision
    • Decision:
    • We can assume in this case that users have already instrumented sensitive parts of their code for us to extend off of. Can we actively change/block bad requests we see from Jaeger?
    • @whaber : IMO, Jaeger may be a good fit to capture and trend web app/service requests; however, it does not cover looking for anomalous requests. This is something we would need to build on top of it.
  6. Integration with OpenRASP
    • Decision:
  7. Integration with OWASP App Sensor
    • Decision:
  8. Inserting hooks with Intel PIN or another dynamic binary instrumentation tool
    • Decision:
    • Choose a reference use case & provide an instrumented implementation of part of the libraries that would be used (e.g. use this pre-instrumented DB library)

Acceptance Criteria

  • Follow-on issue created for the implementation of MVC created
Edited by Wayne Haber