You can spend a lot of money on security technology. You can spend a lot of time developing security policies and procedures. And you can have security awareness training sessions once a year for staff. You can do all of these things and still have major security incidents.

Why is security so hard to get security right, even when you do all the things the standards, manuals, books and courses say you are supposed to do?

Every technology has limitations. You can’t depend on technology to fill in the gaps. It is one of the most static components of security. Once you have installed it and configured it, you can’t expect its behaviour to change to suit your changing organization or its changing environment. You must understand the technology’s limitations, and understand what it does and doesn’t do for you in meeting your security objectives.

For example, an Intrusion Detection System (IDS) or an Intrusion Prevention System (IPS) do many things in similar ways, and some things differently. They can both look at network traffic and identify patterns that usually represent threats to normal operations. IDS will send an alert to the Security Operations people in order for them to initiate a response, while IPS will often be able to take immediate action to stop the threat (while also sending alerts or writing log entries). So, it would seem logical to assume that IPS is a better technology to deploy, since it is able to take action on its own. But what if the type of network traffic your organization normally encounters in daily operations is something that would cause a lot of false positives (traffic incorrectly identified as a threat) in an IDS or IPS system? Having an automated system take action when it is incorrectly identifying a threat could cause havoc in your critical business systems. So, sometimes you may need to have a human in the loop to look at an alert before deciding to initiate a response. Somebody has to decide on what the right technology approach is.

In the case of policies and procedures, you may think you are ahead of the game by using another organization’s governance documentation, saving a lot of time and money. But what happens when your main operational Web application has 100,000 daily login failures, and the cloned documentation calls for logging of every login failure with time, date and username information, but no IP addresses, and no login failure limits before lockout? You may have reams of logs, but no idea where attack on a thousand usernames a day may be coming from, or how to stop it without shutting down the whole system. Somebody has to review the policies regularly to make sure they are appropriate for your business systems.

Finally, you can train people annually on security awareness, as most security standards require. But you can still find daily violations of security policies that should be preventable in just about every work environment. I was at an appoinment to see a medical professional recently, and was led to the examination room and asked to wait. The office had a desk with two files less than an arm’s length away from my chair, and a few more that were within easy reach. On the outside cover of each file, without opening it, I could easily read the name, address and sex on each of them. Had I wanted to learn more about them I could have just opened the files during the 10 minutes while I waited to be seen. Suppose someone had this information and waited a few days, then called the patient, saying “Hi, I’m calling from Dr. Rosenhorse’s office…” Sounds like a pretty credible source, and who knows what could be gained from the patient at that point? Was this a sign of poorly written policy, poorly defined procedures, poor facilities to support the procedures, or poor handling by the humans involved? Whether the procedure existed or not, it should be common sense for staff to take the precautions of at least keeping personal files out of sight or out of reach of waiting patients.

The reason I used the three different dimensions of techology, procedures and people in these examples was to illustrate how each aspect of security depends on the others. Not only that, but it shows that the most difficult part of getting security to work properly in an organization is in getting the more flexible human side to adjust to fill in the gaps created by the more rigid parts. Humans have a critical part in the success of every type of safeguard. Technology and procedures don’t change very often, but humans behave differently every day, unless they are given knowledge, motivation and the means to behave consistently. Even then, it is not a 100% guarantee. The good part is that humans can think on their feet, and they can report when something is not looking quite right.

The bottom line is that the humans involved in choosing and implementing the technologies, drafting and enforcing the policies and procedures and executing their daily jobs must all understand the value of their roles and the importance of the security safeguards they work with every day. The safeguards have to be appropriate and must be applied consistently in order to protect the value of each individual’s contributions to the organization.

Therefore, I submit that the problem is almost always with the people. Do they understand the organization’s objectives, its values, the value of the systems they interact with and their role in protecting it? Fixing these things at every level of the organization can often do more to improve security than adding newer technology or stricter policies. Make sure the human part of security is the top priority.

Finally, I don’t believe security awareness training on an annual basis is nearly enough to keep staff focussed on what the important things are in their jobs, and how to safeguard them.