Key Secure Design Principles

In this article we will review some of the key principles that need to be considered during the design process. These principles will help meet the security needs of the software.

It is worth noting that these principles are widely used and are also proposed in many of the existing secure design approaches either as core or supplementary principles that need to be considered.

Least privilege

This principle recommends that the users should interact with the system having the least amount of privileges required to perform their tasks.

When it comes to data this is a clear requirement under GDPR. However, using broad privileges a bad idea of the security of any part of a computer system?

A simple answer could be that allowing users to have such privileges could intentionally or accidentally result in malicious access to protected system resources as they are able to perform activities that are beyond their proper rights.

A typical example of such a case could be the assignment of administrative privileges to a user, which could cause modification or editing of sensitive operating file or even the installation of malicious software.

Another reason why this is important is reducing the potential attack surface. We have already seen that human error is a major cause of cyber threats. If a users privileges are locked down, then the amount of damage that can be caused is reduced.

Separation of duties

This principle recommends that the responsibilities/duties and privileges should be separated and split across different users or services.

Two main reasons why separation of duties is necessary for the proper design of the system security is because:

Allowing a user to have all the responsibilities/duties and execute all or most of the system processes could end up being a huge vulnerability for it as it could be tempting target for social engineering or insider threat attacks.

Decentralising the duties, we can have better control of the system operation, limit the impact of successful attacks and make attacks less attractive (e.g. insider threat) as each user does concentrate all the important duties or privileges required for the operation of the intended system.

Making changes to systems and software typically requires a number of approvals, which require the involvement of more than one person. For example, implementing changes to firewall rules is separated from approving those changes as a basic security control.

Keep Security Simple

This principle recommends that a system should be designed in a clear and simple way avoiding unnecessary features and functions. This will improve the understanding of the system’s security requirements.

But, why should we keep security simple?

Good Security requires good understanding of the system design. A complex design is rarely understood resulting in insufficient analysis and security of the system.

To avoid complex failure modes, implicit behaviour, etc.

For instance, adding a new application to an old operating system could trigger possible system inconsistencies. Hence, we should consider carefully whether the system needs that “additional” functioning feature that is added to it.

Do not Invent Security Mechanisms

The application of this principle suggests that you should not create and use your own security technology, try always to use a proven component. This can also come under the principle of "Keep Security Simple", using libraries the complex elements of security to the experts can help simplify the overall design of the system.

Why you should not trust your own security mechanisms?

• Firstly, the generation of security technology is a difficult task and it is usually a specialist job
• The use of your own mechanisms, instead of the industry security standards, could increase the system vulnerabilities.

Example

Sanitising user input is really hard.

But in most of our programs we will have to deal with user input. So we either limit functionality, or have to come up with some way of making it safe.

Lets say you try to avoid XSS in your application, by stripping out <script> tags. you might think that a simple replace replace("<script>","">) would be sufficient.

However, this fails almost instantly. For example: - <SCRIPT> will be allowed through - <scr<script>ipt> does something interesting too....

Its much easier to make use of a well known and tested library for this piece of security.

Warning

NEVER, roll your own crypto! (except for learning, or I tell you to as a lab task) Regardless of how good you think it is, its probably insecure.

Audit

This principle suggests that a system needs to keep a record of the core and significant security events that occur during its operation.

Again, this principle make our compliance with GDPR simpler. If we have a clear audit trail, we can understand how and why data is accessed, and in the case of a data breach understand the extent of it. A strong audit process can also be part of an automated defence and response system using tools like SIEM

Typically, an audit trail can be proved useful every time there exists a system failure as we need to know how it happened and why. Moreover, it can provide us with a log that will be able to reconstruct the past events that resulted in the failure or lead to the retrieval of a stable and secure system state. Finally, it could also act as a monitoring point and as a deterrent to people who are malicious.

A typical case of auditing events is the regular recording of the changes to sensitive or confidential system files or even the changes that take place regarding the registered users of the system.

Fail Securely

This principle advices that when a system fails, it needs to do that securely. This means that its failure should have the minimum impact possible for the system’s security or functioning.

In other words, a secure fail could mean that some of the core security principles of a system could be maintained even if other security principles are not satisfied. For instance, the confidentiality and integrity of a system should remain even though availability has been lost. Another example could involve a secure fail in case of a successful attack, where the attackers must not be permitted to gain access rights to privileged objects during a failure that are normally inaccessible, exhibiting a secure fail for that system.

Finally, it should be noted that a secure fail related to the access control system of an operating system should “deny access to the users instead of granting it”. This guarantees that unauthorised users will not gain access to it, benefiting from that failure.

Don't Rely on Security by Obscurity

Security by obscurity principle proposes that the security of key systems should not rely only upon keeping details hidden.

Why we should not rely on security by obscurity? Some of these reasons are presented below:

• Keeping information hidden does not imply that it is secure.
• Security by obscurity is a weak security control, and nearly always fails when it is the only security control point.

Securing software by keeping its source code secret be should not be the only security practice. Other practices like password policies, defence in depth and audit controls could also be considered for its security.

Example

You create a web application, which has an admin interface. You try to keep the existence of the interface hidden, by not publicly listing the URL. One of the first things I am going to try when breaking into your site is to look for URLs containing things like /admin. Similrlary with "hidden" subdomains like dev.application.com

We will look at some example of this in a few weeks when for web security.

TODO: Can I add a Poll, What's the first thing I would look at....

Note

We will have some real, practical examples of this in BFF Part 2

Defence in Depth

This principle suggests the application of multiple security layers that can prevent a single point of failure.

Defence in depth is needed to ensure that the security level or protection of a system cannot be massively affected by the failure of a single security mechanism, as there will be other mechanisms that may still be able provide the necessary security to protect the system.

For example, assuming that the firewall of a network system is penetrated, defence in depth could utilise encryption to protect the data/information of the system.

Summary

I this article we have explored some of the most commonly used secure design principles.

Secure design Principles #designprinciples

Review the design principles discussed above.

Research secure design, are there other principles that you feel are important? Next rate the design principles discussed, and any others. Which one do you feel is most important?

Discuss your views using the tag #designprinciples on the feed.