MVC RASP

[Moved to: &2183 (closed)]

Problem to solve

Adversaries will attempt to probe applications and send them all sorts of malicious traffic, whether it is cross-site scripting, SQL injection, or others. Applications will generally have security controls in place to monitor traffic and drop obviously bad traffic. However, existing security controls can lack the application-specific context to be able to identify some of the more advanced or nuanced attacks.

Intended users

Further details

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.

RASP should be viewed as an "agent" or a security control that lives inside the logic of the application itself, rather than in-front or behind the app.

RASP systems generally work by running in a "learning" mode for a period of time, where they learn what is normal behavior for an application. Once they have built a profile of what normal behavior looks like, they are switched into "active" mode, where they will then compare real traffic to what they saw in learning mode. Then, any suspicious activity can be responded to in a number of ways. Responses can include, logging the event, blocking the request, or even response that leverage application context, such as forwarding users to step-up authentication or disabling a user's account.

Use case to target initially

Ruby applications that access a SQL database, hosted on a GitLab-managed Kubernetes cluster.

    • Confirm this is the initial use case we want to target.

Proposal

Introduce a minimal RASP which is able to identify applications calls to the Object Relational Mapping (ORM) layer that are potentially malicious. Provide this for a specific use case and validate it against at least one specific form of attack.

  1. Users should not be required to make changes to the code in their app.
    • It is reasonable to ask them to add a package to their Gemfile/requirements.txt/etc file
      • One RASP vendor uses bundle exec <rasp agent> init
  2. The RASP should only log suspicious events but not block anything.
  3. Provide users a way to view the results of the RASP.
    • This can be very basic

(ideation)

  • Target for protection:
    • ORMs
      • Introduce a custom version of OSS ORM with additional security in it
      • Provide a custom Gem/Pypi/etc package to be used
      • GreenSQL/HexaTier
      • Could we use DAST and review apps to configure "learning" mode and then deploy to production environments in "active" mode?
    • Web servers
      • Inspect packets after SSL termination (seems like WAF though?)
    • App Routers
      • Inspect packets before passing to app logic

Permissions and Security

GitLab Ultimate is required to use RASP packages.

Documentation

Testing

What does success look like, and how can we measure that?

  1. Number of users who have enabled the RASP controls within 90 days of release. Target => 100.
  • This will help us to gauge initial adoption.

What is the type of buyer?

Links / references

Technical discovery

/label feature

Edited by Philippe Lafoucrière