Israeli Software

Automated discovery of data at rest is  an unsurmountable  challenge for institution with large quantities of PCs, data and thousands of document formats, most of which are not well-documented and all the application and database server technologies that were ever invented. Smaller companies may find it either unnecessary or not cost-effective.

Discovery of data at rest is also  a double-edged sword.  From a compliance perspective, it’s not only not required by PCI DSS 1.x but it can create exposure issues that no business in their right mind would want to deal with.  Also – why would a business want to buy products and services from a technology vendor vendor and allow them to “discover” their data?

Love to hear your comments and what you think.

Compliance is about enforcing business process – for example, PCI DSS is about getting the transaction authorized without getting the data stolen. SOX is about sufficiency of internal controls for financial reporting and HIPAA is about being able to disclose PHI to patients without leaks to unauthorized parties.

So where and how does DLP fit into the compliance equation?

Let’s start with COSO recommendations for internal controls:

“If the internal control system is implemented only to prevent fraud and comply with laws and regulations, then an important opportunity is missed…The same internal controls can also be used to systematically improve businesses, particularly in regard to effectiveness and efficiency.”

In this article I will show that DLP technology such as Fidelis XPS, Mcafee DLP, Verdasys Digital Guardian, Websense Data Security Suite and Symantec Data Loss Prevention 9 – is a necessary but not sufficient condition for effective data security. I submit that effective data security is a three-legged stool of:

1. Monitoring – using DLP technology
2. Training – strengthening of ethical values with training and personal example at all levels of management
3. Accountability – paying the price when a data loss event happens

Read more…

The Verizon Business Report on data breaches 2009 was released – the data breach investigations report headlines with 285 million data records breached in 2008:

• 91% of attackers were organized crime
• 74% of attacks by malicious outsiders
• 67% of vulnerabilities due to system defects
• 32% implicated business partners

The report must be particularly disturbing to endpoint DLP vendors focused on preventing data loss by trusted insiders on  PCs (  99.6% of data was breached by  attackers attacking servers…. )

My experience with clients in the past 5 years in the data loss/extrusion prevention business has been focused on discovering internal security vulnerabilities and implementing cost-effective security countermeasures.  Our findings (summarized in our Business Threat Modeling white paper) were based on analyzing empirical data of 167 data loss events points a finger at software defects as a key data loss vulnerability. The Verizon business study appears to suggest that the situation has only gotten much worse – i.e. data breachs are rising as software quality is declining.

A conservative estimate in our research showed that 49% of the events exploited software defects as shown in the below table. Theoretically we can mitigate half of the risk by removing software defects in existing applications. The question, which we  answer in the white paper is how.

The Carnegie Mellon Software Engineering Institute (SEI) reports that 90 percent of all software vulnerabilities are due to well-known defect types (for example using a hard coded server password or writing temporary work files with world read privileges). All of the SANS Top 20 Internet Security vulnerabilities are the result of “poor coding, testing and sloppy software engineering

Pop quiz – what is the limit on a HTTP GET request or HTTP PUT request?  Does it have to do with the server/browser or  RFC2086?

Check this

I’ve been saying for a long time now that compliance standards like PCI DSS 1.2 have created a marketing franchise for auditors instead of improving security.

Empirical evidence of the past 2 years suggests that compliance focuses on meeting auditor requirements instead of assuring actual security of your systems and customer data assets.    Here’s an interesting interview with Chris Nickerson who is billed by SearchSecurity.com as “your worst nightmare. He’s the guy you never see coming, the one who can slip into your data center, install malware on any server he chooses and ease back out without so much as a shadow on your security cameras”.

Newspaper hype aside – Nick had an important insight on PCI compliance:

You might be compliant, but if your system is compromised, you’re going home without a paycheck. People err on the side of compliance versus security.

Quantity or quality -  that is the question!

There is a great deal of debate between the supporters of quantitative risk assessment and the supporters of qualitative risk assessment in the security and compliance business.

The qualitative people say that since it is impossible to estimate risk as an absolute number such as  “87 percent probability of your customer data being stolen by an angry employee”, they would rather rate that risk as “high”.

The quantitative people say that risk is a function of threat, ARO (annual rate of occurrence) and percent damage to the asset.   If the annual rate of occurrence of an attack is twice/year on the average and the percent damage to a customer list is 10% of its value, then the risk of your customer data being stolen would be 2.0×0.10 = 20 percent on a yearly basis.   The qualitative folks are quick to retort that it’s impossible to estimate ARO, since most organizations don’t collect historical loss data for security  and compliance events. (This is actually a good case to start collecting data now…) They also claim out that it’s impossible to accurately estimate the value of an asset such as a customer list in dollars (need to ask the right person – like the CFO…).

Since I am a physicist, I must say that I am biased towards physical models that can be calculated and observed.  I would start with three assumptions:

