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

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

Business Week has published a pretty good article on the Lessons Learned from the Heartland Data Breach.  I think the title is a bit misleading though.  There aren’t really any lessons learned, at least as far as what we in the security industry would call lessons learned.  Now from a business point of view it does highlight the need to try and get out in front of a story.   

The original draft of this post had me summarizing the Business Week article with a bit of commentary here and there.  As I reread it I realized that I wasn’t really adding anything and what I really wanted to accomplish had very little to do with the timeline and a lot to do with disclosure.

All in all I can’t really fault Heartland on the public relations side of this security incident.  The only two items that don’t seem to jive for me is the claim that Robert Carr, the CEO at Heartland only found out about the breach at 10:30 PM the night of Monday January 12^th and the claim that they didn’t try to bury the disclosure in the middle of the media storm that was the Inauguration of President Obama. 

As the article pointed out, Heartland was informed by VISA in October 2008 that there appeared to be signs of a breach based upon card issuer’s reports.  Heartland took the information seriously enough to go out and hire two forensics companies to examine their systems.  Now I know that Heartland is a big company but when you add up the costs involved in having two different forensics companies come in for at least two months and couple that with the possible implications of a data breach of this magnitude I find it hard to believe that Robert Carr wasn’t at least aware of a critical potential problem before the phone call on January 12^th and if he truly wasn’t then he wasn’t doing his job. 

The second point is the accusation that Heartland tried to bury the story by making their public disclosure in the midst of the media storm surrounding the Inauguration.  Heartland claims that they couldn’t disclose the details until law enforcement were finished with their initial assessment and that they did so “as soon as was practicable.”  It is true that they couldn’t make any announcement in the midst of an investigation but don’t insult my intelligence by implying that the release date and time wasn’t by design. 

Now that I have that off of my chest let me move on.  It is easy to sit out here on the Net and snipe but let’s look at the situation objectively.  Heartland was compliant with industry standards and guidelines.  When they were notified of a possible breach they began an internal investigation.  This investigation most likely involved spending massive amounts of money in the retention of not one but two separate companies that specialize in digital forensics.  When they received official notification that a breach had occurred (Supposition would lead one to conclude that the final document was delivered and briefed to someone at Heartland most likely on January 12^th.) they informed the appropriate authorities.  After law enforcement concludes their initial assessment they make a public announcement and own up to the facts rather than trying to pass the blame on to anyone else.  They follow this up by personally contacting their customers, either in person or by phone.  Since then Carr has spearheaded an effort to encrypt card data at the point of collection as well as co-founding an organization to share security within the payments industry. 

I’m sorry but I can’t find anything to fault here and quite a bit to praise.  I predict that in the years to come the Heartland Incident will become a case study in how to respond to a security incident.  All too often companies try to play the blame game and dance around on the issues.  I think that had Heartland done this they would have taken a bigger hit and garnered a lot more media attention than they already have. 

Not that this has been painless for Heartland says that they lost a few hundred customers; their stock price lost 78% of its value and is currently trading at about 50% of what it was worth prior to the announcement.  They have spent something on the order of $12 million dollars in remediation and mitigation activity thus far.  Expect that number to go up.  TJX is reported to have spent $171 million.

Was Heartland negligent in some way?  Well that has yet to be seen but based upon the information we have thus far I’d venture to say that they weren’t.  Negligence is the failure to exercise the care toward others which a reasonable or prudent person would do in the circumstances, or taking action a reasonable person would not. If they were compliant with industry standards and guidelines coupled with responding appropriately when notified of a problem then I would say that would constitute exercising due care commensurate with a reasonable or prudent person’s actions. 

Now if Heartland isn’t to blame, who is?  There is the assertion that PCI is to blame.  Personally I’m not a fan of competing standards.  I just don’t see why we need so many different standards when we obviously are just repeating ourselves in varying levels of detail.  All that said I’m not so sure it is the fault of PCI or any other standard that Heartland could have applied.  What I believe the issue to be is in the application and measurement of standards and guidelines.  All too often we take an audit mentality when we talk about complying with standards and guidelines.  When we do this we distill everything down into some sort of checklist and then equate this with being secure.  You pass the audit you are secure; you fail the audit you are not secure.  The Heartland Incident is just another example of this being a false premise.

Now I don’t want to appear to be advocating the proverbial throwing the baby out with the bath water.  What we need to do is find some way to encourage and support companies to make informed risk based decisions about security.  We can utilize standards and guidelines as frameworks upon which to build sound security practices but we also need to find a way to support companies to make security decisions based upon acceptable risk and not compliance. 

