I’ve been a bit lax with the blog lately and for that I’m sorry.  The reason will be clear in a few weeks when I hope to be able to make an announcement.  For now though I’d like to just provide my apologies.

This post started out as my commentary on two recent articles that appeared in CSO Magazine concerning the data breach at Heartland Payment Systems (“Heartland CEO on Data Breach: QSAs Let Us Down” and “SQL Injection Attacks Lead to Heartland, Hannaford Breaches.”) 

Now what I do to write these posts is basically sit down and let it just flow out of me.  I then go back and do a little clean up as needed.  Sometimes the clean up needed is so much I just trash the post.  Other times I realize that a concept that came up late post is really what the post should have been about in the first place.  That is the case this time.  So I’ve basically thrown out three quarters of the pontificating (which you really didn’t want to hear anyway) and focused on the analogy that information security is much like professional cooking. As I put this together I glanced down at the word count and realized that this was growing to be much more than the simple post that I initially envisioned.  So what I’ll do is break it up into a few parts to try and get my point across.  Let me know if I was successful. 

How did I come up with this analogy?  Well it was mainly sparked by a comment made by Heartland CEO Robert Carr in the first article mentioned above.  That comment was:

“The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem. The QSAs in our shop didn’t even know this was a common attack vector being used against other companies. We learned that 300 other companies had been attacked by the same malware. I thought, ‘You’ve got to be kidding me.’ That people would know the exact attack vector and not tell major players in the industry is unthinkable to me. I still can’t reconcile that.”

In this first part I’m going to set up the analogy and then dive into it within the subsequent posts. 

While I’ve been critical of some of the statements that Mr. Carr has made in the past I basically think that he has done a great job in responding to the crisis his company is in.  True he may have been forced into this response by circumstances but I’m not going to look a gift horse in the mouth.  A CEO of a major corporation has finally come to realize the importance of information security in the daily operations of his company.  However you look at it that is a good thing.  That he has become proactive in advancing our cause is an even better thing. 

What concerns me though is Mr. Carr’s statement.  He may be doing the right thing but I don’t want him to do it for the wrong reason because in the end it won’t help us out, it may even hurt us. 

You see Mr. Carr’s statement smacks of “missing the forest for the trees.”  He seems to understand that he must do something but doesn’t really understand the real reason behind it.  So this is my effort to try and shed some light onto the subject.  Will Mr. Carr ever read this?  Who knows but that really isn’t important as long as this helps someone.  So if this makes sense and you want to use it go right ahead.  (Just give me credit in some way.)

Let me take a stab at reconciling the issue.  The QSAs didn’t necessarily fail.  They audited to a known and accepted standard.  PCI DSS didn’t even necessarily fail; it is what it is a standard.  What failed you was the commonly held assumption that compliance equals security. 

When push comes to shove, SQL injection has been around for a long time so the fact that systems are still regularly found to have input validation issues is surprising.  Since we can’t blame the QSAs should we blame the developers?  We could but again we’d be missing the forest for the trees.  These are but symptoms of the problem.  How do we get at the problem?  In trying to get a handle on this I’ll try my hand at a little analogy.  That being that Information Security is a lot like professional cooking.  I’ll illustrate this by first focusing on how recipes are a lot like standards (Part Two) and then I’ll move on to broaden the image by relating what we do in information security to working in a professional kitchen.

Tags: Compliance, CSO Magazine, Data Breach, developers, Heartland Payment Systems, information risk management, insider threat, PCI, PCI DSS, professional cooking, professional kitchen, QSA, recipes, risk management, Robert Carr, SQL Injection, standards

I was perusing the blogosphere and came across a post written by Sam Dekay over at BlogInfoSec.com.  Apparently it was sparked by the recent laying off of a friend.  The post focused on where Information Security fits within the grand scheme of any organization.  In the case of Mr. Dekay’s friend, that company was reassigning information security functions across several existing areas rather than have them assigned in one area.  The Office of the Chief Security Officer was to no longer exist. 