1. The estimated value of an asset  is analogous to it’s momentum mv,  the product of its mass and velocity.  A very large database of 10 year old customer data that was archived in the Colorado Rockies might have a large mass but almost zero velocity and therefore low value.   If the database had 100,000 transactions/day then it would have a high velocity,  correspondingly high momentum and high value. Note that this model runs counter to all  privacy regulation but I think it holds water from a practical perspective.  No one ever said that our legislators were good at physics….

This physical analogy leads to some interesting conclusions. If an attacker were to steal 10 million customer records from the archive in the Colorado Rockies – the dollar value of the damage would actually be low in this model.   On the other hand, if  political attackers were to access the flight details of only one  passenger name record, the damage might be very high if it was disclosed that a US presidential candidate called Barack Obama, was using frequent flier mileage to get away for an intimate weekend with Janet Jackson. Or not…

2. The ability of an attacker to damage an asset is analogous to the force it can exert on the object we call an asset.

3. The ability of a security countermeasure to protect an asset is analogous to the force it can exert on the attacker.

Observed from an inertial reference frame, the net force on the object (the asset) is proportional to the rate of change of its momentum F = d (mv) / dt.

Force and momentum are vectors and the  resulting force is the vector sum of all forces present.

Newton’s Second  Law says that  “F = ma: the net force on an object is equal to the mass of the object multiplied by its acceleration.”

If the attacker manages to decelerate the asset to v=0, then the momentum of the asset is zero and it has been rendered inoperative.   In a case like this – the damage to the asset is 100%

If the asset runs faster than the attacker or another force (a security countermeasure) deflects the attacker, then the asset momentum is unchanged, and damage to the asset is 0%.

This simple-minded physical argument shows that risk is indeed a dependent variable;

Risk = the vector sum of the forces of the attackers and security countermeasures relative to the asset.

As in physics,  we must observe and collect data if we want to be able to calculate risk.

1.  Asset value (momentum)

IT security and compliance people should ask their CFO how much the asset is worth in dollars

2. Attacker force  relative to the asset

3. Countermeasure force – relative to the attacker.

No one said it was easy – which is why not everyone is doing quantitative risk assessment. But – that’s why we’re getting paid the big bucks – to calculate risk to the best of our abilities.

References:

High School Physics – Newton’s Laws

Risk assessment – Practical threat analysis calculative method

just saw a post  from a month ago by Jeremiah Grossman from White Hat Security on his blog PCI-DSS references the outdated OWASP Top Ten

There are actually a number of more serious technical issues with PCI DSS 1.1 than using the OWASP Top 10 from 4 years ago. Note the definition of vulnerability management in Section 5 as “Use and regularly update anti-virus software or programs”. Note  “Requirement 1: Install and maintain a firewall configuration to protect cardholder data.” A firewall cannot protect cardholder data by definition, since a) a firewall typically filters inbound traffic at the network layer and b) firewalls are incapable of identifying payment card data going out. This is why companies like Fidelis Security Systems and Vontu (acquired by Symantec) developed data leakage prevention products (which by the way are not even mentioned as a possible security countermeasure in PCI DSS 1.1).

The experience of the past 2 years has shown that PCI DSS 1.1 does not improve payment card security judging by the number of data breach events with large PCI-compliant merchants like Hannaford. I believe that this situation stems from  conceptual flaws in PCI DSS 1.1:

1. PCI DSS 1.1 was designed by the card associations and big processors to meet their needs – which means that it will probably never meet the current needs of over 4 million merchants in the US and over 8 million world wide.
2. The information security industry has not exactly bought into PCI DSS 1.1. As both the thread on Jeremiah Grossman’s blog  and general industry discussion show – there is a still a good deal of argument on the standard itself.
3. PCI DSS 1.1 is a one-size-fits-all compliance standard that makes all requirements mandatory without encouraging the merchant, vendors, service providers and consultants to analyze the merchant’s risk profile and find the right countermeasures at the right price. I cannot accept that a merchant smart enough to run a business in a down economy cannot think in terms of assets, threats, vulnerabilities and cost-effective countermeasures.
4. A QSA has limited application and is far from a panacea for technical flaws in the standard. Note that the role of the QSA is only relevant for Level 1 merchants – and there are only about 1200 of those in the US and about 2500 world-wide.  Everyone else does self-assessment and would benefit from a standard that encourages them to think about threats and security. The PCI Association works to monetize it’s franchise with expensive qualification programs.  I believe in free markets, but there is mega-scale franchise building in the security and accounting industry with Sarbanes Oxley and  I am not optimistic that franchise building by the PCI Association contributes to improving the security of payment cards.

If it were up to me – I would make PCI DSS 1.1 an Open Source initiative like OWASP – I would give risk assessment software away for free to merchants and create a community of vendors, merchants, attackers and consultants who could share their expertise and create a more secure and more cost-effective economy for credit card processing. I would require disclosure of loss events and publicize a pricing guide for the security countermeasures.