But do you want to know what the kicker is to all of this?  It is that if we do this then we will eventually come across a company that does all the right things and still has a security breach.  That will be the moment of truth.  How do we react?  Do we support the company for doing the right things and making sound risk based decisions or do we slam them for non-compliance with an arbitrary set of standards and guidelines? 

If we slam them then we are right back to where we are now. Stuck in the quagmire of checklist/compliance driven security which we know doesn’t work.  If we support them and use the security breach as an opportunity to learn from the mistake in order to improve then we’ve turned the corner. 

I’m not saying that I have all the answers either.  There has to be some measure of incentivizing companies to incorporate security into their processes other than forcing compliance with a law or regulation.  I’m just not quite sure what that is.  I do know that what we are doing now isn’t working.

Tags: Compliance, Heartland, Heartland Payment Systems, PCI, Robert Carr

Introduction

This is the second in a two part guest post by Ian Charters, an expert in digital forensics.  As a result of reading Evan Shuman’s blog post: Heartland Sniffer hid in Unallocated Portion of Disk, I asked Ian if he would be willing to write a guest post on the topics that Mr. Shuman detailed in his post.  My thought was to reframe, in layman’s terms, what happened so that managers and executives would have a better understanding what happened without getting tied up in technical terms.   What I received were two submissions that gave a bit of background on unallocated disk space and then looked at what is reported to have happened in the Heartland Incident. 

Many thanks to Ian for sharing his time and knowledge with us.  Ladies and Gentlemen: Is there a Ghost in the Machine:

Is there a Ghost in the Machine?

It just seems that in the world of computer security and digital forensics, the more things change, the more they stay the same.  In this case, I’m referring to a recent security incident reported by Evan Schuman in his wonderful blog, entitled Heartland Sniffer hid in Unallocated Portion of Disk.

The incident that Mr. Shuman describes is typical of today’s credit card information theft.  It appears that organized criminals in Easter Europe targeted a credit card payment processing firm.  They implanted a software sniffer on the firm’s servers (a sniffer is a software package that examines and records data moving across the network that it is attached to).  The sniffer apparently collected significant amounts of unencrypted credit card data.  From a technical point of view, what makes the incident interesting if that it appears that the sniffer was installed in unallocated disk space on Heartland’s servers.  (For those who might need to brush-up on what unallocated disk space is see, “A short primer on empty disk space”.)

What was not reported was how the collected data was stored (presumably also in unallocated disk space), and how the collected data was moved off the network.  If the storage and transfer of the stolen data was handled in as sophisticated a manner as the implanting of the sniffer, this was an attack of some significance.  

Getting back to the initial issue of the use of unallocated disk space to hide files and executables is not a new technique.   It does require significant level of sophistication for both the programmer involved and for those operating the scheme over all.  One of the first times I saw the technique used was around 1990. At the time MP3s were fairly new but immensely popular with young computer professionals of all stripes. Young programmers in particular wanted to listen to music at work.  However, folks running the networks didn’t want them to use the network’s resources to listen to (and perhaps unfairly presumed sharing) music.  So, the cat and mouse game of hide and seek began.   When the “mouse’s” started hiding their file shares in plain sight using unallocated disk space they pretty much had the upper hand for a while.

The problem with this is that eventually this same technology started being used for darker purposes. Folks involved in the illegal or unlicensed sale of software want to have their software securely stored but they also didn’t want the software associated with or indeed located anywhere physically connected to them for fear of arrest.  In the early 1990’s, Federal law enforcement started treating the trade in illegal or unlicensed software seriously.  This resulted in several spectacular arrests. So, the folks selling unlicensed software started hacking corporate servers in order to hide their unlicensed software in the unallocated disk space found on their servers. 

Even before the peddlers of unlicensed software started using this approach, hackers had been storing and hiding their hacking tools on corporate servers.  This led to an interesting underworld market in hacked servers in which hackers would take over corporate or even government servers and “sell” control of the servers within the underworld to the highest bidder.  Unfortunately this trade goes on even today. 

Because I was aware of all of the silly games of file hide and seek going on, I got into the habit of regularly overwriting the slack space, unused space and unallocated space on my computers. I even did this on my home computers at the time.  However, with time the popularity of this approach to hiding data declined in favor of other techniques. As a result I also stopped this preventative practice.  I guess Evan’s article reminds me that there are several old security techniques that I have discontinued that I should reconsider. If you have similar concerns, please contact an digital forensics professional.  After all, I see a lot a “solutions” offered on the internet.  In many cases, if you aren’t careful, the cure is worse than the original symptom. 

Thanks Evan, for the great article and the nudge to never forget the past. 

About the Author