Apparently the company didn’t see the value in having the responsibility for security residing within a single department or person.  As information security professionals we want to make sure that everyone in an organization realizes that they share in the responsibility to use and protect information appropriately but this protection needs to be coordinated in order for it to be effective.

I’ve touched briefly on where security should fit into the organizational structure in Nomenclature and Where should the CSO or Network Security Reside within the Corporate Structure?.   This problem also seems to exist across all industries (See The Guerilla CISO Blog: Needed Agency CSOS), so the question is now becomes why. 

Many of the business drivers associated with information security are negative drivers.  Compliance issues or responding to a security incident are reactive in nature not proactive.  Somehow we have developed an approach that is fed by negative incidents rather than positive incidents.  We spend so much time just trying to stabilize what we are doing that we can’t seem to move forward and as such are seen as a drain on a company rather than an asset to be utilized.  This is all part of what I call the Silver Bullet Mentality.

The Silver Bullet Mentality involves the mindset that security issues can be solved by technology.  “If only we could find that product that does X our problems would be solved.”  This mindset has typically resulted in declining revenues (information security is commonly an overhead function which eats into the overall profit margin).   Since security is seen as a technological issue our value as trusted advisors is limited to technology.  That has relegated us to overhead status that can be cut when the company tightens its belt. 

One of the reasons that I like the term Information Risk Management is that it implies that information, and the protection thereof, needs to be managed.  It incorporates the concept that the appropriate protection of information involves people, process, and technology. 

We first must understand the people part of the equation.  This includes understanding the nature of the business and the people involved with that business (both employees and customers).  From people we move on to the processes involved in meeting business needs and demands and finally on to the technology which can be defined as the tools used to facilitate the processes.  This type of model has been used in many different ways and is no way unique to Information Risk Management. 

The difference is that instead of using negative drivers in an effort to drive security, we are using security to drive business.  The arguments that we, as an industry, have been using (we need to do this or we’ll be hacked, or we’ll fail the compliance audit, etc) just don’t work anymore (if they ever truly did).  The executive level isn’t motivated by fear, their motivated by achieving a goal.  We need to show how we can not only support business but how we can contribute to improving how our organizations do business.  It is in that way that we move from being seen as an impediment to being seen as an asset. 

I was talking with Abe Chen, a friend and former cohort member in Norwich University’s MSIA program, about the successes he has had in redefining the value of information risk management to the executive level of his company.  “Make friends with Sales and Marketing” he said.  “They know what is resonating with customers and partners.”

“I decided to reach out to Sales and Marketing while working on a particular project.  When I did they (Sales and Marketing) immediately saw the benefit that information security could bring to how they portrayed the company to new customers and partners.  They knew they could use it as a market differentiator.”    

This isn’t a one way street either.  Sales and Marketing can give you valuable insights into what makes your company competitive thus giving you the insight and information on where you can to contribute to business improvement.  

“The added benefit to reaching out to Sales and Marketing was that as soon as they realized the benefit my project (and information security) would provide, they were able to sell it to management.”    Abe relayed. 

How much more powerful would your next budget request be if you had a profit generating department in your corner with you; making the case for you? 

Going back to the BlogInfoSec.com post, it is unfortunate that Mr. Dekay’s friend was laid off.  While I don’t know the specifics of why his department was made redundant, I can only speculate that his management didn’t fully appreciate the value information security brought to the company.  We should let it serve as a lesson to all of us that we need to either learn the language of business or risk being made redundant ourselves. 

Tags: Abe Chen, BlogInfoSec.Com, CSO, information risk management, negative business drivers, organizational structure, people-process-technology, Sam DeKay, Silver Bullet Mentality

