The Tenets of Security

Good security practices help to create good security implementations. Within the security community, there are a few tenets that come up time and again. Many or all of the implementation best practices can be traced back to these principles, which are explored in the next few sections. I have found that these tenets, when carefully followed, help to ensure effective security.

An important observation is that these tenets are proactive and persistent. They must be analyzed and discussed before any coding, and certainly before anything goes into production. They should also remain constant both in time and in applicability. They should apply to all applications, databases, and digital and nondigital processes.

Security by Design

When asked, “When does security begin?” many will answer when the user authenticates. It’s a trick question. Security begins when the application is designed. The first tenet is this: Security has to be built into the system, not bolted on afterward. This is also the overall message of this book. A proper security design helps to ensure that an application will be secure.

By applying this principle to an every-day example—automobiles—a powerful analogy becomes apparent. In today’s world, automobiles are built with security features incorporated by design. Door locks are probably the most obvious example. For the sake of argument, assume the opposite. Pretend that automobiles don’t come with door locks. (In fact, at one time, this was true.) Assume when the car is built, it has a door that is easily opened all the time. Door locks and other security measures were considered, but they interfered with the usability of the automobile and drove production costs up. Substitute the word “application” for “automobile” in the previous sentence and you may recognize a familiar argument.

To ensure my analogy is consistent, consider security only after the car has been built. Assume the car is now delivered, and you, the owner (user), immediately recognize the security shortcomings. Because the car has no locks, what can you do to secure it? Perhaps you are envisioning a car with a big chain and a padlock around it. Perhaps you are thinking of a way to retrofit something on the side of the car that would be used to attach a rope around the door handle.

Whatever security solution you think of, it’s probably not elegant. The same applies to database applications when security is not part of the design. In many cases, performance and practical implementation issues may prevent the security “feature” from actually being used at all.

The lesson is simple: make security a first-class citizen. Spend some time thinking about the application from the security angle before you start building. In the end, you will have a much more functional and secure application.

Defense in Depth

The second tenet for effective security says that security should be a multilayered composition. This is commonly known as “defense in depth,” and it implies there will be no single point of failure from within the security domain. By creating multiple layers or rings of security, you can generate a system with higher security assurance. If one layer of defense is defeated, another will hold. And you don’t need to be limited to just two; you want as many layers as practical. Defense in depth is successfully employed in many areas of technology, and it’s also applicable to database applications.

Automobile designers today practice the defense in depth principle. To prevent automobile theft, cars are secured by more than just door locks. Breaking the window to unlock the car doors is easy. Many cars come equipped with sophisticated alarm systems that not only sound an alarm but also disable the ignition system of the car. If that’s not enough, the car can be further protected by placing a metal bar across the steering wheel, preventing a would-be thief from successfully steering the car even if they were able to start it. Each layer incrementally adds more security.

A bank also represents a wonderful example of defense in depth in action. The first layer of security lies in the robust construction of the bank. The bank walls are fortified. Inside the bank, bullet-proof glass and physical barriers separating the bank customers from bank employees provides additional layers of security. Perhaps even a security guard is employed as another security measure. Valuables in banks are secured by a huge, nearly impenetrable, time-operated safe. There is no single point of security failure within the bank. If the security guard calls in sick, it does not imply that the valuables in the safe are immediately accessible.

Within an enterprise IT infrastructure, defense in depth is just as important. You use firewalls to separate the outsiders from the insiders. You may also use network encryption to protect data as it travels within the walls of an organization’s intranet.

To further protect insiders from other insiders, you can utilize operating system security and application security. If the data is what you are trying to protect, then you also have to apply security where the data lives. This means you have to add the layer of database security. The databases act as the impenetrable safe or data vault. The job of the database, like the job of the police, is to both serve (the data) and to protect (the data).

By using the appropriate security tools, designed and deployed in layers, you can set the groundwork for a truly secure environment.

Least Privileges

The third tenet of effective security is to maintain least privileges. “Least privileges” means you give people only the permissions they need to do their job and nothing more: you give them the least amount of privileges. One of the easiest ways to compromise a system is to exploit accounts that have been granted too much privilege.

The least privilege principle is probably practiced in many parts of your life already. For example, an employee usually does not have the privileges to grant themselves a salary increase. Most employees can’t approve their expense reports either. Why? Even though employers generally trust their employees, there is too high a risk that the privileges could be easily abused.

The process of abiding by least privileges is simple: start by granting no privileges and then give only the minimum privileges needed. Not following the least privilege principle can result in serious consequences. Why isn’t this principle followed regularly? One primary reason the least privilege principle is not practiced is laziness. (I hate to use that word but I believe it to be accurate.)

Consider a database example. For administrators who are unfamiliar with database security, it generally takes work to ascertain precisely what privilege(s) are needed to perform a set of tasks. Documentation has to be referenced, and even then the answer may not be obvious. The shortcut is to grant all privileges. This is bad.

I see examples like the following all the time. Assume a database application developer needs the privileges to create a database table and a database procedure. Instead of granting the two simple privileges to perform these tasks, the user is granted the database administrator (DBA) role, which provides the user with unrestricted access to the entire database. This makes life easy for the developer because she can now create tables and procedures. It makes life easy for the administrator because he doesn’t have to know what privileges were needed, nor will he be bothered with any more privilege requests since the developer now has every privilege in the database. This creates a huge risk because the developer can now do anything—read any table, update any data, execute any procedure in any schema, and so much more.

Database security is based on privileges. Privilege abuse cannot occur if the privileges haven’t been granted in the first place. While it requires some effort to determine what privileges are needed, it’s essential for maintaining least privileges and least privileges are essential for effective security.