Secure design principles

Segmenting assets on a network provides the following benefits:

• It helps to contain the compromise to the segment that has been breached
• It enables you to better protect the assets that are most sensitive or valuable
• It supports the ability to limit or examine communication flows between segments. This means monitoring rules can be created which are able to assert with high confidence that a breach or misconfiguration has occurred

Decisions on how to segment a network will typically consider the protections different assets require, their need for interaction with other assets, and the extent to which their integrity is trusted.

If functionality exists for authorised users then it can be abused by unauthorised users in event of a compromise.

Reduce the presence of unnecessary functionality and you reduce this risk. In doing so you'll also cut the operational overhead of maintaining software or functionality you don't need, simplifying your system and making monitoring easier.

Removing unnecessary functionality can take several forms, such as tuning the default configurations of the software you use, or removing debug or test functionality from production systems.

A common design flaw is to have weaker security controls and security architecture in management communications, than in the systems being managed. In such scenarios, compromising a single external-facing component can result in privileged access to systems or data via channels which were only intended for administrative use.

Design your system architecture so that, if you detect a compromise, you can quickly rebuild to a known clean state - once you've addressed the flaw which led to compromise.

Create a design that will enable you to both recover andmaintain the records and data you might need to support an investigation. If you wait until post-compromise, you might find that you have to choose between recovering the system quickly or keeping the data you need for an investigation.

Where the impact of attack, misuse or compromise would be significant, consider requiring the most privileged or potentially dangerous functions in the system to demand two or more individuals working together to perform them.

Performance or reporting tools should be supplied with de-sensitised data.

Suppose you have an operations team that wants to create and display a performance dashboard for a financial payment system. To function properly, their dashboard does not need to work on raw transaction data, which may well be sensitive. Any personally identifying information can be stripped from the data before the analytic system processes it. This will reduce the number of places that a high impact breach could occur.

We recommend implementing controls to anonymise data as close to the source as possible. Rather than relying on reporting tools to anonymise data, you should maintain control of the process yourself.

Don't design functionality or deploy applications which enable arbitrary queries against your data. These applications undermine segmented system designs by providing an easier path to compromise data.

These data stores are likely to be less well protected than the primary data store, but can potentially yield high-value information to an attacker.

If a cache or temporary data store is required, then it should operate a data-fading policy that purges records as soon as possible after access has finished, ensuring that minimal data is stored in the cache and what is stored is protected appropriately.