The following is a very interesting white paper on the Evolution of Digital Forensics by Ian Charters.  Ian is a very good friend of mine and a member of the Board of Advisors for my company Ascension Risk Management.  The paper is aimed at the laymen and explores how digital forensics has evolved over the years. 

Ian’s background has covered a wide range of environments.  He began his career as an independent business man with his own networking and software development firm before he was recruited into the nation’s Intelligence community.  His tenure there spanned over 20 years and included service in both the Defense Intelligence Agency (DIA) and the Central Intelligence Agency (CIA).  It is from this time period from which Ian’s experience with digital forensics springs. 

If you have ever been interested in Digital Forensics then this paper is a great introduction into the field.  It is a quick, non-technical overview of the subject and aimed at the general reader.  Further papers may explore some of the more technical aspects of digital forensics and how they can be used in the corporate environment. 

This white paper was originally posted on The Guerilla CISO, a blog run by another friend of mine.  It is cross-posted here with permission by both The Guerilla CISO and the author. 

 

Click here to download the white paper in PDF format:

The Evolution of Digital Forensics by Ian Charters

Tags: Digital Forensics, Guerilla CISO, Ian Charters

I have been giving the idea of metrics considerable thought lately.  I’ve had a few people tell me that they have been asked to “justify what they do” by their management.  In a way that is understandable.  In tough economic times a business should examine everything they do and determine what the value added tasks are and what they aren’t.  As long as this is a question being asked of every department then we shouldn’t be surprised.  Unfortunately it seems that those involved in information risk management get asked this question way too often. 

It is very hard to quantify information risk management it is important to find some way to determine if you are getting ahead or if you are falling behind.  So rather than give the classic “it depends” response I will instead offer some considerations that you should take when considering the appropriate metrics to generate and report. 

Metrics are a means to measure the performance of a particular area.  They are intended to provide the feedback necessary to support continuous improvement.  Information Security suffers from the fact that metric development can often neglect the larger picture therefore lessening their ability to influence key decision makers within the organization outside of the technical environment. 

 This issue stems from the ability to measure so many different aspects of our environments.  While this ability is beneficial, it can also be a liability if the information generated cannot be translated beyond the information technology department.  Hopefully this post will help with addressing these concerns and provide issues to consider when information security professionals develop metrics for senior management.  

Answer the “Why” before the “What” and “How”

Information Security (Infosec) metrics must be based not only on the goals and objectives of the Infosec department but must also be directly tied to an organizations overall goals and objectives.  The purpose of Infosec is to support and facilitate business through the control of information.  This supporting role requires that all Infosec initiatives relate to the overall mission of the organization. 

The business case for all initiatives must directly relate to and support the overall mission of a company.  This linkage should also form the basis of all metrics developed within an organization.  These linkages dictate the desired result and identify critical areas to measure.  This measurement must yield quantifiable information that can be used to compare current performance with past performance for analysis.  This information must also be easily obtainable as the burden of collecting the information should not exceed the benefit gained from its collection. 

The first question that must be asked is “Why do we need to develop a metric?”  Metrics must serve a purpose beyond themselves and be relevant to their environment.  Metrics can assist decision makes with the isolation of problems, the generation of data to justify investments requests and the need to ensure that funded investments are returning value from the resources committed.  Metrics can assist companies in their ability to demonstrate compliance with the applicable laws, rules, and regulations of a particular industry.  Care must be taken though to keep the number of metrics manageable as too many metrics can lead to the dilution of critical information. 

“What” needs to be measured?

Once we have a handle on why we need to measure, we can then focus on what we need to measure.  This requires prioritization on the part of the Infosec professional.  So many different elements of our environments can be measured that we need to take care that information overload does not occur. 

Let us examine some areas that Infosec typically addresses:

• Identity Management,
• Change Control and Configuration Management, and
• Contingency Planning and Incident Response.

These areas give us a basis to examine the considerations that we need to take into account when developing metrics for these areas.

 Identity Management (IM)

Identity Management includes those areas that are typically involved in the identification of users and devices within an environment as well as the ability control access to that environment and the information therein.  While IM lends itself to many different metrics that are useful from an operational standpoint, senior management often does not need this level of detail.  The idea is to provide information that is relevant to senior management and this information should be related to the benefit that the organization is receiving through the use of the technology.  Metrics that may be useful could include:

