If you are a subscriber to the Cutter IT Journal you can check out my article in the August 2009 issue.  If not you can find out more information at the following link:

http://www.cutter.com/content/itjournal/fulltext/2009/08/itj0908a.html

 

I’m also trying to get a link to a PDF version of the article and will post it here as soon as I do.

 

Just an FYI – I don’t earn any income from the Cutter IT Journal so if you do decide to purchase a subscription I won’t benefit in any way from it.  Basically I get a free subscription by having my article accepted for publication that is about it.  That said I’ve enjoyed this issue so far (aside from my article of course) so if you do decide on purchasing a subscription you will probably enjoy it.

Tags: Compliance, Cutter IT Journal, information security, Privacy

In the first part of this series, I began by explaining that the topic came from a reaction I had to a quote from Robert Carr the CEO of Heartland.  The underlying premise of the quote was built on the assumption that Heartland was PCI DSS compliant therefore they should have been secure.  Anyone who has read this blog won’t be surprised to hear that I don’t agree that compliance can be equated to in any way to how secure a network or system is or isn’t. 

As I milled this over an analogy came to mind.  It was that Information Security is a lot like professional cooking.  Part One basically set things up and this part (Part Two) will begin the analogy by showing how standards are a lot like professional recipes.  In Part Three I will broaden the image by relating what we do to working in a professional kitchen.

As some of you know when I first graduated from college I went to culinary school.  The school I went to focused on technique and we spent every day in the kitchen learning and refining what we have learned.  I went on to work in some fine dining restaurants and while I later came to the realization that life in a professional kitchen wasn’t for me, I learned quite a few life lessons during that experience. 

Getting back to the that standards are much like recipes, let me share with you one of the base recipes from my time in culinary school:

Mediterranean Fish Soup

(Serve with rouille on croutons)

Olive Oil

Scallions – FC

Onion – C

Garlic – FC

Tomato – C

White Wine

Fish Stock

Season

Saffron

Thyme

Fish in 1” pieces

(Salmon, Red Snapper, Scallops, Clams/Mussels, etc)

 

That’s it.  Most professional recipes are like this one.  Some even have less detail.  Now if you know what you are doing then this is really all you need. 

The Chef who taught me to cook was from France and he taught us as he was taught.  No recipes – just technique.  We didn’t have recipes, cook times, or for the most part cook temperatures (Pastry and baking is a whole different world.  In order to do pastry and baking you need all of those things.  I’m talking savories not pastry and baking.)  When asked how long to cook something Chef’s response was: “Until it’s done.”  When we pushed him further he told us to start cooking and we would see. 

What he didn’t want us doing was blindly following a recipe.  He wanted us to think about the food; how it was cooking; what was happening in the pan; how this flavor blended with that one; how they blend differently depending on the cooking technique being used, etc

By teaching us the technique he was developing in us the skill to understand how different ingredients interact to create a dish.  We could then experiment to create our own dishes and creations (later outside of class of course). 

Now standards (such as PCI, HIPAA, GLBA, FISMA, DIACAP, etc) are very much like professional recipes.  Some have more detail than others but they are a basic set of instructions and all imply a certain baseline of knowledge to make heads or tails of them. They take someone with skill to apply them if they are going to result in something.  And by something I mean a soup that is so memorable that it brings you back to the restaurant time after time. 

Take the above recipe.  If you throw everything that I listed in a pot and cook it you’ll end up with garbage (much like blanket applying a standard or baseline set of controls).  The vegetables will take longer to cook than the fish.  Some fish will take longer to cook than other fish.  So you could end up with a soup with overcooked mushy vegetables and fish that will range from being overcooked to raw. 

Here’s the thing: you followed or rather were “compliant” with the recipe but you still ended up with garbage (or at least not something worthy of a fine dining restaurant).  Sound familiar?

Put this recipe in the hands of a trained/experienced cook however and you will have something. (WARNING – minor digression here.  We throw around the term “Chef” too loosely in this country.  There is really only one Chef in a kitchen – everyone else is a cook.  IMHO, you must earn the title “Chef” and shouldn’t get it just because you put on a white jacket and stand next to a stove.) A trained/experienced cook will take the finely chopped scallions and onion and sweat them down in a little olive oil. Just as they are tender and translucent the garlic will be added for a minute or two – that way it doesn’t burn.  Next in will be some chopped and seeded tomato.  This will be cooked down until the pan is somewhat dry but the tomatoes are moist.  At this stage you’ll need to keep your eye on the bottom of the pan.  You are looking for a little caramelization of the sugars from the scallions, onion, garlic and tomato to occur.  Don’t burn it though.  As the caramelization occurs, add in some white wine to deglaze the pan.  When that cooks down to the point that it is gone, add the saffron followed by the fish stock and some fresh thyme. 

Now you have your fish soup base.  To this you will be adding several types of fish/shell fish.  The problem is that even though you will cut them all to the same size, they won’t all cook the same.  Some will take longer than others.  Here is where experience comes in again.  What some people do is that once they have a huge pot of the base, they take a cup or two of it and put it in a smaller pot or pots.  They use these pots to cook the fish to order and return the cooking liquid back to the soup base after each go.  That means that the base will pick up the flavors and oils from the fish and actually get better throughout the night.  The base is kept at a simmer all night too so you can quickly cool it down and refrigerate it for use the next day too.  

Now in this analogy the cook was able to use the elements of the recipe to create a pretty good basic fish soup.  Can you alter the ingredients to create something else – of course you can.  You can substitute shallots for the onions and some of the garlic.  You can add in Leeks or other vegetables too and you would treat them slightly different depending upon how the soup was going to be served.  I won’t go into all that here as I’ll get too far away from the analogy but once the basic technique is learned a lot can be done from that basic starting point.

That is what standards are – basic starting points.  In the hands of a skilled professional they can take us a long way towards securing our networks but they are by no means an end unto themselves. 

Now that I’ve run a bit long on that I’ll wrap this up by saying that now that we have an idea how standards fit into professional cooking we can move on to how managing security in a network is akin to professional cooking.  That will be next time of course.

Tags: culinary school, Heartland Payment Systems, information security, L'Academie de Cuisine, Mediterranean Fish Soup, PCI DSS, professional cooking, professional kitchen, recipe, Robert Carr, standard

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

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