Least Privilege

This a security design principle in which a person or process is given only the minimum level of access rights (privileges) that is necessary for that person or process to complete an assigned operation. This right must be given for a minimum amount of time that is necessary to complete the operation

The principle of least privilege states that a subject should be given only those privileges that it needs in order to complete its task. It limits possible damage in case of exploited vulnerabilities.

In order to implement this principle, one needs proper granularity of privileges and permissions to apply this principle.

Example

Weakness of some Microsoft Applications: IIS 5 runs under the Local System account, equivalent to root privileges.

Some people recommend that Apache should run as user “nobody” under UNIX

Apache server can be installed as root which is a disaster if compromised. Always use a service account

Separation of Duties

Also known as the compartmentalization principle, or separation of privilege. Separation of duties is a security principle which states that the successful completion of a single task is dependent upon two or more conditions that need to be met and just one of the conditions will be insufficient in completing the task by itself.

The deeper you go into the centre the higher the privileges required

Defense In Depth

Also known as layered defense,

Defense in depth is a security principle where single points of complete compromise are eliminated or mitigated by the incorporation of: a series or multiple layers of security safeguards and risk-mitigation countermeasures.

The message here is: Have diverse security strategies, so that if one layer of defense turns out to be inadequate, another layer of defense will hopefully prevent a full breach

Example

For SQL injection mitigation a layered security needs to be followed:

Validate all the tainted inputs for bad/danger characters

Use of Parameterised prepared statements through out the application

Use low privileged database account for all DB interactions

Can be further enhanced by role based access accounts etc.

Fail Safe

A security principle that aims to maintain confidentiality, integrity and availability by defaulting to a secure state in the event of a malfunction of some sort.

Rapid recovery of software resiliency upon design or implementation failure.

In the context of software security, fail secure is commonly used interchangeably with fail safe, which comes from physical security terminology.

Make your application fail to a known state. Try and roll back to a known good state instead of crashing and displaying a stack trace on the screen.

Unless a subject is given explicit access to an object, it should be denied access to that object, aka Fail Safe Defaults

Example

Apache access control through .htaccess: first (default) rule:
Deny from all allow from… (white listing)

Earlier firewalls used to come with all ports open and one has to explicitly close them to deny traffic on that port. Many security breaches have happened because of this

Now in almost all firewalls, by default the ports will be closed

Economy of Mechanism

This in layman terms is the Keep It Simple principle because the likelihood of a greater number of vulnerabilities increases with the complexity of the software architectural design and code.

By keeping the software design and implementation details simple, the attack ability or attack surface of the software is reduced.

Complete Mediation

A security principle that ensures that authority is not circumvented in subsequent requests of an object by a subject. It achieved by checking for authorisation (rights and privileges) upon every request for the object.

In other words, the access requests by a subject for an object is completely mediated each time, every time.

All access to objects must be checked to ensure that they are allowed.

You need to watch out for:

Performance versus Security issue

Results of access check are often cached

What if permissions have changed since the last check

Mechanisms to invalidate or flush caches after a change are often missing

Example

DNS Cache Poisoning Vulnerabilities

Consider software in which authorisation checking information is cached at client side. This cache is refreshed in certain intervals. Even if the permissions are revoked for a particular user, the user can still be able to perform privileged action until the cache is refreshed

Open Design

Focus on making sure that the encryption key is not stolen. Security by obscurity never works.

The open design security principle states that the implementation details of the design should be independent of the design itself, which can remain open.

Unlike in the case of security by obscurity wherein the security of the software is dependent upon obscuring the design itself.

When software is architected using the open design concept, the review of the design itself will not result in the compromise of the safeguards in the software.

The security of a mechanism should not depend on the secrecy of its design or implementation. If the details of the mechanism leak then it is a catastrophic failure for all the users at once

If the secrets are abstracted from the mechanism, e.g., inside a key, then leakage of a key only affects one user.

Example

Hidden parameters used in Web Applications for authorisation, computation etc. Everyone can read them once compromised

Least Common Mechanism

The security principle of least common mechanisms disallows the sharing of mechanisms that are common to more than one user or process if the users and processes are at different levels of privilege.

Avoid dual functionality – privileged and unprivileged, guest and admin. Avoid using the same login mechanisms for guest Wi-Fi as corporate Wi-Fi. If guest Wi-Fi is compromised then the attacker could elevate their privileges and potential compromise the corporate Wi-Fi as well.

For example, the use of the same function to retrieve the bonus amount for an exempt employee and a non exempt employee could potentially be abused. In this case the calculation of the bonus is the common mechanism which should not be shared.

Psychological Acceptability

A security principle that aims at maximising the usage and adoption of the security functionality in the software by ensuring that the security functionality is easy to use. Transparency is an essential requirement for this security principle to be effective.

Make sure people understand why

Be transparent about security

If people don’t see the value of security, they will defeat it

Security mechanisms should not make the resource more difficult to access than if security mechanism were not present

Problem: If people do not understand why they have to do things a certain way or security makes the whole process awkward, users will look for ways to defeat the mechanism and “prop the doors open”

Examples

Biometric authentication mechanism requiring hair samples

Higher n Factor authentication may discourage users from opting in

Weakest Link

This security principle states that the resiliency of your software against hacker attempts will depend heavily on the protection of its weakest components, be it code, service or an interface. Hackers and pentesters look for weak points.

Leveraging Existing Components

This security principle focuses on ensuring that the attack surface is not increased and no new vulnerabilities are introduced by promoting the reuse of existing secure software components, code and functionality. New components may introduce vulnerabilities. Any new components will need to be tested both in isolation and together with anything that interfaces with them.

We leverage existing components by using trusted secure design patterns, frameworks or libraries.

Conclusion

11 Principles

How they support the core security

Take your design and test it against the 11 principles

They are meant to make you think