There, I said it: stop listening to information security people. Before you fire your security vendors, disable those perimeter defenses and toss your security development processes to the fire there’s more to this story you should know.
On the front page of MSN.com this morning, there was an article entitled “Stop Listening to Suze Orman” and it reminded me of some of the cardinal lessons I learned in a past life as a semi-successful amateur day-trader (hey, I had to bootstrap my security company Impacta some way :P). For those of you who don’t know about Suze Orman, she has a show on television were people call in, explain their financial problems (stocks, real estate, retirement planning, etc.) and she offers her perspective (<– keyword, remember this for later) to callers. The MSN.com article knit picks at some of Orman’s general trading strategies and former stock picks, but if you boil this article down to the bone there’s a very important lesson to be learned here that can be also be applied to information security.
The mistake I made as a day-trader when I was first starting out was to listen to trading/investment experts. If Joe Expert said buy stock X, I would buy stock X. If that same expert said short stock Y, I would short stock Y. I soon realized that doing this was a sure path to financial disaster. First, trading/investment experts are indeed experts in their respective fields and they deserve all the successes they’ve had. However, there’s one field that they can’t be experts at: you. You see, those experts have much larger bank rolls, higher risk tolerances and much more powerful trading platforms that normal traders/investors won’t. So while they can provide a perspective that makes sense for their own situation (i.e., buy stock X), that perspective may not necessarily be the right one for you. The day that I changed my strategy and used advice from experts as a single input amongst others (my personal risk tolerances, my personal financial goals, my own research, etc.) to make my own decisions, and not just following their advice blindly, significant successes soon followed (and a lot of them).
I suspect the same lesson could be applied to the information security industry. Take this common scenario where organizations hire security vendors who run tools and do all sorts of weird and wonderful things to uncover all sorts of information security nasties. A report comes in and organizations blindly follow the remediation steps listed (similar to investors blindly following ‘expert’ advice). Bad idea and here’s why: those reports are based on technical findings and from the perspective of someone who is independent from your business (someone who does not understand your business). For assessing risk that’s a good thing, but when it comes to mitigating risk that’s not always the case. That technical risk perspective may not align well your particular business objectives. Often it does, but in the instances where it doesn’t bad things happen. Applications get crippled due to incompatibilities with recommended patches, money gets wasted on addressing vulnerabilities in areas of the business with lower business priority but high security priority and so on. Potential revenue is lost and the friction between security and every other business function is perpetuated.
Now, organizations are 100% entitled to address risk in whatever fashion they please. That’s not for me to say otherwise. However, what I’ve personally found useful when helping my customers address security risks to help them make better business decisions is to focus on the WHY rather than the WHAT. When you’re presented with a slew of security vulnerabilities that need to be addressed and you don’t have infinite resources to address them all, ask yourself these helpful questions:
- Why does this vulnerability translate to a business risk?
- Why does this impacta (<– sorry, slip on my part :P) the business?
Here’s an example, say you get a report finding that says that you have a potential buffer overflow condition in your application. That’s the what, that you have a buffer overflow condition. Well buffer overflows are bad right? We should spend resources to fix it. Hold on, let’s consider the why.
- Why does this vulnerability translate to a business risk?: If a malicious user is able to exploit this buffer overflow, they could gain access to customer data (confidentiality), modify that data (integrity) or degrade the application to legitimate users (availability).
- Why does this impact the business?: If a malicious user was able to do the above actions, that could degrade our customers confidence with our service. We could also be subject to fines for not having sufficient security controls. All translates to loss of revenue.
Turns out in our example that the technical risk aligned well with the business risk, but asking questions like the above can help you better ensure that that alignment is consistently there. This small perspective shift I’ve found has been a very useful and powerful tool, and has helped me be more effective in security, trading and other areas.
Just as with investing and trading, you know you best. Security is just one facet of your business and not the entire story. So in my experience, when you fold in business factors (the ‘why’) when addressing information security issues (the ‘what’), the better off you’ll be. What are some of the techniques that have helped you?
–Kevin
18 Comments
Interesting perspective but I think you should have considerd how government regulation also impacts the decision making on how and when to address certain vulnerabilities.
Companies and agencies can not just
” choose” what should be fixed if they want to be compliant with HIPPA, GLB, SOX etc.
You do need to rely on outside experts that understand these regulations inside and out and how they impact your business.
Great entry Kevin.
Totally agree on the need for true business alignment.
Have you seen or used the SABSA methodology?
It is an open source information security framework that enables business risk / technical risk alignment.
http://www.sabsa.org/
Hey Bruce, thanks for taking the time to post a comment. First you’re right, companies under compliancy restrictions sometimes can’t just “choose” what they want to do. When I said to look at why something translate into a business risk, I meant ‘risk’ broadly to also include risks from failing to be compliant with things like HIPPA, GLB, SOX. That said I didn’t call it out directly, and I am glad that you specifically pointed this out! It’s an important point that should not have been overlooked like I did. So thank you!
–Kevin
Hey Michael, thanks for sharing the like to the SABSA methodology. I haven’t seen this methodology before, but I took a look at it briefly and it definitely looks interesting. I like how it starts with business requirements first instead of doing the technical analysis first and seeing how it aligns to business requirements later. Also, traceability throughout the process is very interesting, especially in high-business impact scenarios. Good stuff, thanks again!
–Kevin
Good article — I started to reply but thought it better to add it to a blog myself ;o).
http://sectalk.blog.com/4617937/
This exactly what I talk about Business…..and I would go little further, Business is nothing but calculated risk, you have taken your chances , so its right to provide the risk assessment and different scenarios, but more often than not business is gut geeling ….Kevin, would be interested in your comments on my blog http://hack0r.blogspot.com
Hi Rodney, thanks for writing a reply even if its on another blog! :)
–Kevin
Hi Kevin, I thought that this was a well written article and had good content. I would advise others in the business community to expect and demand more of their security vendors. As one of those security vendors, we run our tools, prepare our reports, but we take the process a step further than you outline. As a good security partner to our customers we interview key stake holders/business leaders to understand what matters to the organization. Based upon and in combination with our findings, we make remediation recommendations.
While agree with your article’s content, I would only add that perhaps you have not encountered a professional enough security vendor!
Bill great comments and thanks for posting! It very well may be that I haven’t encountered enough security vendors :), but I think that even if I did (while I was corporate employee, I am a security vendor now myself :P) I still think we would see the same problem. All the assessment techniques and tools are great at pinpointing risk, but all that risk is really technical risk. I haven’t seen very many that can take that technical risk and express it in terms of business risk very well, I think tools like that would really invigorate this industry! Thanks again for the comments and I am glad you enjoyed the post!
–Kevin
Vijay, apologies for approving your comment late (your comment made it into the spam filter so I didn’t see it until recently). Regardless, thanks for taking the time to post and share. You make a good point about businesses and calculated risk. There’s risk that we as business owners have calculated and addressed in some way, and then there are those that we have not. Then to mix that bunch up even more, there’s also perceived risk versus actual. Good stuff!
–Kevin
Nice story, Kevin, very nice metaphor as well. Thanks.
Bruce Tucker said: “Companies and agencies can not just ‘choose’ what should be fixed if they want to be compliant with HIPPA, GLB, SOX etc.” Of course, he’s right. However, they CAN choose whether or not they want to be (fully) compliant with HIPPA, GLB, SOX etc. Of course, as with any choice, you get to suffer the consequences.
In my opinion, there’s a difference between “not having a choice” and “facing a dilemma”. A month or so ago, the Dutch health inspection published a report stating that in many hospitals, username/passwords (U/PWs) were not treated as it should (people would know each others credentials, or they would be written down). I think that this signal, as any other signal of violations of commonly used security policies or practices, should be addressed. To me, addressing such a security signal differs from “going for the first solution that makes the signal go away”. People do things for reasons, even if you’re not aware of that. You need to find this motivation, and then find a solution that both accommodates for this motivation, and makes the signal go away. Employees of a hospital told me that abiding by the security policy with respect to U/PWs, they get to put off operations once in a while because e.g. the artificial hip wasn’t available in time for the operation, the cause of which was that the person with appropriate permissions for the ordering system had fallen ill, or got an accident. Putting off an operation not only provides (psychological) damage to patients (if not worse), but also disrupts the primary process, and lowers the staff’s morale, and there’s this waiting list for patients that they need to shorten… Their solution (in general, people know pretty well how situations can be solved) however could not be implemented in the ordering system.
So here it is: there is a signal saying that U/PWs are not handled securely. There can be (at least within the operating theater of one hospital), good reasons for this. In this case, addressing the issue is making (business) choices, which is not just a business privilege, but a business obligation, specifically in what is perceived as a dilemma. Security signals are just messages to telling the business that once again it’s time to make some choices.
Hi Rieks, thanks for the comment and nice post! With regulation/compliancy sometimes you don’t get a choice as to what you can or cannot fix, but sometmes you do (i.e, you’re not under regulation, or there is flexibility within regulation). When you do have that choice, then it’s in my opinion that business owners should be making sure that security decisions are aligned to their business objectives is really at the core of my point, which I think fits nicely into your “facing a dilemma”/”not having a choice” model. The notion of security signals as how you explained it is also really interesting, definitely got me thinking now ;P
Thanks again for your post Rieks!
–Kevin
I think your opening statement “Stop Listening to Security People” is misleading, incorrect, and disrespectful to information security professionals everywhere. Pause for a moment, in this world of cyber-criminality just think where this world would be without information security people. I would suggest most businesses would not be in operation.
I am a security professional and have been for nearly 10 years now. In matters concerning risk it is my ethical duty to present risk in such a way that provides the client with a clear “understanding” of it and the “capability” to consider the most appropriate solution. My primary security approach is to be a business enabler, not disabler. Too much security cripples business through indirect cost and loss. Most of my colleagues sing from this same hymn book.
Here are my professions Code of Ethics Preamble:
Safety of the commonwealth, duty to our principals, and to each other requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior.
Therefore, strict adherence to this Code is a condition of certification.
Code of Ethics Canons:
Protect society, the commonwealth, and the infrastructure.
Act honorably, honestly, justly, responsibly, and legally.
Provide diligent and competent service to principals.
Advance and protect the profession.
Are there vulchers out there? Of course! But they’re in every facet of business, not just information security.
Companies that hire security vendors should consider the WHAT they are trying to accomplish. WHAT risk are they trying to counter. Then assess they WHY. Once your done you have the pavement to get to the HOW, which will lead to the WHO and the WHEN. Perform the appropriate comparative analysis and research on similar products to ensure the right product fit. That’s just common business sense.
The title of your article may turn heads, but it doesn’t fit with your story and is disrespectful to my profession. You may want to consider changing it to “Why you shouldn’t throw all your eggs in one basket” since the article has more to do with business ethics than Information Security.
I digress…
Hey Gerard thanks for the comment and post! Interestingly enough, I am part of your profession (I am an information security professional as well) too; however I apologize that you (or anyone else) felt disrespected, I believe there was one other guy on LinkedIn who was none too happy.
You’re right, we should not stop listening to our security vendors 100%. My point was simply to state that when we’re making business decisions based off security risks, those decisions should be based on a variety of information and not just security (the WHAT). Security is just an input, not the only input. As someone who used to work for a corporation (the customer) and now as a security vendor, I’ve seen and helped my own customers from making the mistake of making a business decision just because something pops up on a vulnerability scanner (i.e., what I am saying is not the final decision, just another input for you to make a good business decision). My intent was to share this small, but important point with the community at large even though it’s common sense, as you pointed out, for most. Maybe “Focus More on the Why Rather Than Solely The What” would have made more sense, moot point now :P
Thanks again for taking the time to post,
–Kevin
Kevin,
Your article was spot on, the business criteria or requirements are often not considered by what I’ll call the Security “purist” when recommending a new security approach. I’ve lived through many of the consequences you outlined when a purist approach is taken, resulting ultimately in a diminished role of the Security group. Good job.
MM
Hey MM, I am glad you enjoyed the article and thanks for leaving your comments! A lot of people have commented (and some flamed :P) that what I was talking about is business common sense, but often times it’s these small things that have big impact! Thanks again!
–Kevin
I had to really think about what you were saying for a while; because I believe what you have done is mixed several unrelated activities together. While I appreciate you’re sensationalizing the article with an outlandish headline to get readers to read (hey, it worked on me), the premise of the article is simply flawed.
Security professionals who run tools do not make business strategy recommendations. They usually deliver technical details on the potential exposures and explanation as to how to address them from a technical perspective. It is their job to deliver every single potential exposure as a finding (after verifying these findings are not type 1 or type 2 errors), not to judge exposures for impact.
Senior management within organizations needs to review these findings and align those vulnerabilities to mission-based risk and decide if the exposure is worth mitigating (usually via an impact and cost-benefit analysis). This step is done (or should be done might be more appropriate), by those within the organization with knowledge of the mission goals and can understand the hazard these findings may present to those goals.
Hey Wade,
I think we might be on the same page, but if not I still appreciate that you took the time to speak up and voice your opinions and thoughts.
You’re right about security folks analyze for for technical exposures, and to some degree they need to also indicate what the technical impact that exposure might create. My point in one sentence was to ensure that the business impact (the why) and technical impact (the what) were aligned. Again I think we’re more aligned than it appears. Again, good stuff!
–Kevin
One Trackback/Pingback
[...] but often we focus too heavily on the the what rather than the why. I previously wrote a post on how prioritize risk (the why), which boiled down [...]