If you have been in the security field for any amount of time, you have most likely heard of the "10 Immutable Laws of Security Administration" ( https://kktechkaizen.blogspot.com/2010/02/how-to-think-like-hacker-scott-culps-10.html) published by Scott Culp of Microsoft back in the year 2000, or the collective update published by the Microsoft Security Research Center (MSRC) known colloquially as version 2.0 (https://technet.microsoft.com/en-us/library/hh278941.aspx) sometime after.
If you have NOT heard of these laws, and your job title contains the word "security", start clicking those links above and get your printer whirring. They should be somewhere visible on your workspace at all times. Despite their age, they have held up quite well over time.
The original 10 dealt with protection and prevention, or staying ahead of the "bad guys". It always seemed very reactive to me, and rightly so. The field of information security was still in its infancy as an industry. The majority of people employed in 2000 in information security worked for anti-virus vendors, as the virus was seen as the force majeure for exploiting security flaws, either in products or in computing environments.
The second version dealt with guidance and preparation, or placing you on the defense and preparing your systems for an attack. In moving from a reactive to a proactive stance, the second set accomplishes far more than the first from a preparedness standpoint. However, it still seems to me that this set addresses security as an afterthought and not a design decision.
I will only say this once, but I'm going to say it in all caps: SECURITY SHOULD NOT BE AN AFTERTHOUGHT!
Do I have your attention now? Even if your eyes immediately caught the all caps and kept reading from there, good. You'll have time later to go back and review the laws after you've asked yourself these questions, but we will get to that in a moment.
Here's some questions I'm sure some people may have, just on the title:
- Why are they questions?
- They are questions because someone already wrote laws, and I wanted to be different. 🙂 Seriously though, some people don't respond as well to statements as they do to questions.
- If you ask a child a question such as "Did you clean your room?", you will usually get one of three answers: Yes, No, or <insert excuse here>. With a positive response, you can elicit praise and move on. With a negative response, you get the chance to ask another question, such as "Why not?" or even "Could you go do that now?". Even with an excuse, you get the chance to ask follow-up questions pertinent to the excuse and it's bearing on their ability to complete the task.
- If you address a child with a statement such as "Clean your room.", the response from most children will probably not be entirely positive. Typical responses may include crying, stomping, screaming, running away, or falling on the ground and acting unable to move. The children will have some responses, as well.
- Why are they hard questions?
- The hardest questions are the ones to which we don't want to hear the answers. The questions which make us doubt ourselves, our work, our previous decisions, and our expertise.
- Why are there only ten questions?
- There aren't only ten questions. Each question is meant to invoke more questions. Conceivably, each question could invoke ten more questions, with each of those invoking more questions (I think you see where I'm going with this...). This set of ten is merely meant as a starting point to start a conversation within your team, organization, or company. I've also included some follow-up questions to start the conversations.
- Why didn't you call them "immutable" like the laws?
- Because no question can be immutable. Questions are inherently subjective. If we hearken back to the "Did you clean your room?" question, every parent and every child have a different definition of "clean". The questions are inherently vague; there are no "yes or no" style questions, or even multiple choice questions. Think of the answer to each question like a short essay, potentially containing more questions. Quite philosophical, I know.
- Is there a test at the end?
- Yes. The test is to see if your thoughts about enterprise security have changed. To see if your perceptions of solution design have changed. To see if your mindset around implementing security from the start is really about doing what is secure instead of what is easy.
Now then, on to the questions. I'm going to follow each of these up with their own longer entry.
But before we see the list of questions, I just wanted to say this: This is not by any means an authoritative list. I am providing these as food for thought for security professionals, IT administrators, CIO/CISO, and basically anyone involved with enterprise-level security matters. Also, there is no order to the questions. Each is meant to function independently, although the follow-up questions (or answers, if you think you have them) may apply multiple times, and there may be some cross-referencing.
OK, now on to the questions. Really. I mean it this time.
- Who should I trust?
- Whose system is this?
- What would a highly publicized security breach cost me?
- Quis custodes custodiet?
- How will this change affect enterprise security?
- Is this an industry best practice?
- Is time being spent recreating products or functionality that are already generally available on the open market?
- How old is that product/appliance/hardware/system?
- Whose idea was this?
- Technology is not a panacea?
Chew on these for a while. I'll be back every week or so with a post about each question.
If you choose to post a comment below, please keep it civil. This is not a finger-pointing exercise. It is an exercise in questioning the "status quo" in IT security, and in developing IT security talent.
One last thing: The title of the series says 10 questions. Really, there will be about 15 posts on this subject. I can count, I just chose the title because "10 hard questions" sounds better than "15 vaguely interrelated posts".