Ten Hard Questions About Security: Question 1


Question 1: Who should I trust?

This question should be in the back of your mind for every solution you are designing or consulting on, every answer you give to every question you are asked about security, and every decision you make in regards to enterprise security.

Information security spending is nearing $100 billion yearly across the globe, and everyone and anyone with an IDE and a couple of programming classes under their belt thinks they can produce a security solution that is "ground breaking" or "turnkey" or "industry leading" or "complete, holistic end-to-end".  Most of these claims may be true for their own business, as most of these products are simply a small piece of niche security on top of a myriad of already existing solutions which you are probably already utilizing.  Don't be wowed by their flashy advertisements, cheesy taglines, or brash statements.  There is only one person you should be trusting to make decisions for your enterprise: yourself.

Now, don't let your head get too big.  That wasn't a compliment, it was a caveat.  If you want to be trusted within your enterprise, you have to give reasons why you should be trusted.  Title alone does not dictate good decision making.  It simply means that someone trusted you to have the final say in their enterprise's security.  While we are not giving compliments, let me not give you another one: You are not infallible.  You are human.  Humans make mistakes.

Computers make mistakes too, but the difference is that a computer only does it what a human tells it to do.  Whether the computer's error is poor code, incorrect configuration, or the all-too-common using a non-security product as a security product, all of the inherent issues with a computer system ultimately come back to an error or decision by a human.

How can I take the human element out of security?

You can't.  While security systems can be great at detecting well-known security threats, and even unknown security threats, a human has to be the driving force saying "yes, this is a threat" or "no, this is not a threat".  Sometimes those humans belong to your organization, and sometimes they belong to a vendor from whom you are purchasing services or support.  Sometimes they are right, and sometimes they are wrong.  The same intelligence refers to fixing software. Sometimes, a bug fix to one piece of code can open holes in other locations.  It's not common, but it can happen.  Test thoroughly.

Who or what should I let influence me?

There are plenty of "trusted" sources out there.  Gartner "magic quadrants" are usually the favorite of C-level decision makers, and anyone else who doesn't do the research themselves.  Even though a picture may be worth a thousand words, the magic quadrants don't tell the whole story.  The axes on the Gartner version for products in any space, not just security, are usually labeled "Completeness of Vision" and "Ability to Execute".  The quadrants usually themselves contain labels like "Challengers", "Niche Players", "Visionaries" and "Leaders".  When you really think about those labels, none of them infer anything negative about the products reviewed, not that they really should.  They really concentrate on the overall product, not important factors like a specific functionality you may be concerned with, or the ability or likelihood of smooth integration into your environment.  Weigh the factors like those closely.

Then there's the "untrusted" sources; bloggers, "industry experts", and other people who do perform enterprise security for a living.  While their advice may be sound for their particular situation, it does not mean it is right for yours.  There is no "one-size-fits-all" solutions in the world of security.  This applies to both physical and logical security.  While one company may brag about how secure their enterprise data centers may be, if you are in a co-location situation, this doesn't affect you.  Likewise, if co-location providers list the merits of hosting your infrastructure with them because they are so secure, and your enterprise has some legal or contractual requirements to host onsite, their measures may not be sufficient for your enterprise.

Then there is the most dangerous category of all: the people who pay the bills.  Sometimes, the most expensive solution is the best.  You recognize it, your teams recognize it, your administrators and architects recognize it.  You go through whatever processes your company may have in place to purchase said solution, but you can all guess what happens next.  The people holding the purse strings aren't willing to pay for it.  Whose fault is it?  No one's really.  Most financial people in the business world are not IT focused.  Conversely, IT people can tend to want to overspend on solutions just because they are the newest, shiniest piece of technology out there.  We are probably all somewhat guilty of it, whether in our personal lives or at work.  The allure can be hard to resist.  If you really believe that a piece of technology is the best for your needs, be prepared to defend your situation in terms of money.  Think of the value of the assets being protected, both physical and intellectual.  That's the scariest number.

Trust, but verify!

Advice is great, but we've all gotten bad advice at one time or another, whether it be personal or professional.  The heading says it all.  Fact/source/data-driven analysis of any complex problem will lead you to a more rational solution. I don't infer fact, source, and data interchangeably there.  They are 3 separate and distinct drivers in your decision.  Data is no good if you don't know the source from which it came.  And if the source from which the data comes is not basing the data from factual information, it's as good as garbage.  Let the data do the work for you. It may not always be the answer you were looking for, but it's an answer.  Don't allow your personal feelings to cloud the decision.

Got a suggestion for more content?  Feel free to leave a comment below.  The questions are meant to be "living documents", allowing for reference over time.

Comments (0)

Skip to main content