With over 20 years of experience in the field of digital forensics, Ian Charters has a unique perspective on the evolution of digital forensics.  His career has taken him from the private sector into government service and back to the private sector. 

After successfully starting and running his own networking, software development and systems integration firm, Ian was recruited into the nation’s Intelligence Community, including service in both the Defense Intelligence Agency and the Central Intelligence Agency where he proudly served his country for over 20 years. 

Upon retiring from Federal service, Ian served as the Security Practice Leader with the Unisys Federal Group based in Reston, Virginia.  While being responsible for leading the practices efforts in the development, sales, and delivery of a full range of IT security solutions, he was responsible for the development and introduction of a code application assurance into the Federal market. 

Ian is currently a Senior Manager in a Big 4 Accounting firm’s information security and risk management practice.  His responsibilities include leading engagements to provide security services to both commercial enterprises and government agencies.

Ian holds a Bachelor of Arts in Political Science from Washington State University and a Masters of Arts in Security Policy Studies from George Washington University in addition to completing extensive post-graduate and commercial coursework in Computer Security, Architectures, Networking, Programming, Telecommunications, Computer Simulation and Simulation Theory.  He is a frequent seminar speaker with the Potomac Forum Ltd, a non-profit educational foundation (www.potomacforum.org) and serves on the Board of Advisors for Ascension Risk Management LLC (www.ascensionriskmanagement.com).

Tags: Data Breach, Digital Forensics, Heartland Payment Systems, Ian Charters

Introduction

Two weeks ago three people were arrested for using credit card numbers stolen from Heartland Payment Systems in what many are calling the largest data breach in history.  At this time it is unknown what role these individuals played in the actual breach as the investigation is still open.   What we do know is that the breach occurred due to the presence of malicious software (malware) planted on Heartland’s payment processing network.  Apparently this software hid in the unallocated portion of the server’s disk (See Evan Shuman’s Blog Post Heartland Sniffer Hid in Unallocated Portion of Disk). 

When I read this I decided to reach out to a friend who also happens to be an expert in digital forensics.  I asked him if he would be willing to write a guest post for the blog that attempts to explain what happened in layman’s terms.  In response to my request Ian has provided two great guest posts on the topic.  The first, presented here, gives the reader a short primer on empty disk space.  As I read the two posts that he sent me I felt that it was important to put this post first as it forms the basis for his explanation of the technique used in the Heartland Incident.  (Look for that post on Thursday).

So without further adu, here is Ian Charters with his Short Primer on Empty Disk Space:

 

A Short Primer on Empty Disk Space

As unfortunate as it may be sometimes even simple discussions of computer technology force you to get involved in some pretty complicated technical details. This is certainly the case when discussing “empty” disk space.  And the whole point of this short blog is to provide the background needed to understand the topic without getting hopelessly mired in bits and bytes.

Let’s start with at the top.  There are three basic types of empty or unused disk space. They are:

• Slack space
• Unused disk space
• Unallocated disk space

 

In order to understand what slack space is it is important to have some basic understanding of how computers use or assign storage space on a hard disk drive.  When you tell the system to save a file the operating system goes through a rather complex series of tasks.  However, for our purposes it:

1.       Determines how large the file to be saved is;

2.       Allocates an appropriate amount of space on the hard drive;

3.       Makes a reference to the file; and then

4.       Saves the file.

In order to illustrate this concept, let us use the analogy of a book.  Using the book analogy, the same steps could be described in this way:

1.       Determine how long the chapter you are printing is;

2.       Determine the number of pages required;

3.       Note the chapter in the table of context; and

4.       Print the chapter.

 

Now let’s put these two together. 

Slack Space

To put it simply, slack space is the difference between the length of your chapter and the number of pages you have printed.  What does that mean?  Well, when you print a document you never really think about it but there is almost always space at the end of the last page that isn’t used or is left blank.  That is the equivalent to slack space on a hard disk. 

Unused disk space

You would think that the concept of unused disk space would be simple and straight forward and in some ways it is but there are a couple of twists to the concept.    It is very important to keep in mind that computers don’t know anything if you don’t it to them.  So, the way computers use hard disk space is that they don’t “know” about any files or data that isn’t recorded in the table of context.  If you have a 1000 page book (hard disk) and you have only written a few, say 4 chapters in it and those chapters total say 43 pages, you have 957 pages of empty pages (unused hard disk space) right?

