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

Have you ever left a meeting frustrated that you didn’t get your point across?  Have you ever wondered why other people don’t “get it” when it comes to security?  I certainly know that I have and it was a moment like this that initially caused me to look at the problem differently.  I decided to turn the question around and began asking myself what I was doing that got in the way of other people getting it.

That was about 10 years ago and since then I have learned quite a bit about communicating effectively.  That isn’t to say that I don’t backslide on occasion or that I’m some sort of expert in effective communication.  I’m not but am lucky to know someone that is.  His name is Michael Santarcangelo and if you live near enough to Fairfax, Virginia you have a treat in store for you.

In addition to being a lifelong security professional, Michael is a professional speaker (as in member of the National Speakers Association and not some guy who gets to speak in public occasionally like me).  That means that he has refined the ability to communicate effectively and quickly something that is very important in these days of bullet point meetings and decreased budgets. 

Michael has put together a program to teach others to effectively communicate the value of security and is just about ready to roll it out in an upcoming 15 city tour.  All he needs to do is give it a test run and that is where this amazing opportunity comes in. 

On Saturday July 25^th (This coming Saturday), Michael will be giving a preview of the Communicating the Value of Security Seminar at George Mason University in Fairfax, Virginia.  He has worked with GMU and their Cauldron project to deliver this seminar.  Better still since it is on a Saturday he is offering a pool party and BBQ for the attendees and their families (provided courtesy of Cauldron).  The price is $12.75 per person/family. 

That means that you can pay to attend the seminar and then have your family meet you for the pool party and BBQ for only $12.75.  Now where are you going to be able to feed your family for that price?  I use to live in the DC area and can tell you that you won’t fine anyplace around where you could feed a family of four for under $15.  Even if you consider yourself a master communicator, you can always pick up a tip or trick and at this price can you afford not to go?  The normal seminar will probably be quite a bit more expensive and probably won’t include BBQ and a pool party. 

Check out Michael’s site for a description of the seminar and a link on where you can register.  Please spread the word too.   It is always important to support those in our community that are working to make our jobs easier and Michael is definately one of those.

Tags: communication, corporate culture, Free BBQ, Michael Santarcangelo, perception, Prioritization, risk management, security awareness, Trust, value of security

Over the past week or so I’ve been following the pirate attacks on international shipping off the east coast of Africa.  As I was listening to the news coverage a few statistics were given.  While I couldn’t write them down immediately these were the notes that I took as soon as I could pull over and find a pen. 

Every year there are approximately 80 successful pirate attacks off the coast of Somalia.  (The number of unsuccessful attacks is higher) This may sound like a lot but when you compare that with the estimated 300,000 commercial vessels that pass through this section of ocean.  That amounts to 0.027% of the traffic.  It would take 3,000 successful attacks before you would reach 1% of the estimated commercial traffic in that region.  Now I’m not sure what the statistics are worldwide but my guess is that the ratio would be about the same. 

As I was listening to the coverage I began to think about the parallels with other kinds of risk management.  It sounds cold, especially considering all of the human interest pieces the media has been doing on Captain Richard Phillips and his crew but it is no different than decisions that business leader’s make daily on how their critical information is protected.

Situations like these tend to put risk-based decisions into perspective.  The decision makers at the A.P. Moller-Maersk Group now have a different perspective on the risk of piracy than they did two weeks ago.  Now I’m not deriding the decision makers at the A.P. Moller-Maersk Group.  Up until now I would bet that their decisions were based upon quantifiable numbers and in line with their industry’s best practices.  In other words they have taken a risk-based approach that has worked. 

Worked?!? – you say.  Yes it has worked.  By all accounts some crews have been trained in how to respond to pirate attacks and thus have been successful in avoiding or thwarting the occurrence of this risk up until now.  (Another good example of this is the evasion of another pirate attack conducted against another U.S. flagged ship within the past 24 hours)  It is a common fallacy that risk management is about the elimination of risk.  Risk management is not about the elimination of risk but rather its reduction to acceptable levels.  The risk still exists though be it in a reduced form. 

This then uncovers two important concepts:

·         Risk can never be totally eliminated – it can only be managed to acceptable levels; and

·         Perception is as large an influencer of decisions as statistics and other forms of measurement. 

In the coming weeks I’ll take some time to explore these two concepts in relation to information risk management. 

