3.1 Research, implement and manage engineering processes using secure design principles

  • Threat modeling
  • Least privilege
  • Design in depth
  • Secure defaults
  • Fail securely
  • Separation of Duties (SoD)
  • Keep it simple
  • Zero Trust
  • Privacy by design
  • Trust but verify
  • Shared responsibility

In order to protect our system, we must first come up with a good design.  Some good design ideas we can use

We should first think about modeling the threats to our system.  The three most common threat models are STRIDE, DREAD, and PASTA.

The STRIDE model gives us a starting point for identifying threats.  It contains

  • Spoofing – gaining access to a resource through false credentials.  A hacker can fake his IP address, MAC address, username, password, e-mail address, hostname, SSID, etc..  The resource sees the spoofed credentials and assumes that the hacker is a legitimate user.

  • Tampering – making an unauthorized change to data.  The data might be in transit or at rest.  A hacker might tamper with data in order to obtain unauthorized access to a resource or to cause damage.

  • Repudiation – a hacker denies that they performed an action.  A hacker might structure his attack in such a way that it is impossible to prove that he was behind it.

  • Information Disclosure – leaking confidential information.  This may take place on purpose or by accident.

  • Denial of Service (DoS) – attacking a resource so that legitimate users are unable to access it.  A DoS attack might be permanent or temporary.

  • Elevation of Privilege – a user attempts to gain access to resources that he is not entitled to.  The user may be a legitimate user attempting to gain access to resources or a hacker who has obtained the user’s credentials.

The PASTA (Process for Attack Simulation and Threat Analysis) model allows us to define threats

  • Stage I: Definition of the Objectives for the Analysis of Risks

  • Stage II: Definition of the Technical Scope

  • Stage III: Application Decomposition and Analysis

  • Stage IV: Threat Analysis

  • Stage V: Weakness and Vulnerability Analysis

  • Stage VI: Attack Modeling & Simulation

  • Stage VII: Risk Analysis & Management

DREAD – Damage, Reproducibility, Exploitability, Affected Users, and Discoverability

  • Damage – how much damage will the threat cause?

  • Reproducibility – how difficult is it for a hacker to copy the exploit causing the threat?

  • Exploitability – how difficult is it for a hacker to implement the threat?

  • Affected Users – how many users will be affected by the attack?

  • Discoverability – how difficult is it for a hacker to discover that the system has a vulnerability that can be exploited?

We can look to ISO for some guidelines.  ISO 19249 provides design and architectural ideas for developing secure products.  The architectural principles include

  • Domain separation – we separate systems logically

    • A domain is a group of related components

    • We place components with similar security requirements in the domain and then we assign them the correct controls

    • Each domain communicates over a specific channel

    • We might use a VLAN if the domain is network-based

  • Layering – we layer our security so that if one level is violated, we are still protected by the other layers

    • Security must be made up of layers that are lower levels to higher levels

    • We can make each level simple enough so that we know how it operates and be able to verify it

  • Encapsulation – An object is accessed through a logically separate function that is separate from the object

  • Redundancy – we install multiple pathways so that the system remains operational in the event of the failure of a component

  • Virtualization – we virtualize our applications and systems so that they are separate from the underlying hardware

The design principles include

  • Least privilege – give each user only the access that they require to perform their duties

  • Attack surface minimization – reduce the exposure of the system so that there are less spots for it to be attacked

  • Centralized validation – validate credentials from a central location instead of from the local machine.  We do this because the local machine can be easily hacked.

  • Centralized security – monitor security from a central location

  • Error handling – ensure that errors are logged and also that errors do not display any sensitive information

Some other ideas

  • Secure Defaults or Secure-by-Default – the system should be secure by default.  We don’t want to give users the option to turn on security features later.

  • Fail Securely or Fail Safe or Fail Closed – when a system fails, it should fail securely, not fail open.  For example, if an electronic door lock fails, the door should stay locked, not unlocked.

  • Separation of Duties

  • Keep It Simple – the system should be simple to use and simple to understand.  When the system is complicated, it is more difficult to verify that it is working properly.

  • Trust, but Verify – we can trust legitimate users, but we should always verify that they are acting correctly

  • Zero Trust – Zero Trust is a new concept that tells the network not to trust anything regardless of whether it is inside the network or outside.  Any device connected to the network must prove that it is worthy of accessing a resource.  In a way, it is an idea of installing a firewall between the internal users and the network, not just between the internet and the network. 

    Zero Trust assumes that a breach has already taken place and is designed to mitigate the effect of such a breach.

  • Privacy by Design (PbD) – a framework for developing applications with user privacy in mind.  It has seven principles

    • Proactive not Reactive; Preventative not Remedial.  We develop systems that anticipate and protect against privacy breaches before they happen.  We want to prevent privacy breaches, not react to them.

    • Privacy as the Default.  A user should have privacy by default, not have to ask for it.

    • Privacy Embedded into Design.  Privacy is an integral part of the system, not an afterthought.

    • Full Functionality – Positive Sum, not Zero-Sum.  Privacy does not reduce other features.

    • End-to-End Security – Full Lifecycle Protection.

    • Visibility and Transparency.  We should be able to verify that the privacy settings are intact.

    • Respect for User Privacy

      • The user should give consent for the use of their data

      • We should have good notices

  • Cloud shared responsibility model

    • The cloud provider is responsible for some parts of security, and the customers are responsible for some parts.  Security is a shared responsibility.  The level of responsibility depends on the nature of the product.

    • The cloud provider is responsible for the physical infrastructure and its security

    • The cloud provider is responsible for separating data from different customers

    • The customer is responsible for protecting their data, their account credentials, and their internal network

    • For example, the AWS shared responsibility model
  • Defense in Depth

    • Defense in Depth is a military strategy designed to slow down an attack

    • It allows us to create multiple layers of defences so that if we are attacked, we have time to detect and control it, rather than have a catastrophic failure