Feb 22, 2005 (01:02 PM EST)
Rob Enderle: You Are Your Worst Security Liability
Read the Original Article at InformationWeek
While IT managers scramble to buy products to guard against external threats, they're ignoring the enemy within.
No, I'm not talking here about dishonest and stupid users. The threat that security managers fail to protect against is themselves: You. You're failing to protect against your own errors in setting up network security.
You fail to take into account that threats will move where you are weakest, and not where you have strengthened your defenses.
You don't have to be the most secure, you simply have to be secure enough to either effectively block reasonable threats or convince attackers to attack someone else. You can't have perfect security; you have to optimize your available human and financial resources.
Mistake One: No Security Goal
You should go beyond simple data security or physical plant security and include the security of traveling executives, branch offices, home offices, and key partners. Remember that most breaches now come through unsecured endpoints, so endpoints are where you will probably need to start, with regard to setting your goal.
Mistake Two: No Risk/Security Assessment
It is important that this assessment be done by an outside party who will not be involved in any corrective action, to avoid any conflict of interest. An insider, or outside vendor involved in implementing your security, might be tempted to cover up their own mistakes when they do the assessment. An insider might focus the effort to change the power structure inside the firm. And an outsider involved in implementation might over-inflate security expenditures to drive up their billables. By using someone that is independent of your company and your provisioning security vendor, you help insure that they are focused on your company's needs and not their own.
This is not a one-time event either, threats are rapidly changing and you will need to change your security plan to address these changes. In my view you should do this annually; this allows the assessment entity to remain up to date on your firm and gives you a relatively current assessment to use as a baseline to help determine needs when looking at changes or purchases addressing your security needs. Firms and organizations under high threat would probably need to do this more often, and there are some instances where an ongoing assessment would be the most prudent.
Mistake Three: No Plan
And that has never been truer here. In many cases, the layers of security you need are often interrelated. Think of it like building a skyscraper, if you didn't have a plan you'd likely not build the foundation strongly enough.
I remember a hotel I visited in Micronesia; it was made out of solid reinforced concrete and it was paid for by US taxes. They didn't think of plumbing and electrical wiring until after the structure was built . That oversight resulted in one of the ugliest buildings I've ever seen in my life, because both plumbing and wiring had to be run outside the building and through the halls, and then core-drilled into the rooms.
You often see failure to plan at national borders; they will spend a lot of money securing the border-crossing. while people continue to cross the border illegally, out of sight of the border station. This is the same as security the front door and datacenter but allowing rouge wireless access points in the company, which can bypass this physical and electronic security.
The security plan needs to address the issues identified by the risk assessment.
Mistake Four: Linux/Firefox
I just chose these two platforms because some rather foolish people are making generic recommendations to move to those products to address security needs.
This mistake is actually more commonly made with security products.
The vendor will come in and pitch you using an insurance sale. An insurance sale is one where the salesperson scares you half to death by graphically describing possible, but unlikely, catastrophic events to get you to buy something you otherwise wouldn't buy. The buyer expends resources already targeted at something else to address this scary threat.
In the case of an OS or browser — neither of which are really security offerings in and of themselves — this practice may actually open you up to exposures the rest of your security infrastructure can't adequately address, because your security infrastructure was not designed with those platforms in mind. In many cases, the result of a platform change is actually a less secure environment, because the change is done without properly reconfiguring security infrastructure.
This doesn't mean those platforms are less secure, only that their introduction weakens the security infrastructure, because it wasn't designed for those platforms. The infrastructure needs to be redesigned to address the change.
Products come last. You may, in fact, decide to move platforms, but that decision should come as a result of the plan and not despite or without it. Platforms often have to balance between ease of use and security. Managing that balance requires adequate skills and surrounding products that can mitigate any related exposure.
In the end, your company has layers of security around it, much like a home surrounded by fences, with locked doors and windows, and with a panic room inside (a secure room with hardened walls you can lock yourself into if someone breaks into your home). The nature of the exposures you face, your resources. including the skill sets of your people, and your access needs define the nature of the security solution you provide. Designed right, you can do amazing things with a small amount of money and some training, done wrong you can spend millions and actually become less secure then you were when you started. The path is yours, here is hoping you pick the right one.
Rob Enderle is an analyst specializing in emerging personal technologies. He heads the Enderle Group, and has been an IT analyst since 1994. He spends his free time building computers and playing with personal technology prototypes. He can be reached at email@example.com. Contact the editor of Security Pipeline at firstname.lastname@example.org.