Until recently – and, arguably, with ample justification – computer and network security has been the exclusive bailiwick of security experts. However, ever-busy legislators and lawyers can never leave well enough alone.1 As a result, security in many areas of the economy is now mandated by regulations and contracts.

I want to explore this phenomenon in a series of successive blogs. The first will look at the background of security and, in particular, what security actually means. Subsequent blogs will take a peek at what the law (surprisingly) mandates for technology security.

Among the prevailing concepts in security are two important and complementary ideas: Security by Design and Security by Default.

Security by Design

"Secure-by-Design" means that technology products are built from the ground up to protect against malicious cyberactors successfully gaining access to devices, data and interconnected infrastructure.

Secure-by-Design requires developers to take "ownership" of security outcomes. This implies that developers must:

  • Perform risk assessments from the outset of each development project and include protections in base designs to protect against evolving cyberthreats.
  • Systematically design defence in multiple layers using a "tailored threat model" during development: in effect to anticipate and identify threats and vulnerabilities from the earliest stage of development.
  • Invest significant resources at each layer of technology product design and development, and avoid "bolting on" security later.

Companies that develop technology on a Secure-by-Design basis must have strong leadership by top business executives from the very beginning of development and throughout the development process. This will ensure that security is a business priority, not just a technical feature.

The Secure-by-Design approach to development will require the use of programming languages that eliminate widespread vulnerabilities, such as Python, JavaScript, Java, C/C++, Ruby, Perl, SQL and some others. It also requires limitations on access to computer memory.

The Secure-by-Design approach prioritizes features, mechanisms and implementation of tools that protect customers and systems rather than cool product features that enlarge the potential attack surface for bad actors.

It has been argued that Security by Design will save money for developers in the long run because of a reduced need for issuance of security patches and a reduction in the number of potential lawsuits.

Security by Default

"Secure-by-Default" is related to Secure-by-Design. It essentially means that technology products are made resilient against prevalent/usual exploitation techniques, out-of-the-box. In other words, even if you are unskilled in security, you can still have a tech product that is resistant to attack by bad actors from the moment you fire it up. Secure-by-Default products protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them.

A good example of Secure-by-Default in the day-to-day world is the security afforded to passengers in an aircraft. The loading area, the passenger processing process, the loading process, the staff and the aircraft itself are secure from the get-go. Passengers only have to limit what they carry with them to be safe.

Characteristics of products that are Secure-by-Default include (among many others) the following:

  • There is a baseline secure configuration.
  • The customer should not have to navigate complicated security configuration requirements.
  • There are no default passwords.
  • Multi-Factor Authentication (MFA) is built in.
  • Often there is modern single sign-on, like SAML or OpenID Connect.
  • Secure logging is part of the functionality.
  • Authorized profile roles and use cases are built in.
  • Security is prioritized over the convenience of backwards compatibility.

What Is the Result?

The great benefits of these twin ideas of Security by Design and Security by Default are:

  • That customers do not have to shoulder burden of security alone: the developers have their backs;
  • that the development of technologies is characterized by sensible transparency and accountability (for example, through the publication of vulnerability advisories and Common Vulnerability and Exposure (CVE) records); and
  • development organizations are built around clear security goals with the support and leadership of both senior executives and security-savvy development personnel.

It has not escaped the attention of governments that insecure technology cuts productivity, exposes a nation's technology and data to theft by bad actors, poses national security risks, and costs tax dollars.

In my next blog post, I will talk about the role of various governments – often working in collaboration – and some proposed and actual legislation that mandates security in technology products. Stay tuned!

Footnote

1. This is arguably a good thing. The last thing polite society needs is roving gangs of unemployed legislators and lawyers, running amok and willy-nilly promulgating legislative fiats and regulations, applying for injunctions and frightening impressionable children and the elderly.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.