Possible MMMs for the OWASP Top 10

Defining principles for a Mitigation Maturity Model (MMM) is all well and good, but without a more concrete way to approach creating your own MMM, principles can be easily lost or misunderstood.  On the flip-side everyone's environment and business is different and there are no hard and fast rules which apply to everyone.

But in the spirit of having a go at the ridiculous in an attempt to achieve the impossible, I thought I would share some more concrete examples of what a MMM could look like.

In tried and true form, I will use the OWASP Top 10 (commandments) as the source of vulnerabilities to address.  I have to say though that the only way some businesses could treat these vulns with more reverence would be if they were actually written on stone tablets.  They are of course:
        A1: Injection       
        A2: Cross-Site Scripting
        A3: Broken Authentication and Session Management
        A4: Insecure Direct Object References
        A5: Cross-Site Request Forgery
        A6: Security Misconfiguration
        A7: Insecure Cryptographic Storage
        A8: Failure to Restrict URL Access
        A9: Insufficient Transport Layer Protection
        A10: Unvalidated Redirects and Forwards

Let's organise these into some categories that will complement the mitigation strategies we apply to each.

RequestProcessingResponseConfiguration
A1: Injection (Code)A1: Injection (SQL)



A2: Cross-Site Scripting
A3: Broken Authentication and Session Management


A4: Insecure Direct Object References (Files)A4: Insecure Direct Object References (Other)

A5: Cross-Site Request Forgery





A6: Security Misconfiguration



A7: Insecure Cryptographic Storage

A8: Failure to Restrict URL Access

A9: Insufficient Transport Layer Protection


A10: Unvalidated Redirects and Forwards




The Request

Arguably all the request vulnerabilities can be mitigated by Input Validation (if we include authentication and CSRF) and so they share a common mitigation strategy.

A1: Injection (Code)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References (Files)
A5: Cross-Site Request Forgery
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards

An advanced MMM would involve crafting a request framework that is secure by default and secure by design.  Every request would declaratively state (in a way that could be audited by a tool) what the business context of the request is and list all the request parameters and their validation criteria.  Examples of business context of the request could be; "Public", "Write User Data", "Read Sensitive Data" etc.  When a request comes in, the framework would match it to a declared request, apply the appropriate checks for the business context (mitigating A3, A5 & A9) e.g.
  • Public - No authentication check, no CSRF check, no transport check
  • Write User Data - Authentication check, CSRF check, transport check
  • Read Sensitive Data - Authentication check, no CSRF check, transport check
The default business context would enforce the majority of the security checks.  The framework would always check the request parameters for code injection attacks and validate them against their declared validation criteria (mitigating A1, A4 & A10).

Such a request framework could co-exist with legacy requests as the framework could forward the request to the legacy request processing functionality for any incoming requests it had no knowledge of.  The long-term plan would be to migrate the legacy requests to the new framework as business considerations allow.

An intermediate MMM would make use an API to provide security functionality.  There would be an API call to check for authentication, for CSRF and for the correct transport layer protections.  It would however, be up to the developer and code reviewers to enforce the use of the API.  Similarly another API could be used for input validation to protect against code injection, direct object references and unvalidated redirects and forwards.  It would become part of the coding standards to use these APIs religiously in all new code and all code reviews would ensure the API was being used.  The long term plan would be to migrate all existing code to use these APIs.

The actual API that is used may have been developed in house, although more likely a industry standard API would be used, perhaps as an add-on to the application framework already being used.  Additionally, if testing was well developed internally then some security testing may also occur.

A basic MMM does not have a centralised approach.  It would enforce authentication at obvious entry points to the application, but may miss direct requests for resources.  There is likely no CSRF protection and it would take a proof-of-concept attack to convince management to protect against this vulnerability.  Transport layer protection would be implemented as a catch-all solution, but be the first thing to go whenever performance concerns were identified.  All input validation would be left up to the developer, but with them so busy focusing on functionality the validation would be loose and untested.

A1: Injection (SQLi)

Is covered in my blog post SQL Injection MMM.

The Processing

A4: Insecure Direct Object References (Other)
A8: Failure to Restrict URL Access

