As you probably heard about the term ‘Secure-by-Design’ in software engineering, which basically means that software products and capabilities should be designed to be foundationally secure. However, this approach has been widely adopted for broader systems architecture and engineering design not just software engineering. In particular, in the field of information security accreditation practice, it is the approach required by the well-known Certified Information Systems Security Professional (CISSP) offered by ISC2. In this post, l’ll discuss the key design principles underpinning secure architecture and engineering in the context of CISSP framework. For an easy digestion, I have categorised the 11 secure design principles as three S, two T, one PDF plus one KLZ. Let’s unpack each capital letter.
Three S
Shared responsibility principle. In a shared responsibility model, multiple parties team up to meet a common goal. For instance, a cloud service provider that offers virtual machines in the cloud is responsible for securing the virtual infrastructure, network and storage; their customers are responsible for securing the operating systems of the virtual machines.
Secure defaults principle. While comes to secure defaults, think about how something operates brand new, just out of the box. For example, a wireless router comes with a default administrative password, and the software that performs lookups in a database might, by default, use a legacy protocol or method. Securing default configurations is important not just for pre-packaged hardware and software; if you are developing a product or service, you should build in secure defaults. For example, if your service operates over the internet, you should use the latest version of TLS by default. Or, if you are creating software for a firewall, you can make the administrative portal by default, only available on the LAN interface and not the WAN interface.
Separation of duties (SoD) principle. It refers to the principle that no user should be given enough privileges to misuse the system on their own. A simple example is a person authorising a pay check should not be the same person who can prepare the check.
Two T
Threat modelling principle. It is a process to identify, catalog and organise threats that pertain to your environment (often a single application or service at a time). There are different models that organisations use. One very popular model is the STRIDE model (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege). Others include PASTA, Trike, Dread and VAST.
Trust but verify principle. The expression “Trust but verify” is an old Russian proverb that has made its way into information technology as well as many other areas. For example, an email sent by a user on your corporate network would normally be considered trusted (it comes from one of your users, on one of your devices, on your network). But, just in case, your anti-virus systems would still scan it to verify it’s not malicious before it goes out to the internet.
One PDF
Privacy by design principle. With this principle, it is recommended to take a proactive approach and build privacy into you apps and services from the beginning. There are 7 recognised types to achieve privacy by design:
1. Proactive, preventative. Think ahead and design for things that you anticipate might happen.
2.Default setting. Make private the default. For example, if you develop a social media app, don’t share all of the user data with everybody by default.
3.Embedded. Build privacy in; don’t add it later.
4.Positive-sum. Achieve security and privacy, not just one or the other. (And don’t focus more on one than the other.)
5.Full lifecycle protection. Privacy should be achieved before, during and after a transaction. Part of achieving this is securely disposing of data when it is no longer needed. Visibility, transparency, open. Publish the requirements and goals. Audit them and publish the findings.
Respect, user-centric. Involve end users, providing the right amount of information for them to make informed decisions about their data.
Defence in depth principle. To adequately protect your environment, you need to have multiple layers of defence. That means combining multiple products and services together. Sometimes, these products and services work together and sometimes they work independently. Let’s look at one real-world example: email. The first line of defence is protecting your domain names through private registration and locking changes. On top of that, you might incorporate Send Policy Framework (SPF) to limit who can send email from your domain. Then, you will have an anti-spam/anti-virus scanner on the internet, prior to allowing email into your network. Thereafter, you will have host-based anti-spam/anti-virus on all computers. Finally, you might have email client security (attachment filtering, previews turned off, additional spam filtering, etc.). Working together, these comprise defence in depth. This concept applies across all aspects of your environment security.
Fail securely principle. This principle refers to that when something fails, it must not reveal sensitive information. For example, if a web application fails, it shouldn’t reveal the directory structure, lines of code and other internal IT information. Additionally, when something fails, it should not end up in a less secure state. In some cases, failing securely is reverting to defaults. And that’s when secure defaults come into the mix too.
One KLZ
Keep it simple principle. The term “keep it simple” refers to reducing complexity and keeping things easy to understand. Reducing complexity in your system, service or environment helps administrators keep it healthy, simplifies troubleshooting and makes it easier to secure. When designing a secure solution, you should try to keep it simple to take advantage of the benefits.
Least privilege principle. The principle of least privilege refers to that an entity is granted the minimum system resources and authorisations that the entity needs to perform its required function. For example, an administrator who manages Windows servers doesn’t require and shouldn’t have administrative privileges to Linux hosts.
Zero Trust principle. Zero Trust is a methodology that authenticates and authorises all users and devices as though they are untrusted, and authentication and authorisation continue to occur throughout the day. Historically, users with devices on a corporate network were automatically treated as trusted and secure. With Zero Trust, even users and devices on a corporate network go through the same validation as users and devices outside the network. Some organisations describe Zero Trust as a model that forgoes the traditional network edge (where the corporate network meets the internet). Zero Trust is a way to enable people to securely work from anywhere and from any device.