•  The Number of Unauthorized Access Attempts vs. the Total Number of Users/Devices Accessing the Network, and
• The Number of Unauthorized Access Attempts to Critical Data Storage Areas.

This information provides senior management with a measure of success of not only security controls but with user training and help desk support with regard to new identity Management projects.  These metric measures put IM projects into perspective and highlight their effectiveness. 

 Change Control and Configuration Management

Change Control and Configuration Management involves all aspects of change within the environment and the impact these changes have on Infosec.  These aspects involve the systematic proposal, justification, implementation, test/evaluation, review, and disposition of changes to the information system(s), including upgrades and modifications.  

The metrics involved in this aspect of Infosec can be overwhelming.  This is an area where the “big picture” view that senior management needs can also be very useful at the operational level as well.  Some metrics to consider:

• Number of Required Functional Change Requests
• Number of Required Security Change Requests
• Number of Feature (Non-required) Requests
• Average LOE (Man-hours and funds) for each of the above
• Average projected loss of user productivity for each of the above

These metrics can be used to place the Change Control and Configuration Management initiatives into perspective.  Care must be taken though to relate these metrics directly to the company’s overall mission.  This linkage will vary depending upon the organization and how each department interacts. 

Contingency Planning and Incident Response (CPIR)

Contingency Planning and Incident Response addresses those areas critical to maintaining the operational ability of an organization during an adverse event.  These events need to be related to the loss the organization anticipates experiencing (or is experiencing in the case of Incident Response).  CPIR is traditionally one of those areas seen as a “money pit” within an organization.  This perspective gains strength the longer a company continues without a need to take CPIR actions.  Proper measurement and alignment of CPIR initiatives to an organization’s mission are critical.  While many metrics can be developed around this subject area, the key is to justify the need for resources.  To this end, it is suggested that a breakdown of activities include the cost of CPIR activities per hour vs. the projected expected loss per hour for that activity. 

Conclusion

The aim of metrics is to measure a particular activity in order to generate feedback that is needed in order to effect change that results in an improvement of the activity.  To that end there are many different metrics that can be useful to various levels within an organization.  This makes it important to aim the metric at the appropriate audience in order to present that information that is most relevant.  As with any presentation or proposal, understanding the intended audience is key to achieving success.  This is no less important with the development of metrics.

Tags: job justification, Metrics, mission support, performance, quantify

According to the Wall Street Journal the Heartland Payment Systems Inc of Princeton, NJ has fallen victim to a data breach that may have resulted in the unauthorized disclosure of 100 million credit card numbers or more.  At this time the company can’t say how many records were lost but it does handle 100 million credit card transactions each month for more than 250,000 businesses nationwide for a total processing volume of $20 billion dollars (according to the companies Q3 2008 Earnings Call).  This data breach has the potential to be bigger than the TJX data breach.  The data compromised is supposed to be “track data” the crown jewels of credit card information because it allows the attacker to actually reproduce the victim’s credit cards. 

Heartland was first alerted to the possibility of a breach by Visa and MasterCard who detected a pattern of fraudulent transactions.  Heartland’s investigation has revealed the presence of malicious software on its systems which Heartland’s president Robert Baldwin characterized as “light-years more sophisticated” than the run-of the mill malicious software typically found on the Internet.  This raises the possibility that this was a targeted attack as opposed to a “drive-by” infection. 

What is also curious is that when I did some looking into Heartland and PCI I found that security and PCI compliance was one of the main selling points of their service based on these two PDF’s I found.  (Retail Solutions PCI and RippedOff). 

Now I don’t work for Heartland nor do I know anyone who has so I don’t have an axe to grind any more than I have an ass to kiss.  It is early days in this data breech story so at this point I’m prepared to give Heartland the benefit of the doubt that they had taken reasonable and prudent measures to protect their data consistent with their industry.  I was also able to find a quote from Robert Carr, Heartland’s Chairman and Chief Executive Officer on the importance of security:

