Among those looking for the answer are new CSOs overwhelmed by the prospect of overhauling an organization's security infrastructure and business people thinking of how to cost-effectively improve security. What they all have in common is the search for a simple answer to a complex issue, and they are all asking the wrong question.
"What product should I start with?" is a very common first question, but it has about as much use as approaching a doctor and asking, "What medicine should I take?" Unless you are displaying some extremely obvious symptom, the answer is likely to come in the form of additional evaluation questions, and likewise with security implementations.
Before prescribing a cure, the patient, in this case the organization, needs to agree to a self evaluation. There are, at a minimum, three core questions that every organization, c-level executive, security consultant and others must be able to answer honestly before receiving a proper security diagnosis.
There are, of course, tens or hundreds of additional follow-up questions that could be applied both within and in addition to these three, but here in no particular order are the three questions to ask when considering where to start.
- Why are you doing this?
- What are you trying to secure?
- What will happen if you don't do this right?
Question 1: Why are you doing this?
In my experience, no one comes to the decision to be secure because they have had an epiphany and now believe that security is up there with purity, charity, and chastity. It is always because something has happened. It can be because they just took a class, or attended a Webinar or seminar. Maybe they were breached, or found out that a company in their space had been breached. Often, they are simply asked to do it by a manager, or an auditor, or an executive.
Depending on what the motivation is, the first steps can be different. If they have been breached, clearly they need to complete whatever triage and clean-up they are performing, and need to establish a means of both protecting against re-infection or re-emergence of remnants of the same exploit. This means that the short answer to them is that they need to think about why they are interested in security, and then start of by understanding the reasons why they are not secure enough yet. This provides a much more focused goal for them, and also gives them a language and context to talk about their security within.
Question 2: What are you trying to secure?
This is a question that is usually particularly enlightening about, and for, individuals newish to the space. The gut reaction in many is to answer "my networks," but when pressed, or when given more time to think, they may answer "my data," "my business," "my reputation," or "my time." Depending upon their actual goal, the answer to this question leads to a litany of others, about the specifics regarding whatever body of resources they are really looking to protect. Security is among the most murky disciplines in the entire technical catalog, and it requires this kind of self-examination to get a handle on what is actually needed because in an absence of a real strategy, it can be argued that anything will make it better, but few organizations just want to get better, they want to be at least good enough. Good enough is very related to what is actually supposed to be secured, and how secure it has to be.
Question 3: What will happen if you don't do this right?
Human nature, or at least the noble components of it, inclines us to want to do the right thing. I think people ask advice about security because they actually want to be better informed and do a better job. This is all to the good. Unfortunately, in many cases, the yearning for security tends to cool pretty abruptly when confronted with the chilly reality of funding, inconvenience, and change. Security is not free, and good security is neither cheap nor convenient.
At the start of any new security process, or at the start of an extension to an existing security program, it is very important to ask this question, because knowing whether it is imperative or interesting will make all of the difference in the choices that should be made. If failure will mean loss of jobs, and revenue, and reputation, then there will be pretty robust support for the person who wagers their career on creating an effective means of addressing all the issues, even if those means are not easy. If, on the other had, failure will mean that someone's status report is yellow, or that the managers need to sign a waiver, or that a vendor gets a very strongly worded letter, the security champion should keep that in mind when he or she finds it necessary to either push hard and escalate, or compromise and close on the issue.
Security is not a word with a strictly defined meaning and so it must always be approached situationally. These questions, and all those that they will in turn engender, will help to set up an environment in which there will be a balance between the intention for security and the likely willingness of the organization to help to make it a reality.
About the Author
Jack Danahy is founder and Chief Technology Officer of Ounce Labs and one of the industry's most prominent advocates for data privacy and application security. Danahy is a frequent speaker and writer on information security topics and has been a contributor to the U.S. Army War College, the Center on Law, Ethics and National Security, the House Subcommittee on Information Technology. His blog can be read at http://suitablesecurity.blogspot.com.
About Ounce Labs
Ounce Labs' solutions enable organizations to identify, prioritize and eliminate business risk to the enterprise caused by software security vulnerabilities. With Ounce Labs, organizations strengthen application security, protect confidential information and verify compliance with both internal policies and industry mandates. For more information, please visit www.ouncelabs.com.
Click here for original article.
