The principles of security

There are some principles that we always have to remember when we speak about IT security, since they can really help to prevent the most common security problems.

The Principle of Insecurity

I have called this principle the Principle of Insecurity because I have not yet found a better name for it. This principle states that no matter what you do, who you are, and how much money you spend, you will never have a 100 percent secure environment.

An example of this happened on April 7, 2014, when a new version of OpenSSL was published with the announcement of the Heartbleed bug having been fixed. This bug allowed users to extract a memory (RAM) dump from any machines that were running unpatched versions of OpenSSL. OpenSSL was considered safe and therefore the majority of the companies worldwide have used it and embedded it in their products to the point that in April 2014 there was close to no alternative to it. But even if something is very standard and wide used, it does not mean it's 100 percent secure.

Something that is always important to remember when we speak about security, is that money is limited, and it is often hard to evaluate how much money we can spend on security. To evaluate how much money it makes sense to spend on security, a mathematical economic model called the Gordon-Loeb model was developed in 2002, which tells us that it makes sense to spend up to 37 percent of the expected losses that would occur from a security breach. This model is widely used and is a well-accepted analytical model in the economics of cyber/information security literature.

Security is a journey, not a destination. Security is always an ongoing process.

The Principle of Least Privilege

The Principle of Least Privilege (also known as the Principle of Minimal Privilege or the Principle of Least Authority) requires that any user, process, or system has all but only the permissions required to complete the assigned tasks. This is one of the most important principles on security and usually the one that is least considered.

I can write about many examples I have seen where the violation of this principle brought about very bad situations. Not very long ago, I saw a simple process that only needed to access (in read/write) one folder and to read from a database, wiping a machine and the multiple remote disks that were mounted in that moment, because the process was running as root instead of a limited user, as it should have.

What happened was that the process was removing all the files in a subdirectory with the bash command:

rm -rf $VAR/*

Here, the $VAR variable was set reading a field in the database. The database did not respond (because it was down) and therefore the variable was empty, allowing the process to run the following:

rm -rf /*

This is deadly if it is executed by root, since it will erase all the mounted storage devices, including the one containing the Operative System (the logs, etc.)

Note

When it comes to the Principle of Least Privilege, remember that rank does not mean full access. A company's CEO may need to see more data than other inpiduals, but he/she does not automatically need full access to the system just because he/she is the CEO.

The Principle of Separation of Duties

The Principle of Separation of Duties (also known as Principle of Segregation of Duties) requires that a complete task cannot be done by a person alone or that a person cannot perform all actions on a system. The basic idea of this principle is that completely trusting people could be unsafe for these reasons:

• People can make mistakes
• People can be malicious
• People can be corrupted or threatened
• People can take advantage of their position

This is always hard to accept for companies, but we have to face the fact that people are not perfect if we want to create a secure environment. The separation of duties (and powers, due to the Principle of Least Privilege) helps the people too, since they will be less prone to take advantage of their position and also they will be less attractive to those who wanted to bribe or threaten them.

A world-famous example of the consequences of failing to keep up with this principle is what happened at the National Security Agency (NSA) in 2013. On June 10, 2013 Edward Joseph Snowden, a private contractor working at NSA, leaked thousands of classified files from the NSA. This was possible because he was allowed to copy (and bring out of the facility) that data without the involvement of other people in the process.

People are often the weaker link of the security chain, so never underestimate people when thinking about security.

The Principle of Internal Security

The Principle of Internal Security requires that a system is defended by multiple layers of security, each one protecting it from a particular type of attack. Often this principle is stated not as a principle but as a technique with the name Defense in depth and Castle Approach. Data center designers should study a castle's fortification structure, since castles are very good examples of this principle. Very often, I see data centers with only one level of security and once you are able to violate it, you are free to go wherever you want. Castles, on the other hand, have multiple layers of security and even when you pass a security layer, you are still being watched. Also, the defenders in the towers will have a better spot than you because they are in enhanced security facilities, and there are no blind spots where you can hide.

We have to design data centers with the idea that the single security layers (and potentially all security layers) could be breached. This means:

• Putting in multiple (different) security layers
• Monitoring in and around the security area, leaving no blind spot
• Training your people to react immediately to breaches
• Don't create strict reaction schemas, because if leaked, these could be used against you
• If breaches occur, study them and study countermeasures
• Run frequent tests to be sure all systems are active and your people are ready to react

IT security is as much about limiting the damage from breaches as it is about preventing them.