We also recognize the need to move beyond the lowest common denominator of data security, currently the PCI DSS standards. We believe it is imperative to move to a higher standard for processing secure transactions, one which we have the ability to implement without waiting for the payments infrastructure to change. We believe that standard to be true end-to-end encryption, and we are committed to launching this new standard in the fourth quarter of ‘09 or early 2010 with several forward-looking clients and industry partners. We believe that the payment world is at risk, relying on virus protection software to protect us from determined criminal organizations.

When I add up what I’ve found it appears that once again we have an example where simple compliance with standards does not necessarily equal security.  If Heartland was fully compliant with PCI DSS, and I have no reason at this point to believe otherwise, then it should serve as an example to change the perspective we take on securing our information from one of compliance to one of risk.  (although I’m admittedly perplexed at why they were storing track data… If they were truly storing full track data, to include the CVV and/or PIN number then that would call into question their PCI compliance. )

This is definitely one to watch in order to see how it develops.

Tags: Data Breach, Fraud, Heartland Payment Systems, malicious software, malware, MasterCard, PCI DSS, Robert Carr, TJX, track data, Visa, Wall Street Journal

It has always been my intention to keep this blog on topic and resist the urge to dilute it with subjects that are not related to information risk management.  That said I think that today will be an exception so I beg your indulgence while I wax patriotic for a moment. 

Today in Washington D.C., the United States has for the forty-fourth time in the nation’s history inaugurated a new leader.  For the forty-fourth time we have successfully transferred power without bloodshed and violence.  We do so despite the deep political divisions that we have within the United States. 

As a people we have come together in this way to forty-four times but today is different.  Today we have been witness to a first.  Today we have finally realized the words first espoused by the founding fathers in the Declaration of Independence: “We hold these truths to be self-evident, that all men are created equal …” Today we have realized the first payment in the promissory note that Dr. Martin Luther King referred to in his “I Have a Dream” speech.  Today we have been witness to the inauguration of the first African-American to hold the office of President of the United States. 

As I sit and watch today’s events unfold before me I cannot help but be proud of my country and hopeful for the future.  I find it difficult to imagine how any American, regardless of political ideology, cannot be proud of our country on a day such as this.  We have achieved a major milestone in our “Grand Experiment.”   We still have our differences and we are still striving for “a more perfect union” but today is a day for celebration and hope.  Sadly, the political partisanship will return all too soon but it is nice to have at least one day every four years when we can step out of ideology to celebrate what it is that brings us together in the first place.

In the first part of this multi-part post we set the stage by talking about what you need to protect (i.e. the information).  In this post we’ll talk about two key legal concepts: Liability and Damages. 

Again let me reiterate that I’m not a lawyer and what I’ll be giving is a layman’s interpretation of the topics that I’ll be covering.  Nothing that I’m going to write should be construed as legal advice or in any way definitive.  While it is useful to have a familiarity with these topics, you should always consult a qualified legal professional whenever you deal with these issues. 

When talking about legal impacts the first item that comes to mind is the concept of liability.  Liability is the legal responsibility that one has related to their actions or omissions.  In the context that we are using liability refers to the legal responsibilities that a company has with regard to how they protect, or fail to protect the information within their control. 

In order to prove that someone is liable for damages you must prove that they (a)had a duty to act, (b) failed to fulfill that duty, and (c) that the proximate cause of the failure caused some injury or harm to another.   It is important to note that one can become liable through action, inaction, and statute or law.  The classic example of statutory liability is that I loan my car to you and you become involved in an accident in which you are at fault.  You’re liable for damages caused through your own action (or inaction) but I may also be liable if local laws state that a vehicle’s owner is responsible for the damages caused by his vehicle – even if I wasn’t in the car at the time of the accident. 

Contractual Liability if of course that liability that comes about because of a contractual agreement between two parties.  For our purposes there are two main types of contracts that come into play:

• Business-to-Business Contracts and
• Consumer Contracts

Under the category of Business-to-Business we have such contracts as outsourcing agreements, service provider agreements, hosting agreements, and independent contractor agreements.  There are others but these are the main one’s that I’ve run across.  All of these contracts involve situations where one party is being entrusted with the data of the other party in some way, shape or form. 

Consumer Contracts involve agreements such as terms of use, subscriber agreements, privacy policies, and click through agreements.  In some cases Consumer Contracts can also involve statutory requirements such as in the case with health care information (HIPAA) and financial information (GLBA). 

