Secure by Design

Systems will be designed and maintained with the assumption that our software and the data they hold will be attacked and possibly compromised.

Rationale

The cost of handling a security breach is significantly greater than the cost of hardening the system in the first place. There is ever increasing evidence that our customers are growing more and more concerned about their data privacy. If a breach does occur, we can minimise the scale and cost by detecting and mitigating it as soon as possible, and being proactive in identifying risks and threats to our systems.

By considering security from the beginning we limit not only the financial impact but also the significant reputational impact that would be incurred in the event of a breach.

Implications

  • Teams must take responsibility for the security of their software throughout its lifecycle. This includes how they detect incidents, as well as how they respond to and resolve issues in the event of an attack or breach.
  • Teams must be aware of data privacy implications including policy and legal compliance.
  • Data needs to be appropriately classified and secured, both in transit and at rest.
  • Teams must understand security risks and model threats to their system.
  • The security of both the underlying platform used and the software being deployed to it, including any open source and 3rd party dependencies, must be considered. This applies on an ongoing basis, as threats evolve alongside the software, and needs continual review.
  • People at all points of the engineering process need strong awareness of current security techniques and principles, and how to apply these appropriately throughout the lifecycle of the software.
  • Teams are expected to make use of appropriate tools and techniques to identify vulnerabilities as early in the software development lifecycle as possible.

results matching ""

    No results matching ""