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

On the evening of April 27 2009 Abdirahman Ismail Abdi entered the facilities of the California Water Services Company (Cal Water).  After presumably parking his car in the employee car park, he entered one building with his electronic key card and proceeded to the office of a senior executive.  Sitting down at the executive’s computer he initiated three separate transfers totaling $9 Million USD from the accounts of Cal Water to an account in Qatar.  Having completed this transaction he exited the office and building and proceeded to another secure building on the Cal Water campus.  Again he used his electronic key card to access the building.  Proceeding to the office of yet another senior executive, he again used that executive’s computer to access the Cal Water’s financial systems and approved the transfer requests he initiated just a few minutes before in the other building.  His work completed he most likely walked out to his car and drove away. 

 

What we don’t know yet is how he accessed the financial systems: did he use his own credentials or did he use the credentials of the senior executives whose computers he accessed?  To me it sounds like he somehow compromised the accounts of the two executives but this is just conjecture on my part.  The next question raised is why he would need two separate computers.  If he had the user account information then couldn’t he just access the financial system from the same machine logging in once to initiate the transfer before exiting and logging in again to approve it? A number of reasons come to mind:

 

·         Perhaps he was trying to frame these two executives;

·         Perhaps the software used to access the financial system required different client modules thus the need for two separate computers;

·         Perhaps the financial system required an electronic certificate from these users that was only stored on their own computers. 

 

I’m sure other reasons come to mind but let’s go with these.  Moving on, how do we know that Abdi is the perpetrator?  Having just broken down how the financial account was accessed I would venture to guess that he did not use his own login credentials.  Cal Water is the largest investor-owned American water company west of the Mississippi River and the third largest in the company.  I think that it is safe to assume that they had some sort of separation of duties controls in place hence the need for two computers in two different buildings.  Again this is conjecture on my part but it does make sense. 

 

But if he used the accounts of those senior executives then how do we know it was him? We believe it to be Abdi because he was observed by janitor in the buildings on the night of the crime and he also allegedly attempted to deposit a check for more than $25,000 USD made out to Cal Water in his own bank account.  Add to this the fact that (1) Abdi put his wife and children on a plane to Germany on April 28^th the morning after the crime and (2) Abdi resigned his position as an auditor for Cal Water just hours before he allegedly committed this crime and things don’t look so good for him right now. (Abdi is currently on the run and is believed to have fled the United States through Canada as of this writing.) 

 

Now this is a good story worthy of a “movie of the week” (or perhaps an afterschool special for young security professionals still in school).  It goes to show that the human element is both our greatest weakness as well as our greatest strength.  Let me explain that. 

 

Going back over the story a few things stand out to me.  The first is that Abdi needed to access Cal Water facilities with his electronic key card.  The second is that he needed to use two separate computers presumably with two separate accounts in order to complete the crime. 

 

Now I have no inside knowledge of the Cal Water environment or systems but it makes sense that if Abdi could have accessed the facilities without his key card he probably would have so they are most likely adequate to protect against unauthorized access by an external threat source.

 

Next he used two separate computers assigned to individuals who most likely had the authority to initiate and approve fund transfers.  Not only did he need their computers but he probably needed and used their login credentials.  How he gained their login credentials is unclear.  Were they written down somewhere; did he eavesdrop them sometime in the past; did he install some sort of key logger software when he was acting in his capacity as an auditor? (The last is a scenario that I made up because it seemed plausible – there is absolutely no indication that this actually happened or is alleged to have happened.) Right now we just don’t know but it makes sense to me that he had to have needed two separate computers and two separate sets of login credentials with the right level of access to the financial systems.  As an auditor it is likely that Abdi was privy to vulnerability information concerning the financial system therefore he probably chose the easiest way to exploit the system.  That tells me that it is very likely that the technical controls on the Cal Water financial system were operating as intended or were at least sufficient otherwise why would he to go the trouble and risk of compromising two buildings, two offices, and two accounts.  (Again, I have no inside knowledge of Cal Water.)

 