Well that is right as far as it goes.  What makes the concept of unused disk space a little more complicated is the way computers handle files (book chapters) when they delete them.  In order to understand this it is important to know a little bit about how hard disks are made.  They usually consist of a bunch of controlling electronics, several data disks, and what are called “read” and “write” heads.  There “heads” are really just thin probes that well, er, read and write to the data disks.  Note that I said nothing about erasing.  So, if you think of a hard disk as a book, you might think of there “heads” as very fast readers and writers that well, read from and write to the disk. Remember, these head have no erasers.

Say you have been using your computer for a while.  You have created and deleted many files.  When a file is deleted all the computer does is takes the reference to that file (chapter) out of its index of files (table of contents).  What amazes may people is that after a file is deleted all of the data is left behind on the disk.  It is not erased.  The computer simply considers that spaced unused and there available for reuse.  So, chances are at some point the space will be reused and original data will be overwritten. Until that happens, the data is still there.  It could be overwritten in an hour, or a day, or a week, or even a year from now.  It all really depends on when the computer needs the space that the old file was taking up. 

Keep this in mind the next time you chuck out an old computer.  You feel safe because you have deleted all of the sensitive files and they threw the whole thing out.  Well what you just did was delete all of the references to your sensitive files, but left all the data on the disk, and then gave the whole thing to someone you don’t know. Oh my!  Now you see why I warned that this seemingly simple topic can get complicated.

This is not the place to spend a lot of time on the topic.  But, if you are concerned about deleting sensitive data from a computer, talk to a computer security professional about your options.  The same applies to throwing out old computers.  There are simple, cheap and effective solutions to this problem.  But, there is also a lot of snake oil being peddled out there that simple web search will reveal as downloadable for only $39.95! Buyer beware.

Unallocated Disk Space

This last category of empty disk space is really of concern mostly for computer professionals.  Fortunately for us it is also a fairly simple topic.  You may or may not be aware but you can segment your hard disk into different sections called partitions.  The computer treats these partitions as separate smaller disks even though they are physically one hard drive.  This is much like defining your hard disk as containing several different books, each dedicated to a specific subject.  In terms of giving you flexibility to organize your data this can be a god-send.

Well, in the process of defining these books you may have a reason to define some books now and want to define some new ones at some time in the future.  Say for example you might want to keep all of your financial and tax records in a separate partitions or books.  What you would do in that case is leave a portion of the hard disk unallocated.

The ability to leave some disk space unallocated can also be a great use to a computer professional.  For example, let us say that a small company decided to deploy a server to serve as a repository for their client work.  They build the server and begin using it.  Sometime later they determine that it would be a wise move to back up this information onto a backup server (in case something happens to the first one).  By the time they decide this they are unable to purchase an exact copy of the first server.  Often as the price of larger hard drives comes down, they are placed into the same make and model server by the hardware providers.  The server itself stays at the same price point however it now has larger hard drives than its predecessor that may only be a few months (or even weeks) old.  This makes things a little harder.  Well, one thing that can be done is to size the disk partitions in the backup server so that they match the disk sizes from the original server.   This is a pretty common and accepted practice.  It also leaves the possibility that the remaining disk space on the larger drive be left unallocated. 

Building off of this we will move on to examine what may have happened in the Heartland breach and how it really isn’t anything new.  Stay tuned for “The Ghost in the Machine”

About the Author

With over 20 years of experience in the field of digital forensics, Ian Charters has a unique perspective on the evolution of digital forensics.  His career has taken him from the private sector into government service and back to the private sector. 

After successfully starting and running his own networking, software development and systems integration firm, Ian was recruited into the nation’s Intelligence Community, including service in both the Defense Intelligence Agency and the Central Intelligence Agency where he proudly served his country for over 20 years. 

Upon retiring from Federal service, Ian served as the Security Practice Leader with the Unisys Federal Group based in Reston, Virginia.  While being responsible for leading the practices efforts in the development, sales, and delivery of a full range of IT security solutions, he was responsible for the development and introduction of a code application assurance into the Federal market. 

Ian is currently a Senior Manager in a Big 4 Accounting firm’s information security and risk management practice.  His responsibilities include leading engagements to provide security services to both commercial enterprises and government agencies.

Ian holds a Bachelor of Arts in Political Science from Washington State University and a Masters of Arts in Security Policy Studies from George Washington University in addition to completing extensive post-graduate and commercial coursework in Computer Security, Architectures, Networking, Programming, Telecommunications, Computer Simulation and Simulation Theory.  He is a frequent seminar speaker with the Potomac Forum Ltd, a non-profit educational foundation (www.potomacforum.org) and serves on the Board of Advisors for Ascension Risk Management LLC (www.ascensionriskmanagement.com).

 

 

 

 

Tags: Data Breach, Digital Forensics, Heartland Payment Systems, malicious software, malware, slack space, unallocated disk space, unused disk space