Tags: best practice, Capt Phillips, Captain Richard Phillips, commerce, Maersk, maritime, piracy, pirate, risk, risk management, Somalia

Okay so I spent the week in DC and attended the pilot presentation of the NIST’s Risk Management – An Organizational Perspective course and I thought that I’d share my thoughts on it with everyone. 

First off the course is intended to provide an overview of the methodology for managing organizational risk unsurprisingly called the Risk Management Framework (RMF) developed by NIST and aimed at Federal Agencies. 

When I accepted the invitation to go I really didn’t give it much thought and showed up expecting to sit through an overview class that would be presenting some new information.  When I got there I realized that what NIST wanted was feedback on the content and presentation.  Ever one to have an opinion, I was delighted to provide constructive feedback.

The course is based on their Special Publication 800-39 document: Managing Risk from Information Systems: An Organizational Perspective.  The primary audience is of course the federal government but it contains tried and true principles familiar to anyone who manages risk.  What is surprising is that after all these years many organizations focus on what I call “point solutions” and not on organizational risk.  I’ve seen this happen at federal agencies as well as private institutions in more than a few different industries.  So with this in mind it is important to keep repeating the obvious until people begin to take some notice – enter this course.

Apparently NIST is planning on developing both an executive overview of the document as well as a three to five day overview course for government people who will have “hands-on” responsibilities with regard to risk management in the federal government (but no actual experience) – two very different audiences.  The problem with the pilot course is that it tried to cover both audiences at the same time. 

Now I’m not knocking NIST here.  Course development is not as easy a task as it may seem.  There are many different types of learners as well as different levels of detail required depending upon the audience.  I’ve been developing and delivering similar training for over five years now so I know first hand how hard it can be.  When you sit down to prepare the material it can often become difficult to accurately judge the level of detail needed so my hat is off to NIST for opening themselves up to criticism.   

The level of expertise and experience of the people sitting in that room was daunting.  With over 10 years of experience I was probably one of the more junior people there.  Just about everyone else had just over 15 years and came from a variety of different backgrounds.  If you were looking for constructive criticism, I can’t think of a better group to get it from though. 

Now when you typically get that many smart, experienced people in the room there is always someone who wants to promote their own agenda – it didn’t happen this time though.  Everyone listened and gave very good advice and their considered opinions.  It was very collegic and team oriented.   I think that everyone felt that they were contributing to the greater good and was happy to be able to do so. 

We occasionally had a hard time not getting caught in the weeds.  When you’ve been doing this for a while you tend to know which minutiae are important and what isn’t.  The problem becomes squaring that with the level of detail required by the target audience.  NIST’s presentation had that same problem.  At times it was just right for an executive level of detail and at others it dove down into the weeds.  While everyone in the room followed along, I’m not so sure a new person would have.  The group’s comments reflected that opinion too. 

One new thing that I heard (and it’s possible that I haven’t been paying attention as I’ve been focusing on the private sector for a while) is that NIST plans to release what they call Quick Start guides.  These are intended to be the “Cliff Notes” for the special publications.  They showed us one as an example and I thought it was just the right level and length for an executive summary.  It was enough to give you a context and an idea of what you needed to know before you dove deeper into the content of the actual Special Publication. 

All in all it was a pretty good few days.  NIST has a very difficult job.  When most people sit down to develop standards and guidelines they have a specific audience in mind.  That audience tends to be somewhat specific – either a specific industry or a specific organization.  NIST’s audience must span the entire federal government with all the different organizational cultures from all the different agencies.  What they come up with must be applicable in all those different environments.  Give too much information and it isn’t applicable in some environments; give too little and it isn’t applicable in any environment. 

This course will probably go a long way towards rectifying some of the criticism thrown at NIST over the years.  This week was a great opportunity to talk with the authors of the document and learn what they went through in order to create the documents.  Many of the issues we brought up were debated by NIST when the documents were created and we were able to gain the insight of their intent.  I hope in turn NIST will incorporate these insights into their Risk Management course.  That will go a long way to reducing some of the confusion that is out there.  I have every expectation that it will. 

All in all I had a great couple of days.  I met some wonderful and knowledgeable new colleagues, renewed old friendships, and gained a little more insight into this topic that we call Risk Management.

Tags: management, NIST, organizational perspective, risk, risk management, SP 800-39

