Data Auditing Blog

Getting life back from compliance

James DeLuccia IV (http://pcidss.wordpress.com/2009/06/25/audits-of-the-future-must-enrich-and-enforce-your-it-strategy/)and I did a webcast this past week that covered an interesting theme of the year. The title was - "Getting life back from compliance". It essentially covered the question of economics around data auditing. Many enterprises are struggling with the enormous amount of work compliance has created and thrust upon IT. The first step out of this insanity is to step back and try and quantify how much work is compliance…really. The next step is to translate this into costs – hard costs and soft costs. Further classifying hard costs into development costs, capital costs, and operating costs. Once we have this number we can all stare at it long and hard until we internalize the implication: which is that it is a staggering number. Don’t believe me, check out the numbers – for a 100 database project around SOX & PCI activity monitoring/logging/reporting/reviews cost an enterprise $2 Million over 3 years – roughly an extra 40% overheadover the enterprise IT spend.  The productivity hit to the IT staff is even worse. Here is the link for details - http://www.tizor.com/News-And-Events/Events/ROI-of-Auditing-and-Compliance-Lifecycle 

Which brings us to the next part of the webcast. What can we do about this? We could stare some more and eventually punt on the problem – this is common, many application owners dump all data (relevant or not) on to the auditors and make it their problem. Unfortunately this makes the problem worse in the long term. Our suggestion is to look into automation. There are tools available (Mantra being one of them) that are purpose-built and turn-key. They capture all the nitty gritty issues, around scoping applications, logging & storing the right type of information, creating reports, managing this effort quarter after quarter. These tools can relieve the impact of compliance and help get your life back….really.

At some point, I will do a series of posts to dig into this in more detail. For now, check out the webcast if you are interested.

By the way, James DeLuccia’s book on IT Controls and Compliance is a good read - http://www.amazon.com/gp/product/0470145013?ie=UTF8&tag=itcomandcon-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0470145013

Rajeev Motwani: In Memoriam

Over this past weekend, I received a shocking news. Rajeev Motwani passed away in a senseless accident at his house. At first it was hard to even believe this could be true until I talked to a few friends. It is still hard to accept.

I was first introduced to Rajeev through interesting circumstances. A few years back, a security architect at a financial services company found the Mantra data mining technology interesting enough that he put me in touch with Rajeev. Rajeev was a Professor at Stanford, and known to be a leading expert in CS theory and algorithms with interest in data mining and privacy. As soon as we had a first conversation we clicked right away. We found many other common connections. My wife knew of Rajeev as “Mots” from her Berkeley days.

Rajeev soon became an advisor to Tizor. Rajeev was very much the active advisor – he worked hard without expecting a return. Over the years, we met pretty much every time I visited the bay area. We had our favorite haunts. One of them was University Café in Palo Alto. Once as I took my Starbucks there, Rajeev forced me to dump it down the trash before we could get down to our discussions. At another meeting, Rajeev wanted to find out how the Google stock was doing – they had just gone public, but he was too busy to track it. Rajeev was a formative influence on the Google founders and technology, particularly Sergey Brin (http://too.blogspot.com/2009/06/remembering-rajeev.html). 

Rajeev was very supportive through all the key events at Tizor. His rolodex was phenomenal as was his effort. He was excited about the Netezza acquisition of Tizor and was looking forward to being a part of the future technology inventions and possibilities. Last year, when my wife and I founded a startup around mobile analytics, Rajeev was the first stop for us, and again he readily rolled up his sleeves to become actively involved. 

As I analyze why I enjoyed interactions with Rajeev, I realize he was a complete person. Unlike CS theory purists, he was comfortable with non-optimality. This combined with his rigor was an unbeatable match. Unlike many other professors, Rajeev was equally comfortable in technology and business. He had an astute nose for common sense and what works. (I would often suggest to Rajeev to jump full-time into entrepreneurship, and he would just nod.) Above all, he had strong integrity and ethics and a sense of giving. He represented the best in us. I will miss him dearly. 

Data Auditing in Regional Banks – A Humbling Moment

Occasionally as I survey first-hand the experiences of enterprises dealing with compliance and risk management issues, there is a “wait a minute” moment. A humbling moment if you will. Most recently, this humbling moment happened as two regional banking customers of Mantra were sharing their experiences. Regional banks as I learnt, are in an interesting place and have unique challenges.

First, they are small – particularly in comparison with the huge financial services companies. Their operating IT teams are small. Their security resources are miniscule. Their application teams are daily firefighters used to manning multiple fronts.

However, unlike other smaller enterprises, the compliance and regulation pressure in a regional bank is intense. A regional bank has all the usual regulations of a large financial services company – as well the hand of FDIC is omnipresent.

As it turns out this unique combination can challenge the best of them and often brings out the best in them. The questions I was interested in understanding from these banks were – 

1. How do regional banks deal with compliance & risk management problems like data auditing? How do they approach the problem? 

2. What are their top drivers?

3. Who leads these initiatives? What are the people, process, and technology issues? Does the security person drive, or does the application owner?

4. What role does technology have to play in this? What are the critical technology challenges in this environment?

The answers to these questions are interesting. In summary: 

• Compliance clearly seems like the top driver, though viewed through risk management lens.
• SOX, Privacy, and FDIC-led audits seem to be top drivers.
•  People driving initiatives seem to be all over the map when it comes to roles – the only common characteristic is that they are usually entrepreneurial leaders, who have a strong combination of hands-on operations and strategic thinking. 
•  Technology has a huge role to play – almost an essential requirement since resources are tight. Total Cost of Ownership (TCO) seemed to be the leading requirement of technology – not just automation, but ease of use and reliability across the whole life cycle of deployment, management and integration. For regional banks, technology becomes an essential operational tool for viewing business risk. There is no room for error or overhead.

For first-hand perspectives from a regional bank, check out the webcast we did recently  – http://www.tizor.com/News-And-Events/Regional-Banking-Webinar

 

RSA Show 2009 - Quiet Year of Operationalizing Security Technologies

I have been tracking the RSA Show for a few years, and each time I return the question always is what is the show theme for the year. (This theme is usually the viral outcome of collective water-cooler conversations by the RSA show attendees – it is not the official mandate of the RSA program committee.) For example, last year’s theme ended up being about governance. The year before that was data & DLP.

2009 RSA show didn’t seem to have such a theme. This year the technology talk was more of the same – compliance, log management, DLP, encryption, …. (I am ignoring all talk about cloud security – while some vendors made an effort to call out cloud security, this is still too early to matter. )  Under the surface though, I noticed that the leaders and visionaries were busy retooling and hard at work with their products. The theme if any was to make technologies work in driving security and compliance into a large-scale enterprise. Driving initiatives into deployment. Driving them into scale. Driving them to manageability. While these drives are not sexy, they can lead to meaningful value for enterprises. They are sometimes the source of very interesting innovation. 

One example at home, was Tizor’s announcement of Mantra 7.0. This release extends the scale of data auditing significantly beyond what has been available in the market. For our press release – see http://www.tizor.com/News-And-Events/Press-Releases/4-07-09

Since this is my first post since Tizor's acquisition by Netezza (NYSE: NZ), I am also reminded of an interesting anecdote I heard recently from Ray Tacoma, the VP Sales at Netezza.  Ray's grandfather, a farmer, taught him the lesson that winters were the best time to sharpen tools. This RSA show was about showing off meaningful and sharpened tools in the winter of 2009. 

Heartland Payment Systems Breach - TJX Breach 2.0

It was announced today (Jan 20, 2008) that Heartland Payment Systems, the sixth largest payment processor in the US, had a breach in 2008 that may have resulted in the theft of over 100 Million credit cards. While there are several theories about how the attack happened, the evidence shared so far seems to indicate that this form of compromise is quite similar to the TJX incident.

Form of Attack: In this case, there was apparently malware that ended up sniffing centralized transactions within Heartland network with credit card data in the clear. At some point, presumably this malware then exported the captured information out to the thieves’ data center.

In the TJX case, there was a two-stage attack – the first stage of which used a WEP weakness to find privileged credentials and get at the unencrypted data-at-rest on RTS servers. This was then followed up by installation of malware to sniff transactions on the network.

The Heartland case has the second-stage attack – there is no information on the first stage. However, it is hard to imagine a way where the second-stage can be achieved without privileged credentials. Hopefully more data will be released when this incident makes it to court. With TJX, it took more than a year to get these details out so it is best to be patient.

Form of Detection: Another similarity to TJX - I am sure we will keep getting asked the same question again - what’s a way to detect these attacks in real-time? My suggestion - Combination of DAM (data activity monitoring- to detect data-at-rest attacks and unencrypted data access) and DLP/NBAD (data leakage prevention/network behavioral anomaly detection - to detect large outbound flows) are reasonable ways to detect these attacks in real-time.

Structured Data Discovery for Databases: Do's and Dont's

Recent enterprise data discovery projects have just begun to realize that database discovery (of structured data) is the next big challenge.

Two use cases for discovery I have encountered commonly are:

(1)  Identifying when production data moves over to test databases so that this data can be masked.

(2)  Inventoring databases with sensitive data (credit cards, SSN) - particularly unencrypted or unmasked data

The reason the structured data discovery problem is hard is that it involves many unknowns and has classic manageability issues around it. First, many enterprises dont even know where their databases are, or how many they are, or what type they are (Oracle, DB2, SQL Server, Sybase, etc). This is the database inventory problem. Two, enterprises dont understand how to scan these databases for credit cards or production data patterns (e.g. fund information) in a manageable way. For instance, you cant scan a database without having credentials to login as an adminstrator. Additionally, doing a verbose scan of a million-row database table or column can bring down the database to its knees, not to mention the challenges with where to store the result set. 

 I have a few suggestions on tackling this problem by making it simple. Break the project into mini-steps and crawl before you walk (literally in this case!):

(1) Start with database discovery first. Also do a schema discovery and a role discovery while you are at it. 

(2) For data discovery scans, do a network-based discovery first that does not need credentials. It will help reduce the search space of likely databases that have critical information. This should also give you some usage discovery - in terms of how data is being accessed by users, time, location etc. Databases that are rarely accessed have lower risk and you may be able to get to their discovery down the road. 

(3) Once you understand roles (see step 1 above) and obtain credentials you are ready for data-at-rest scan. Start with a "sampled" data-at-rest scan to keep the performance impact manageable. For example, a scan that might sample X% of the rows to see if there is a match with a pattern. You can follow up the sampled scan with a more detailed data inventory scan.

 (4) After data discovery has completed, translate the results into risk assessment metrics. For instance, a database with large number of unencrypted credit card records has a high risk. 

 (5) Depending on the risk metrics, specific risk mitigation techniques may need to be adopted. For instance, deletion or masking or encryption of sensitive fields could be required. Alternatively, monitoring access to sensitive data fields may be an acceptable risk management strategy. Check with your assessor or auditor or with the best practices.  

A recent article covers this problem from a life-cycle perspective. Check out http://www.scmagazineus.com/The-data-discovery-challenge/article/120467/

DLP & DAM - Edge and Core Data Protection

DLP and DAM are two technologies related to discovery, monitoring & protection of data that are in the news, but often confused.

• Where: DLP is focused on the edge/egress and is evolving towards end-points. DAM is focused on the core data center, around the databases and file servers.
• What: DLP is becoming a security mainstay for many enterprises struggling to assess their edge leakage risk. DAM is has been focused more on compliance of databases, but it is rapidly evolving into broader, core data risk management.

Some good news to help clear up this confusion. Rich Mogull of Securosis is doing a Webinar focused on this topic on Tuesday, July 29, 2008 at noon EDT.

The Webinar is sponsored by Tizor. Check it out: information/registration. I have known Rich for a while now, he is one of the most perceptive security analysts around.

To reference some of my past posts on this topic, check out:

Data Auditing & Protection (DAP) vs. Data Leak Prevention (DLP) – Theft vs. Leaks

DLP is Dead. Long live DLP!

Data Breaches: The threat of “unknown unknowns”

The recently published Verizon Data Breach Study, 2008 Data Breach Investigations Report, has some remarkable analysis on data breaches. Based on analyzing a collection of 500 forensic investigations over four years, the study describes interesting patterns that emerge from detailed understanding of data breaches. It is important to note that while the Verizon study has a large sample size; it is biased because it only contains investigations of Verizon customers. Even so, this study has a few statistics that are worth noting. One interesting statistic deals with the threat of "unknown unknowns" and the need for data risk assessment.

What is an unknown unknown?
The Verizon study defines an unknown unknown along one of four dimensions - a system, a data store, a network connection, or privileged access.
1. Unknown system - a system unknown to the organization or business group affected by the breach
2. Unknown data - a data store that the organization did not know existed on that system
3. Unknown network connection - an unknown network connection or access used by the data breach
4. Unknown privileged access - a system that had unknown accounts or privileges

How often is there an unknown unknown involved in a data breach?
90% of data breaches involve an unknown unknown! This, I think, is a truly remarkable statistic. In essence, unknown unknowns seem to be a lead indicator for data breaches.

How is the threat of unknown unknowns distributed?
The figure shows the distribution of unknown unknowns. 66% of data breaches involve unknown data, 27 % involve unknown network connection, 10% involve unknown system, while 7% involve an unknown privileged access. Vast majority involve unknown data - data that the organization did not know was present on the system.

Implications for risk & threat management: What can we do about unknowns?
Threat management may be more black and white than gray
In a sense this points out that most breaches are caused because of an inadequate visibility of the most critical elements of an organization system - its critical applications, its critical data assets, its network connectivity, or privileged access flows. This problem is relatively straightforward to fix since it involves visibility of a relatively small number of critical elements. This is good news. Imagine if this were not the case.  If data breaches had involved mostly known elements, both detection and risk mitigation would have had to become more sophisticated around behavior.

Step 1 - Data: The dominant unknown
This analysis shows that 66% of data breaches have an element of unknown data or data store. This points to the need for data discovery (to find databases) and data classification (particularly for critical data assets like SSN, credit cards, and PII information). If such stores were to be found and inventoried, their security would automatically be raised. The simplest first step is to discover the unknown data. It also covers dominant number of breaches, so this step has a huge return on investment.

Step 2 - Data activity risk assessment: cover all unknown unknowns
The next important step is to do a data activity risk assessment - that is to monitor the flows around critical stored data in databases & fileservers (discovered in step above). These flows can show all access activity around stored data. From these activities, simple risk assessment reports can be generated that shed light on the remaining three unknowns accounting for 44% of data breaches:

1.  Unknown privileges - Discovering and classifying privileged activity with roles should be part of a basic risk assessment exercise. Additionally, high risk privileged activity (such as failed logins, privilege escalation, error codes, access to customer data) should be framed as high priority risks and escalated.
2. Unknown connections - Discovering and tracking connections based on access protocols, applications, IP addresses, and hosts should be another part of risk assessment. High risk connections (such as ad hoc activity outside normal applications, activity outside typical set of hosts or IP addresses, etc.) should be framed as high priority risks and escalated.
3. Unknown system - Discovering all systems (such as databases and fileservers) that have critical assets should be a basic part of risk assessment.

The breach that didn't happen

Often enterprises think of monitoring tools as a way of providing visibility into breaches that might be happening under their noses.This use is like a “whistle-blower or early warning system that alerts you to risks. There is however another value proposition around monitoring tools which is as critical but often gets overlooked. It is what I call the use of monitoring for breach-validation or breach-verification or correctly for verification of lack of breach. Monitoring tools can actually quantify or substantiate a data breach in terms of how many data records or systems were compromised. This can help separate minor incidents from major devastating incidents.

Here is a recent case in point. The Best Western hotel chain incident is in the news. Apparently the The Sunday Herald reported that August 21 , "a previously unknown Indian hacker successfully breached the IT defenses of the Best Western Hotel group's online booking system and sold details of how to access it through an underground network operated by the Russian mafia.

The report claims that records of every customer to have booked a room at one of the Best Western's 1,312 continental hotels since 2007 -- 8 million -- were taken. The Best Western hotel chain has responded by accusing the paper of being sensationalistic. It counts a mere 13 records that may have been exposed as a result of "suspicious activity." In a public statement, Best Western questioned the Sunday Herald's story, saying that it "is grossly unsubstantiated" and that the paper's claims about its customer records "are not accurate."

"We have found no evidence to support the sensational claims ultimately made by the reporter and newspaper," the statement says. "Most importantly, whereas the reporter asserted the recent compromise of data for past guests from as far back as 2007, Best Western purges all online reservations promptly upon guest departure."

In an e-mail, a Best Western spokesperson said,"There was one instance of suspicious activity at a single hotel with respect to 13 guests, who are being notified. We are working with the FBI and international authorities to investigate the source of the other claims, which were never presented to us for investigation prior to publication of the Herald story. We have found no suspicious activity to support them."

A data activity monitoring (DAM) system or a DLP system with audit logs could very well have validated this breach (or its absence). 

Motorola Spying Incident: Implications for DLP & DAM monitoring

The incident reported yesterday by ABC News has created waves. Apparently the computer engineer who worked at Motorola was caught with hundreds of proprietary documents in her possession. Interestingly, she was caught not because of any data security monitoring within Motorola but because the customs agents at the airport found she was carrying too much cash. This was an example of how weak the general state of monitoring is within enterprises.

Three implications:
1. If you are not monitoring, start to monitor sensitive data for theft and leakage

I read an interesting study conducted by the Verizon Business Risk team that surveyed over 500 data breach incidents. Apparently 82% of the data breaches could have been detected before the actual compromise, had there been monitoring of event logs. Enterprises need to turn on their data cams.

2. What to monitor? Egress, users, or servers?
A related question is where to point the data cam? At each enterprise user? At the egress? At the sensitive data servers? Each of these locations has implications in terms of cost and effectiveness of seeing specific types of data theft attacks.

• This particular incident would not have been caught by egress monitoring (DLP – data leak prevention) because the engineer downloaded all the documents to portable drives.
• Laptop-level endpoint agent monitoring could have caught this, but this type of technology is expensive to deploy and maintain. Think of 50,000+ laptops at Motorola. 
• Monitoring data servers (DAM - data activity monitoring) would have been an efficient way to catch this theft. Why? Lets do the math.
  

3. Using DAM to detect Motorola theft in real-time

• Monitoring footprint: Motorola has probably 1000+ sensitive servers. 20-30 DAM appliances can monitor all these servers. Not a big expense considering the value of this theft (estimated at $600M).
• Based on the indictment documents, the engineer downloaded 200+ documents between 9 am and 2 pm on Feb 26, 2008. A simple DAM threshold that tracked the number of documents downloaded on sensitive file servers could have caught this in real-time. (Threshold can get more sophisticated, but again most egregious attacks are high volume.)
• The DAM appliance could have sent an alert to the security team. A simple phone call to her boss would have confirmed that this was suspicious.