I was recently involved in a discussion over the different terms used to describe what we do? Information Security (IS), Information Assurance (IA), or Information Risk Management (IRM). Some very interesting points and observations came out of that discussion so I thought I’d echo them here.
The discussion started on the Norwich University MSIA program alumni discussion forum. One of the graduates, Steven Hickey (MSIA ‘06) started the discussion by making the observation:

A colleague of mine, who also works as an Information Assurance (IA) professional (DoD specialty), argues that the CISSP certification has “absolutely nothing to do with IA.” He is of the opinion that Information Security is not Information Assurance and sees “no similarities” at all (ummm… none?). Anyway, from a DoD 8570 perspective, the IAM (managerial) level II and III are required to have the certification while none of the IAT (technical) levels are required to have the CISSP.

This started a discussion that went in two main directions – whether the CISSP certification is useful in both the technical and managerial realms (I won’t touch on this here) and whether or not Information Security (IS) is a subset of or has anything to do with Information Assurance (IA).

There were several great posts to this discussion. One was by John Graham (MSIA ‘04):

Although the DoD has ‘coined’ the phase Information Assurance, in my opinion the concept certainly is broader than information security, and information security is a subset of the information assurance space…knowing and understanding the concepts required for the CISSP only strengthen the Information Assurance professionals tool kit…

And

I have always found it interesting that most organizations tend to initially focus on technical controls, then gain the understanding of the required linkages to process and governance needed to actually implement and maintain the controls.
Information Security certainly does provide the control aspects, and the technical depth. When companies start looking at reasons why they have trouble actually ‘implementing’ information security policies, they begin to see the need for broader discussions more in line with information assurance.

Sharon Mudd (MSIA ‘08) took the concept even further.

I agree with John. To expand on that, in my view the entire space is going through a maturation process. What was once Information Security (focused strictly on IT) evolve into Information Risk Management (allowing it to broaden a bit) and is now heading towards Information Assurance. Each evolution incorporates what was there before and enhances the importance of getting out of the InfoSec silo and into the other areas where it runs into business processes/needs(or government, or whatever other entity you’re working with).

and

What was the original foundation of InfoSec seems to be what we’ve been referring to as Security Operations – or – the day-to-day hands on the firewalls/IPSs/etc. work that must be done even monitoring and incident detection can fall into this category. Where I think it goes over the wall to a risk management activity is when you start trying to understand what the alerts mean in context of your business functions and managing the issues from a cost/benefit or risk/reward perspective.

I believe the term “evolution” in this context is key. One of the things that I have enjoyed about being a consultant over the years is the variety of environments and networks that I’ve been privileged to become acquainted with. Most of the time the issues that I’ve come across had very little to do with the technology. Most technology issues were symptomatic of deeper alignment issues.

Many of the highly specialized (or more tactical) activities that IS “grew up with” have now begun to be relegated back to the network and infrastructure departments. Our role has evolved into a strategic role that bridges business units. IT, and by extension IS/IA/IRM, has been the one department that is typically siloed off from the rest of the company in terms of being fully integrated into business operations. This is most likely do to the fact that IT basically began as a support function not much above the mail room in importance. The companies that have seen the advantage of integrating IT and IS into their strategic planning process have gained a commanding advantage in the workplace.

Once you achieve an alignment with the business objectives, IS/IA/IRM projects are easier to sort out and prioritize in terms of their overall value. As we all know this requires that both the business units and IT cooperate in achieving the common goal. One key aspect of this is the use of a common taxonomy. In the end, whether we call it information security, information assurance, risk management or “skippity do” doesn’t really matter all that much as long as we achieve the ultimate goal of bringing value to our employers. The terminology may be determined by the sector in which were working, such as the DoD example, or it may be something that we can influence.

I believe that we must learn the language of business. Business won’t learn the language of information security – that is what they hire us for. The approach that requires management to learn “our language” is doomed to failure. Whatever the case I’m more of an advocate of using the terms that most clearly conveys the concept to my audience.

Tags: business, DoD, information assurance, information risk management, information security, language, MSIA, Norwich University, risk management