Both these vulnerabilities are authorisation issues, and so largely share the common mitigation of implmenting authorisation.

An advanced MMM would implement an authorisation (authZ) framework that every request had to pass through.  Such an authZ framework would be secure by default which would mean that any request that had been explicitly allowed, would be denied.  The framework would be centrally decided and all authZ criteria stored centrally stored, however enforcement would occur at the points where functionality is invoked.  A4 is mitigated as the authZ criteria would state that only users who own the requested object may access them.  A8 is mitigated as every URL is a functionality endpoint and any request to an endpoint must be explicitly authorised by the authZ framework.

Implementing such an authZ framework is a considerable amount of work (if no appropriate existing solution can be found), but that is not even the difficult part of such an authZ framework.  Creating the framework and ensuring technical correctness is an engineering challenge, but ensuring that those who manage the authZ criteria on a day to day basis are able to do so without suffering an excessive burden that ultimately causes them to grant more access than is required, that is a problem best solved by interface designers (regular and easy auditing, reporting and testing notwithstanding).  My suggestion for this would be to create a mapping between the UI exposing the functionality and the functional endpoints that implement the functionality.  Access control settings should then be place as close to the corresponding UI as possible.

An intermediate MMM would have the endpoint functionality verifying, via an API, whether or not a user has some permission.  The permission value would be hard-coded into the endpoint functionality.  The API would be a shared library that could be reused across multiple applications.  If single permissions can be maintained per-endpoint then this is manageable solution, however it is common for permissions to rapidly increase due to the desire for fine-grained access control.  When multiple permissions are required per-endpoint then the difficulty of managing access control increases significantly.  Permissions should be assigned to Roles, which also group together users.  Requests for objects will require linking to the object owner to protect against A4; the burden is on the developer to remember this.  Testing for A4 vulnerabilities will be required (in addition to normal testing).

A basic MMM places the burden on the developer to remember to check the user's Role and check they own the object they are trying to access.  It's likely that access control will be implemented client-side by only exposing certain UI elements, but not corresponding server-side check occurs.

The Response

A2: Cross-Site Scripting (XSS)

Is covered in my blog post XSS (Part 3) - XSS defences grow up.

The Configuration

A6: Security Misconfiguration

An advanced MMM would include an easy to use tool that simplified and automated deployment configuration options.  The tool would consist of different pre-configured options that would be associated with different policies e.g. internal or external facing.  Full manual configuration would still be possible.  Documentation would cover all configuration and hardening options and provide straight-forward guidelines.  3rd party components would be regularly monitored for security vulnerabilities and new versions tested when available and quickly integrated according to a well established procedure.  There would be automated checking of post installation configuration and hardening options.

An intermediate MMM would provide; manual configuration (copy & paste), documentation on hardening, ad-hoc mitigation of vulnerabilities in 3rd party components and basic testing for misconfiguration.

A basic MMM would be a reactionary state where the minimum set of known configuration vulnerabilities would be dealt with and changes only made when issues were discovered (usually by a customer).  There would be little to no documentation on security.  3rd party component vulnerabilities would only be addressed in line with application updates and only if they didn't break the application.

A7: Insecure Cryptographic Storage

An advanced MMM hides all cryptography from the developer.  Securing information for storage is done through an API that requires no security knowledge, developers only see functional security API e.g. SecureForStorage etc.  The API is built on an encryption library and designed with crypto-agility so that algorithms can be updated.
  
An intermediate MMM has developers using a central crypto-library, likely an open source one, and they decide what configurations to use and where to store the key.   The library may default to secure options but developers can specify all parameters.  Use of the crypto-library is heavily reviewed and guidelines are produced for correct usage is typical scenarios.  Code review is used to spot deviations from the guidelines.

A basic MMM would involve developers creating their own obfuscation algorithm, or using a standard algorithm but with hard coded key.   With little cryptographic knowledge the developers are likely using the any standard algorithm in an insecure way i.e. trying to use encryption to get integrity (encryption is typically seen to solve all security problems).  There will be a senior technical person responsible for security in the company who everyone thinks has sufficient knowledge, but he doesn't really and no one knows this because in the land of the blind the one eyed man is king.

No comments:

Post a Comment