So if the physical access controls were working as intended and the technical financial controls were working as intended then the only thing we have left is a failure of the human control – namely the disgruntled insider, that lead to this breach.  It was also the human control that identified the perpetrator.  Remember that a janitor has identified seeing Abdi in the building on the night of the crime after he quit.  Remember also that Abdi tried to deposit a check made out to Cal Water in his own account – not a very smart thing to do. 

 

People will argue that there was also a failure of the termination process and that Cal Water should have disabled his access (physical as well as technical) when he resigned.  What we don’t know is if his resignation was effective immediately or if he gave two weeks.  In many companies it is normal operating procedure to have an employee departing on favorable terms to wrap things up and transfer their work to another person in their final days in a position.  We have no indication at this time that Abdi was a problem employee or that he would have given any indication that he posed a threat.  Remember from what we know he resigned; he wasn’t fired.  There is also every indication that he probably didn’t even use his on login credentials once inside the facility so even if his technical access had been minimized it most likely couldn’t have prevented his use of another’s credentials.   

 

The bottom line is that it appears as if the physical and technical controls were working and operating effectively therefore the solution probably isn’t a technical one.  The human control is what failed.  Yes you could go through and upgrade the physical and technical controls to require multi-factor authentication both for entry into the facility as well as for identification within the network but is that really feasible in a majority of companies?  The need for security must always be balanced with the needs of the business.  Had Abdi actually been able to walk off with $9M then perhaps you could justify that sort of expenditure but in truth he didn’t.  (The account in Qatar was frozen and the funds transferred back to Cal Water.)

 

The insider threat is real and in an economy like this is growing.  Studies such as the 2009 Data Breach Investigations Report notwithstanding, the impact of an insider breach if often greater than that of an external breach.  In this case it was a transfer of money but what if it had been a customer list or proprietary data concerning a major company project.  (We’re speaking in general here not about Cal Water specifically.)  Touting the number of scans detected or intrusions blocked at the firewall don’t mean anything when Joe the employee who has just been laid off walks out with your customer list or the details of your proprietary processes on a flash drive.  Your competition could then undercut your prices or catch up on year’s worth of development in the space of a day. How much is that worth to your company?

 

As much as I don’t like the fact that some studies and reports have tried to downplay the risk posed by outsiders, I don’t want to overplay their importance either.  They are a threat just like other threats and they need to be addressed just like everything else.  What this story shows us is that your security controls need to go beyond the physical and technical realm.  Your staff and management needs to be trained to identify the potential for employees to become disgruntled insiders and take steps to address the issue before it becomes one.  I talked about this a lot in my three part series on Insiders (Part One, Part Two, Part Three). 

 

You also need to recognize that there is no way to completely guard against the insider threat so you need to have a plan on how to deal with it when it does eventually happen.  This takes a coordinated effort across the organization and since it may involve the seizure of evidence by local or federal authorities (should they become involved) you’ll need to account for that.  How should you deal with the media, stockholders, and the public?  What you say in the early days when you aren’t sure exactly what has happened is just as important as what will eventually be said in hindsight. (See my post on Public Relations and Security.)

 

This post has given me the idea that it might be useful to do something on the order of a breach analysis in order to bring up issues that need to be addressed well before an incident happens.  Perhaps I’ll do something like that in future posts. 

Tags: Abdi, Abdirahman Ismail Abdi, Cal Water, California Water Services Company, Data Breach, financial control, financial system, human factor, human factors, seperation of duties

This week saw the release of the 2009 Data Breach Investigations Report put out by Verizon.   This one is different from last year’s report in that it only deals with 2008 as opposed to a three year period (2004-2007) like the last one.  It is also based upon firsthand evidence collected by Verizon’s investigative response teams.  This is good and it is bad.  It is good in the fact that their analysis of root causes is probably very accurate (as opposed to relying on someone else’s experiences).  On the other hand it is bad in that their analysis of industry and organization size to data breach is heavily influenced by their customer base.  As a result I am intentionally not going to pay any attention to these results/correlations. 