There are three elements of a contract:

• The parties involved must intend to enter into an agreement between themselves;
• The parties must contract with each other to perform a legal act (no court would enforce a contract to perform illegal acts); and
• A benefit or consideration must be given or transferred.

Contracts can be formal, informal, written, oral, or just plain understood.  Without an expressed written agreement the theory of implied contract (promissory estoppel) can come into play. The elements of promissory estoppel are:

1. A promise must be made that is unambiguous in its terms;
2. The promise must be relied upon by the party to which it was made;
3. The reliance is expected and foreseeable by the party making the promise;
4. The party relying upon the promise must do so to his injury. (Cohabaco Cigar Co. V. United States Tobacco Co., 1999)

So we know what constitutes a contract and that it need not necessarily be written.  It can also be enforced although the essential elements of a contract may not be present due to the concept of promissory estoppel.  So we can protect our companies by having an iron clad user agreement in place for our customers, right?

Well those take-it-or-leave-it type agreements are called contracts of adhesion.  The user either accepts the agreement or doesn’t use the site but has no power to negotiate the actual terms of the agreement.  According to Farnsworth on Contracts (§4.26), the courts are likely to interpret any ambiguity in the contract against the drafter of the agreement because there was unequal bargaining power in the formation of the contract between the parties.  Furthermore the courts have ruled that in cases of unauthorized disclosure of information there is the possibility that there could be a breach of an implied contractual duty of confidentiality. (Peterson v. Idaho First National Bank (1961))

Now let’s start to wrap all of this together.  We now know how to basically identify liability in cases of a data breach or mishandling of information.  We know the basic concepts of a contract and how it can be implied as well as written.  We know that the courts are leaning towards categorizing data breaches and data mishandling as breaches of contract so it would seem that things are stacked against the companies who experience a data breach or otherwise mishandle personal information.  The problem however comes down to the concept of damages. 

In the case of a breach of contract the normal remedy would be for the aggrieved party to recover their actual damages.  The problem is that it can be difficult to quantify these damages if they can even be proven in the first place.  The courts have ruled that mere disclosure of information does not necessarily result in damage (Dwyer v. American Express Co. (1995) and Smith v. Chase Manhattan Bank, USA, NA., (2002)). 

On the consumer side we have statistics that we can point to but that doesn’t necessarily constitute actual damage.  For instance we know from the FTC’s 2006 Identity Theft Survey Report that the average value of goods and services obtained by identity thieves is $500 and the average number of hours that victims spend resolving their problems is 4 hours.  (Honestly I think these figures are low but they are what they are.)

On the corporate side the unauthorized disclosure of trade secrets could put a business at a significant disadvantage if not put them out of business outright?  How do you quantify this in an ever fluctuating market?  Most commercial contracts contain disclaimers that limit the liability and damages that can be sought in the event something like this happens.  Some contracts exclude or limit one party’s liability in the event of a data breach making recovery next to impossible. 

Many contracts also have some type of indemnity clause which protects one party against loss or legal action.  Typically indemnification works like this.  Party A agrees to indemnify Party B (their subcontractor) for any third-party claim arising out legal actions involving Party A and its subcontractors.  Things become even more complex the more layers you add to the mix.  For instance Party A is responsible to its customers for their personal data by contract then subcontracts to Party B a function that requires access to that personal data.  Party A needs to ensure that its contract with Party B contains obligations that are similar to, if not identical to the obligation that Party A has to its customers.  If there any gaps and a data breach or loss occurs then Party A may find itself between its customers and its subcontractor without any resource against the subcontractor. 

So while we can trace a line from liability through contractual issues and sometimes down to actual damages, we have very little actual legal precedence as every legal case involving a data breach that I’ve been able to find has settled prior to adjudication.  We can refer to the settlements that companies have paid when they experience a data breach but without courtroom precedent it becomes difficult to accurately quantify the costs of a data breach as it can fluctuate wildly. 

In our next part we’ll review U.S. Federal regulations with regard to the protection of data and see how that ties into the concepts legal concepts of liability and damages.

Tags: breach of contract, business-to-business contracts, consumer contracts, contractual liability, damages, duty to act, Farnsworth on Contracts, FTC, liability, not a lawyer, promissory estoppel