Introduction

This article’s focus will be a compilation of my 10 years of experiences across 5 different industries. It aims to help the reader avoid the most common mistakes that I have seen within the Information Security (herein referred to as “security” for brevity's sake) industry as a whole. It will cover the following areas:

1. Failures in leadership

2. Improper reporting relationships

3. Using technology to solve behavior problems

4. Overlooking the obvious

5. Shadow security

6. Not taking culture into policy creation

7. Negativism

8. Mixing policies and procedures

9. Inadequate maintenance of documentation

This paper covers more of a 'premisis/network security' perspective rather than a “coding practices” or product's inherent security or insecurity.

In the Education, Manufacturing, Telecommunications, Healthcare, and Financial institutions these 9 problems cover most of what one will see. They are easy to avoid, but often difficult to overcome. The greatest cause of failure for a security program is a failure in leadership.

Failures in Leadership

Often, organizations like to distribute security across various business units. In the last organization that I worked for, security was not centralized. Each business unit had its own ‘standards’ with a central reporting compliance department that had no real power. Projects would try to get security done, only to have to appease 10 different people from 10 different departments, each with their own spin on how to interpret the security policies. The diffuse nature of security ensured that it would never get adequately implemented. Additionally, lack of management support made this even worse.

Management needs to get in the game, and get in early. If a security department is launched in a haphazard, unplanned way, without senior management’s guidance and approval, it will have no teeth. People will just “thus sayeth the CEO, we must get our project done or the business will end”. They will simply ignore or overrun the security program to go to production on time. If the CEO, CIO, COO, and CFO and other major stakeholders in a company have supported a security program, such items will be a non-issue. Additionally, management needs to be aware of security and its impacts on “go live” dates, etc, so this can be factored into business timetables. The same can be said of the education sector, only instead of CEO, etc. It is deans, etc. Finally, all layers of management should be informed in a brief letter what is going on from the security department. This makes up for lack of communication among the different levels of management. The person who security ultimately reports to also is of vital importance.

Security Reporting to CIO of Information Technology (IT) and its Hazards

In many organizations (*healthcare especially*) security is more of an afterthought, and the Chief Security Officer (CSO) reports to the Chief Information Officer (CIO). This is an untenable situation. Security functions are inherently hostile to IT functions. IT is about getting things done on time, and ensuring that users are “happy.”

Security is about keeping things “secure” or “safe”. This often can initially ‘anger’ customers who want things yesterday, with no planning etc. Additionally security often performs an audit role, where the auditee is often IT. You don’t want the fox (the CIO) watching the henhouse (IT). It is a clear conflict of interest.

When the CIO is running the show for security, security will ALMOST always take a back seat to production problems/dates.

Security departments who report to the CIO will see the following symptoms:

1. Figurehead security departments with no authority

2. Loss of efficiency in the security department

3. Low morale of the security department

4. Failure to adequately protect business from harm

5. Conflicts of interest, and lots of hostility

6. Use of technology to solve behavioral problems

Ideally security should report to a CEO or someone who is OUTSIDE of IT. This ensures the protection of security’s autonomy, and ensures honesty in reporting and functions. It also avoids the conflicts of interest that often arise from reporting to the CIO.

Another problem of having security inside of It is the danger of using technology to solve behavioral problems.

Using Technology to Solve Behavioral problems

People in technology are often blinded by the “Mantra of Technology” which says, “Technology can solve any problem.” This, especially with computer security, could not be farther from the truth. Let me pull some examples from my various workplace experiences:

Example 1: Users having predictable passwords. The corporation has just gotten a nice fresh audit from a notable “big four” company. One of the items on the audit was that user passwords were “predictable and easily cracked.” The recommendation was to have a minimum length of 8 characters, with a upper, lower, special, and a numeric. A technologic measure was put in place to ensure that this recommendation was followed. Passwords were remembered for 12 iterations, and expiry was set to one month. Users started writing their passwords on wallets, under keyboards, and on sticky notes. They never logged out of their PC’s, they left their pc’s unlocked (too inconvenient to type in password to “unlock” it!). This kind of password was simply too difficult for users to remember, especially those “on the road”. They inevitably called helpdesk, who promptly reset their password to “password” and asked them to relogin.

Example 2: Additionally the audit found that “remote” users should use “strong” authentication to prevent password replay. The corporation dutifully bought RSA SecurID tokens, and issued them to all remote personnel *(especially remote vendors)* who proceeded to take tokens, leave them on desks, with pin and UID attached, so “anyone” on support could use them.

In the two examples above, we see fundamental human behavior, in this case, laziness, foiling the best technology that money can buy. Don’t forget this when recommending the next 10k/sensor IPS etc. that smaller issues can make your wonderful technology next to worthless without adequate understanding of WHAT you are trying to protect against. Overlooking the obvious is the next item that often causes difficulty in most establishments.

Overlooking the Obvious

Often folks in technology circles have a difficult time of seeing the obvious. For example, a hospital has wonderful perimeter controls, firewalls, IPses, system logging, anti-virus, and patching, but fails to lock down/eliminate Internet Explorer and Activex/java controls.

The firewall quite happily keeps evil people on the outside, but what about users on the inside? Secretaries go to ‘shopping sites’, pick up all kinds of malware, spyware, and Trojans. The trojans take over her pc, sending out corporate data RIGHT THROUGH THE FRONT DOOR, via HTTP, or even better, HTTPS.
An even better example of overlooking the obvious is a tale of datacenter disaster I once encountered at two hospitals I worked at. In both cases they had full camera monitoring, fully staffed 24x7 personnel, card-key access, Halon fire suppression systems, fully redundant back up power on two separate circuits, full climate control etc.

Being that one of these hospitals was located in a hurricane prone area of the country, the designers decided that they couldn’t waste precious hospital space on those “musty old computers.”. They located their datacenter in the SUB BASEMENT, failing to take in account what happens to most water (it goes down). With one hurricane, they had to put PLASTIC wrap to keep the mainframe from getting wet due to the leakage from the ceiling.

In another case, a different hospital I worked for had all redundant equipment in the same rack, in the same datacenter! Why have redundant equipment if it is all in the same place? Why not put it in a different datacenter, or at least a different part of the datacenter? In one case we almost lost all the equipment due to a leaky pipe above the ‘redundant’ rack in question.

What affect does this have on security you might ask? Simple: The CIA triad (Confidentiality, Integrity, and Availability) requires availability. Things aren't too available if they are under 8 feet of water. hence the security concern.

Perhaps one of the most challenging problems I have ever had to meet is what I term “the shadow security state”

The Shadow Security State

There are those organizations who don’t really want security. They want the ‘feel good’ but ‘change nothing’ figurehead known as a CSO in order to appease regulators or outside agencies. This kind of situation is ethically the most challenging, and the most difficult to change.

In a shadow security environment, management wants all the appearances of security, with none of its inconveniences, cost, or required behavioral changes.

I worked at such a place for 6 months. We regularly had 40+breakins per week (we had no perimeter controls to speak of), mostly involving spy-ware, or malware. In one case, a medical imaging device became infected.

The incident was mentioned, but nothing was done. The device was patched, but I was encouraged ‘not to share’ this information with anyone outside of security. This could have been a good opportunity to share with heads of departments how important keeping things patched was. This pattern of ‘hide’ it so we won’t get sued by the HIPAA folks continued. I suggested writing an incident response policy, but was met with a “that’s too complicated for our environment, and that if we had a formal policy, we could be held liable.” The manager in charge of the security outfit had been hiding such information from the people who could have helped change it, and needed to know. They buried their heads in the sand, and woe to the person who pulled his or her head out. I was promptly terminated after they decided I didn’t fit the model of “Shiny, but inactive” security analyst after 6 months. The security department was seen as a “black hole” into which lots of things entered, but nothing came out. As such, it was a total failure, but the people in charge wanted it to be that way. Security departments also often fail to take culture into consideration when writing policies or defining architecture.

Not Taking Culture Into Consideration

This often manifests itself when writing policies and procedures, and then failing to consult with users on how they actually DO the things that they do (their culture). For example, a requirement stating that “All users must never share an id and login under their own id” seems perfectly logical from an IT perspective.,

But in an emergency room, this totally fails. You have a large population of users who need to look up patient records, have to be highly mobile, and most importantly, is an incredibly chaotic environment. Nurses would often login to the workstation, and just stay logged in. Anyone passing by could just use the computer, and often did.

A better solution was implemented after realizing this. The hospital in question (a different one), decided to make an exception, create generic ids with limited privileges, and to use an alternate mechanism to allow nurses to login to apps. They used fingerprint readers to authenticate people into apps. This worked beautifully, and took the culture into consideration.

Additionally, all the textbooks, CISSP exam materials, etc. say that “default deny” is a great stance. Everywhere except for academia. Often professors need, expect, and demand complete academic freedom. If you block everything, the dean will simply fire you and hire someone who will keep the professors happy. A better solution in this kind of an environment, is to ban only known “unsafe’ protocols, since you will NEVER know what a professor may try to do and fail. Security is more of a ‘clean up’ and reactive within this type of environment. Negativism can also have a huge effect on the success of a security program.

Negativism and its Affect On Security

The next item is more a condition of the security practitioner’s heart and mindset. It isn’t one of skill, or ability, but of views. It is easy to become overly negative, considering the kinds of people that we often deal with. It is easy to become jaded and cynical as one progresses in one’s security career, seeing the same mistakes being made time, and time again. Here are some of the attitudes and their outward affects on the environment that one works in:

· Only providing roadblocks- Rather than providing solutions, security only provides “don’ts” with no follow up. People often don’t know how to resolve problems, and that is why you have been hired.

· Saying “NO” rather than enabling business to do what IT needs to do securely- Business owners have the right to choose to accept a risk that you may deem “unacceptable”, but in their eyes is. Security must document risk, provide adequate explanation of risk, and transmit that risk to business owners. We cannot (except in certain rare circumstances) force business owners to take a given security measure.

· Dealing negatively with external vendors/contractors- Again, as one’s time in the industry increases, one begins to see a very high level of incompetence on the parts of vendors/contractors. This is simply a fact of life. Most people just don’t know how to think, and nothing will change that. But allowing this fact to impinge upon how we treat our customers, no matter how dim-witted, unpleasant, or pushy, makes us look bad. We don’t have to tolerate abuse, but neither are we entitled to hand it out.

· Talking “badly” about customers/users/coworkers- Again, this kind of goes along with the previous example. It is very tempting to give in to gossip. It seems like a stress reliever. There is usually some so-and-so who really makes us angry. There is always that inconsiderate person who wants to heap blame upon us. But giving into the “gossip monster” only makes the gossip grow. It is my policy to never (as much as possible, we all have slips now and again!) say anything bad about anyone at work, or to simply not comment upon another’s incompetence, stupidity, arrogance, or other negative trait. I have gotten into all kinds of interpersonal problems because someone heard something that I said about them in ‘confidence’ to another co-worker. Talking about these things with trusted friends outside of work is highly encouraged, however. Keeping all this in is unhealthy for the mind!

· Talking negatively about management- We have all had this situation, where upper management doesn’t seem to “get it.” It is way too easy to fall into “management bashing”. Everything from seeing them make the same mistakes, again, and again, we feel ignored (remember nasa anyone?), judge them as incompetent and stupid (which may be true, but they are the boss!), etc. Simply don’t do this. It is a wonderful way to end one’s employment prematurely, especially if someone hears who isn’t supposed to. Cubes have ears.

Mixing up policy and procedures is another common pitfall

Mixing Policy and Procedures

Many organizations mix up policies and procedures.

Policies:

1. High-level statements NOT how to implement

2. Should be no longer than 10 pages (probably WAY less!)

3. General, and Technology independent

4. Must be signed, and approved by senior management

5. Don’t change that often

6. Point to procedures for specific items

Procedures:

1. Support policy in day-to-day running of business

2. Describe HOW things are done

3. Change frequently

4. Are specific to each user community they affect

5. Are often quite lengthy

6. Should be “split” into role-based groups (keeps docs smaller for end-user)

Finally, most places fail to maintain documentation (mostly procedures).

Failing to Maintain Documentation

Frequently, the most neglected items are:

· Adequate and accurate network diagrams (you plan to make firewall rules without them?)

· No accurate inventory of assets, and to whom they belong (this is critical for understanding what you need to protect!)

· Procedures become out-of-date due to changes in technology

· Procedures become impossible due to changes in technology

· No “emergency” guides. Panic ensues whenever there is a break-in, worm, etc. due to lack of written and accurate procedures for incident containment.

Conclusion

These 9 items that I have discussed are by no means a complete list. They do, however, accurately reflect my 10 years of experience in information security. I think of all of them, however, the negativism is the biggest killer of infosecurity programs. I myself have fallen prey to it, and it has impaired my performance more than any of these items. Maintaining a positive attitude is quite difficult, since we are essentially police men/women of the network. No one in IT loves a security person (except after a break in). We are a solitary crowd, who often have to be loners because of what we do. We often deal with incredibly sensitive information, information where the temptation to use that information incorrectly exists. By maintaining a positive attitude (lots of hobbies!), the temptation and animosity are reduced, and hence the temptation to use the information we are trusted with incorrectly diminishes. I hope this article has helped you in understanding some of the pitfalls of our industry(s) and how to avoid them.