In response to a few inquiries that I’ve gotten I’ve decided to address the basics of how to integrate security into a system development lifecycle (SDLC).  This work was initially part of a paper that I wrote for my Masters program at Norwich University.  I’ve shared the paper with a few clients when the subject has come up and the feedback has been positive enough that I’ve decided to revamp it for posting here. 

 

The paper was written under the assumption that the reader would be unfamiliar with the technical aspects of information security (as is true of most management types – after all that is what they hired us for isn’t it).  My aim was to illustrate information security without being overly technical and thus risk losing my audience.  The paper was a bit too long to place in one post here so I’ve decided to break it up into a few installments.   So without further adieu – A Beginners Guide to Integrating Security into the SDLC. 

 

Introduction

 

The goals of any company are to deliver a quality product at the lowest reasonable cost and with the highest profit potential.  The emergence of the Internet over the last 30 to 40 years has caused a shift in the typical business model and drastically influenced the way that companies conduct business.   

 

Information Security is really a subset of business risk management, which has been around for centuries.  The protection of information itself has been traced as far back as the Renaissance and double entry bookkeeping as a tool for measuring and controlling corporate assets (1).  As the means of recording and maintaining information evolved over time, so did the methods of controlling information. 

 

Effective Information Security is security that is incorporated at the onset of a project.  If it is included as a requirement early in the system development and/or acquisition process, it typically results in less expensive and more cost effective security.  Waiting to integrate security until later in the process usually results in interoperability issues and increased cost. 

 

 

The purpose of information and information systems is to process, store, transmit, and receive information for individuals and people to use in some form.  In order for this information to be useful, it must be accessible by those individuals who need it, maintain its integrity, and be available when needed.  These objectives are classically referred to as the security triad: confidentiality, integrity, and availability. 

 

 

In order to achieve these objectives, some measure of quality control needs to be enacted to ensure the achievement of these objectives.  Because information systems involve the interaction of people with machines in order to access and interact with the actual information, information security involves human elements as well as technical elements. 

 

Dr. Joseph Juran, a pioneer in quality management, “is recognized as the person who added the human dimension to quality – broadening it from its statistical origins (2).”  Incorporating security as a requirement at the onset of a project is part of the quality control process and must address not only the technical controls employed within systems but also how humans will actually interact with the technology employed.

 

The following sections address the integration of information security concerns within the system development life cycle and how it reduces risks to a manageable level.  Following in the spirit of the Pareto Principle (see Footnote 1), recommendations focus on measures which are both cost effective and risk averse.

 

Footnote1: It was the Italian economist Vilfredo Pareto who, at the beginning of the 20^th Century, observed that 80% of the wealth in Italy was owned and/or controlled by 20% of the population.  While many others also observed similar phenomena, Dr. Joseph Juran, described what he termed as the “vital few and trivial many.”  Dr. Juran was able to identify that typically 20% of the defects cause 80% of the problems in a product.  “The 80/20 Rule” or Pareto’s Principle, as illustrated by Dr. Juran, can be applied during the SDLC to achieve the implementation of quality security controls as well as ensure cost effectiveness.

 

In Part Two we’ll address the Key Roles and Responsibilities within the SDLC, Security Properties, and the Phases of the SDLC. 

 

In Part Three we’ll look at each of the SDLC Phases and review the security considerations of each.

 

And in Part Four we’ll wrap it all up into a conclusion. 

 

I’d be interested in hearing any feedback you may have.  Translating security to management is always a moving target so the more viewpoints that can be incorporated into the approach the better. 

 

 

References:

National Institute of Standards and Technology, Special Publication 800-64 – Revision 1, Security Considerations in the Information System Development Life Cycle, June 2004

 

Sources Cited:

 

1 – Bosworth, Seymour. Jacobson, Robert V.  “Brief History and Mission of Information System Security.” Computer Security Handbook, Fourth Edition. Ed. Seymour Bosworth, M. E. Kabay.  New York: Wiley & Sons, 2002.  1-3.

2 – Our Founder: Juran Institute (http://www.juran.com/lower_2.cfm?article_id=21)

Tags: 80/20 Rule, Availability, Business Risk Management, Confidentiality, information security, Integrity, Joseph Juran, MSIA, Norwich University, Pareto Principle, quality control, quality management, risk management, SDLC, Security Objectives, System Development Life Cycle, Vilfredo Pareto