Threat Mitigation

Once we identified potential threats, our next step is to create a mitigation plan. The plan will be contextual, since every threat is different. We can identify however a few big categories for threat mitigation actions:

• Infrastructure: switch to encrypted communication protocols, use authentication mechanisms between machines, strengthen the configuration etc.
• Architecture: modify the data stores and corresponding modules to have the lowest levels of access
• Code: improve the code practices and guidelines to include automated tests for specific security threats, avoid injection vulnerabilities etc.
• Tools: use static code analysis, property based testing, test data generators etc.

More sophisticated measures can be deployed depending on your needs. A relatively new approach is to deploy probes in your infrastructure, like for example monitored file systems that look as if they contain valuable data for a potential attacker but that trigger alarms at the moment of access.

Architectural Mitigation

A good analysis to make is to split your data into different parts, depending on the level of privacy. For example:

• public data – data that is available elsewhere, and that is therefore not valuable to a potential attacker
• licensed data – data that you paid for, but that anyone else can pay for, and therefore if stolen it could be an issue for your provider but not necessarily for you
• private data – data sets containing private information such as email addresses, names, postal addresses, phone numbers etc. This type of data is protected by various privacy laws including GDPR and CCPA
• sensible data – data sets with a higher level of legal protection, such as health information, legal information, or child data
• commercial secrets

These different types of data can be stored in physically separate databases, with different needs for encryption, access rights, access monitoring, integrity checks etc. For example, any change in health data can be monitored, linked to a specific identity, digitally signed and encrypted, while public data can be stored unencrypted.

This way of thinking leads of course to separating modules in your architecture based on a threat criteria, in addition to the other criteria you might have such as performance, scalability, and reliability.

In addition to separating these data sets, the policies for backup and restore are equally important. Your backups need to be at least as protected as the database.