Principles of a MMM

I think the best way to convey an idea is to break it down into it's simplest yet most descriptive ideas.  That is what I am trying to do here, present simple ideas behind the Mitigation Maturity Model (MMM).  If you can appreciate and apply these principles then you will get the most out of your mitigations.

Mitigating vulnerabilities is a process.

It is very rare that you get the opportunity to design into a system a mitigation for a class of vulnerability.  Most of the time the best you can hope for is to evolve part (usually not all) of a system to mitigate a vulnerability by design.  This means whatever mitigation you use has to be able to co-exist with the parts of the system it does not protect.  Achieving a partial mitigation by design with a goal of moving all parts of a system to mitigation by design is an advanced level of mitigation maturity.

Often it will not be possible to mitigate by design, in these cases parts of the system need a mitigation plan applied to them and then any deviations from that plan need to be audited.  This might be for example removing the use an insecure API and replacing it with a secure one, where uses of the old insecure one can be detected automatically.  Implementing a mitigation plan on part of a system with a goal of applying the plan to all parts of a system is an intermediate level of mitigation maturity.

When it is not possible to initiate a comprehensive mitigation plan then a mitigation approach can be applied on a case-by-case basis.  If a vulnerability is known to exist in a particular part of a system then if it can be isolated the mitigation can be applied directly to that instance.  Obviously finding the instance of the vulnerability in the first case is problematic and may be reactionary to an identified exploit of that vulnerability.  Developers can also be instructed and trained to apply the mitigation to the system where appropriate, however the effectiveness of this approach is usually limited by business functionality taking priority.  Applying mitigations on a case-by-case basis is a basic level of mitigation maturity.

Let developers focus on functionality, not security.

A mitigation that is implemented by design is virtually by definition also secure by default.  The natural state of all parts of the system should be secure and require a conscious decision to change that level of security.  Any change of part of the system to be less secure should be able to be detected through auditing.  Changing from the default level of security implies identifying other states of security that are available for use (which may just be security is either on or off).  Other states of security made available must be linked to the business scenario justifying that level of security. In this way the developer is not making a security decision, but a business one when they use a lower state of security.

An advanced level of mitigation maturity is when the mitigation is adjustable based on business context.  For instance, communications can be in the clear, encrypted, signed, or encrypted and signed, a developer should be able to get the appropriate security by tagging the business context of the data rather than understanding the appropriateness of the mitigations available.  But the default should be encrypted and signed.

Where a mitigation is unable to be implemented by design, a mitigation plan can be created to be able to audit the different levels of mitigation implemented in different parts of the system.  The security team in consultation with the business unit can then determine if each part of the system is applying the appropriate level of mitigation.  Where you make discoverable your level of mitigations to certain vulnerabilities you achieve an intermediate level of mitigation maturity.

Any mitigation that relies on developers to make security decisions or apply the mitigation consistently, does not scale, will not cover all functionality and will be unmaintainable.  If developers are only applying mitigations based on their knowledge and experience, even if their work is reviewed and tested, then the security of the system (as a whole) will only be as strong as; the least knowledgeable and least experienced developer, the reviewer with the least time, or the tester that implements the least vulnerability tests.  Such an approach only achieves a basic level of mitigation maturity.