It is also important to recognize that all such studies are biased in some way.  It is very hard to conduct any study like this and not introduce some sort of bias be it through the wording of questions to the selection of the data set analyzed.  Rather than throw out all studies, it is important to put their findings within the proper context before applying the findings to your own decision-making process.  What follows is my attempt to do that. 

Findings of note:

·         A vast majority of data breaches come from outside the organization (43%) or from multiple sources (39%).  Multiple sources appears to be defined as a combination of external, internal, and/or partner sources. 

·         The source of external attacks comes primarily from Eastern Europe, East Asia, and North America.  During the period between 2004 and 2007, these regions accounted for 59% of the attacks; In 2008 they accounted for 82%.   Beyond the region, nearly two-thirds of the attacks could not be traced to any specific entity other than IP.  Of the one’s that were traced most were connected with some sort of organized crime.  In fact Verizon points out an amazing statistic: 91% of all compromised records in 2008 were attributed to organized crime activity. 

·         A majority of the breaches involving business partners involved the lax security practices of the partner who was administering client-side systems. 

·         Error is a significant contributing factor in nearly all data breaches.  This one is very interesting to me because if the study is accurate in this regard it means that most organizations already have the tools they need.  In other words you don’t really need that new shiny box with the binky lights on the outside to protect your network.  The error comes from misconfigurations, omissions, programming errors, process breakdowns and poor decisions.  Verizon took the time to clarify their use of the term omission.  An omission could be defined as the failure to follow through on enacted policies and/or procedures and is distinctly different from misconfigurations and programming errors.  A common problem with compliance focused security programs (my own assessment, not Verizon’s). 

·         A vast majority of organizations were either fully targeted (28%) or opportunistically targeted (44%) (Combined 72%)  A fully targeted attack is where the victim was chosen before the means to exploit them was discovered.  Opportunistic targeting involves the victim being targeted because of a known weakness or vulnerability such as running a version of software with known exploitable vulnerabilities.  Verizon provides a suggestion with which I fully concur – organizations need to determine if they will be identified as a target of choice or a target of opportunity.  If a target of choice then they need to be prepared to fend off determined and sophisticated attacks, if a target of opportunity then minimize the opportunities for exploitation. 

·         Online Data is the most frequently compromised asset by far (94% compared to End user systems 17%).  This is important from the prioritization sense.  While it is fashionable to institute elaborate means to protect offline data, mobile devices, and end-user systems the money would be better spend on securing application servers and databases first.  (Incidentally this is the only instance in Verizon’s analysis where I felt that the comparison between the percentage of breaches and the percentage of records compromised had relevance.)   

·         87% of breaches could have been avoided had the organization implemented simple (53%) or intermediate (34%) level controls.  This falls in line with the Pareto Principle (aka the Principle of Least Effort) as it applies to protecting information where in 80% of the issues can be resolved with only 20% of the effort (time and money). 

 

Now my interpretation of Verizon’s findings underscores my belief that most of what is needed to protect an organization’s information assets already exists within the organization.  The findings speak to improving change and configuration management programs along with a more complete integration of security into an organizations system development life cycle (SDLC).  It also speaks to ensuring that business partners with whom you share critical data (be it transferring it to their systems or granting them access to yours) be required to comply with the same level of security that you employ within your own environment. 

The bottom line is that these improvements do not need to cost a lot of money.  Most of them come from focusing on the basics and doing them well – over and over again. 

Tags: 2009 Data Breach Investigations Report, Data Breach, external threat, insider threat, internal threat, misconfiguration, omission, Online Data, opportunistic targeting, Pareto Principle, partner threat, poor decisions, Principle of Least Effort, Prioritization, process breakdowns, programming errors, target of choice, target of opportunity, targeted attack, third-party threat, threat source, Verizon, vulnerability, weakness

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