Secure by Design

Systems will be designed and maintained with the assumption that they will be attacked and possibly compromised by anybody.

Rationale

The cost of handling a security breach1 is significantly greater than the cost of hardening the system in the first place. If a breach does occur, we can minimise the scale and cost by detecting it as soon as possible, and having a well-planned response enables a fast time to close the breach and assess its impact.

By focussing on security from the beginning we mitigate not only the financial impact but also the reputational impact that would be incurred in the event of a breach.

Implications

  • Teams should be aware of data privacy implications including policy and legal compliance
  • Teams understand the security risks and model threat vectors.
  • Data will need to be appropriately classified and secured, both in transit and at rest.
  • People at all points of the engineering process need strong awareness of security techniques and principles, and should apply these throughout the lifecycle of the software
  • Teams apply the principle of least privilege.
  • We will use the OWASP guidelines for software development as a starting point to help people understand potential attack vectors and mitigation techniques.
  • Automated vulnerability analysis tools can help identify vulnerabilities but are not a replacement for a Secure by Design approach.
  • All network communication should be done over a secure transport layer.
  • The system should be able to detect and allow retrospective analysis of attacks through an appropriate audit trail.
  • Teams should have a clear strategy in place to respond to attacks and data breaches.

1. A 2015 survey found the average security breach costs a large organisation £1.46 – £3.14 million (source).

results matching ""

    No results matching ""