LogBlog

« December 2008 | Main | February 2009 »

Top 3 mistakes of PCI requirement 10 (part 3)

By Dimitri McKay

This is the third installment in a 3 part series about the top three mistakes of PCI. This particular blog, however, is THE biggest mistake that enterprise customers make. Read more below:

Number 1: Capturing *some* of the data does not make you compliant:

My father used to have this saying. In the back of the house, he had a giant workshop in the garage. In that workshop he had hundreds, maybe thousands of tools. All sorts of widgets and doohickies. Tools that the majority of people in life would have no idea what purpose that certain tools serve. He even had a full size John Deere tractor. And I asked him one day... “Why do you have so many tools?” He said “I’d rather have a tool and not need it, then need it and not have it.”

I feel the same way about log-data.

Much of the focus of Requirement 10 is based on long term storage of log data. What do you store and how? One customer used to print out the logs onto paper each day and put the stack in his boss's office. (I’m dead serious.) I inquired as to why he does that, and he replied “It’s not my job to ask, it is my job to do.” By contrast, I’ve seen some customers go the opposite direction and want to encrypt all data at rest, all data in transit and all data on the originating hosts. That’s one way to approach immutability of data, however, that too is extreme. I’ve also seen customers who choose to log some devices, but not all devices. Unfortunately, having stacks of paper logs, encrypting all data and logging on select devices only doesn't ensure you'll be compliant.

One question people often ask is “What level of logging should I have on my [firewalls, routers, switches, file servers, etc.]”

That's when I reiterate my above mentioned statement, inherited from my father.

“I’d rather have it and not need it... then need it and not have it.”

More is always better when it comes to logging. Everything should be logged for security and forensics, not just for regulatory compliance or industry mandates. So, when PCI-DSS refers to maintaining an audit trail for a year... that’s not asking for some data. That’s asking for all of your log data.

Posted January 29, 2009 in | Permalink | Comments (0)

« December 2008 | Main | February 2009 »

A little known fact on log management and SIEM

I was somewhat surprised when somebody pointed out to me that log management has become a more popular term than security event management (in it’s various forms):

Nice.

Posted January 28, 2009 in | Permalink | Comments (0)

« December 2008 | Main | February 2009 »

From Native to Instrumented

According to Wikipedia:

To log is a verb derivative of the noun logbook; the verb form means to record in a logbook, and may have been coined in the 1820s. The term logbook itself stems from the practice of floating a stationary "log" (actually a wooden block attached to a reel via rope) to provide a fixed point of reference for the purpose of measuring a ship's speed (see Knot (speed)). Computer scientists adopted the verb to log circa 1963 to describe the systematic recording of specific types of data processing events.

Logs have been around since the dawn of computers. It's been used by computer scientists, IT administrators, security analysts and network operators to perform analysis, troubleshooting and forensics for over 45 years. In most cases, however, users refer to logs as pieces of information that devices and applications generate on their own. For example, routers and switches generate logs that detail their status and what they are doing. Firewalls generate logs showing the various connections passing through, or not. Operating systems and utilities generate logs to communicate accesses to different parts of the system. Web proxies generate logs to describe user surfing activities. These logs are what one would consider to be "native logs."

One type of logs that users don't generally talk about, or event consider, are logs that are generated by agents or systems monitoring network or applications. This type of logs is called "instrumented logs." The most well-known type of instrumented logs is probably IDS logs. IDS monitors the network and reports any attacks that are happening. These reported events are usually considered as logs. However, there are other types of "instrumented logs" that users don't normally consider as logs. For example, most of the application performance management (APM) tools use agents or other means to retrieve information or statistics from various applications. These information are then sent to a central server for processing. In most cases, these information are not considered to be logs, but they do fit the definition of "systematic recording of specific types of data processing events."

Another example of instrumented logs are what Adrian Lane discussed in his blog post "Database Activity Monitoring & Event Collection Options." In this post, he mentioned several methods that monitor monitor database activities via sensors that either monitor the OS stack or the database memory. All of these methods generate "instrumented logs" that are sent to a central server for archival and analysis.

At the end of the day, whether it's "native" or "instrumented" logs, they are still pieces of valuable information that must be collected, archived, and analyzed. Also, the way these logs are analyzed are the same regardless whether it's "native" or "instrumented." As Jon Oltsik said,

In today's dangerous security landscape, no data is considered "noise" anymore. Rather, security analysts now want access to terabytes of historical data for analysis. Furthermore, this underlying data has become more complex.

.
.
.

It means collecting, normalizing, and storing a ton of data. It means sophisticated algorithms and processor-intensive query engines.

As sophisticated enterprises move up the stack (Network to OS to Applications) in their log management projects, we will likely see more and more of the log data come from sensors instrumenting the applications. This type of "instrumented" logs provide another rich set of information, sometimes richer in information compare to their "native" counterparts. Existing log management and security event management solutions can then take advantage of this set of information for compliance management, threat management and fraud detection.

Posted January 23, 2009 in Innovation , Log Management & Intelligence | Permalink | Comments (0)

« December 2008 | Main | February 2009 »

Protect Your Data

2 DBMS info stored.png

According to Gartner, the database market is over $20B and is dominated by Oracle (42.3%). The next two vendors are Microsoft SQL Server (19.1%) and IBM with its Informix and DB2 offerings (23.5%). There’s a huge amount of sensitive information stored in these databases. A research report by Unisphere Research (see chart above) showed that the majority of the companies store customer information, financial data, intellectual properties and customer credit card information in the databases. It is no wonder that database is the target for most attacks these days! And unlike laptop theft where the offender might be an 18-year old wanting to use the laptop, a database breach requires expertise and the information stolen is certain to be used for illegal purposes.

The Kroll Global Fraud Report Annual Edition 2008/2009 showed that information theft, loss and attack is the #1 concern for executives. In 2008 alone, there have been 656 breaches, up from 446 in the previous year. According to Privacy Rights Clearinghouse (PRC), over the past 3 years, 5 million personal records are breached on a monthly basis. An SC Magazine article recently also showed that there’s a huge black market out there for these information. Back account details sell for 5-10% of the account value and credit card data can sell for up to $45 per account. Take this and multiple by the 2.3 million records breached at Fidelity National Information Services, and the DBA who did this would have a pretty nice payday!

Insider threat is a growing trend and cannot be ignored. Unfortunately in most organizations, privileged access is granted excessively and managed poorly. Developers and external consultants often have access to sensitive information without much restriction. The fact is, database-stored data is “in scope” for most compliance requirements, including PCI DSS, SOX, HIPAA, EU Data Protection Act and others. All these apply to databases that are housing most of the enterprises’ sensitive information. The common compliance requirements include

Enterprises need comprehensive database security monitoring and prevention solutions to defend against internal and external threats. These solutions should protect all data copies, locations and platforms and should be actionable in real-time to detect, alert and prevent. Securosis analyst, Adrian Lane, recently reviewed various options for monitoring access to these sensitive information, from both external hackers and insider threats. According to Lane, many IT departments aren't aware of the various data collection options available. He says some DAM vendors don't even realize the limitations of their own offerings.

So what should enterprises do to protect their data? Here are some suggestions:

Posted January 16, 2009 in | Permalink | Comments (0)

« December 2008 | Main | February 2009 »

Top 3 mistakes of PCI requirement 10 (part 2)

By Dimitri McKay

In my previous post, I talked about the number three PCI requirement mistake, which is thinking that PCI is about check boxes, not about security and accountability. You can read more about that here:

This is the second part. The “Post Audit Follow Through”.

Once the audit is over, there’s still work to do. Logging all new devices, reading daily reports and following up on report results is just as important as the initial audit. You must monitor those reports every day! You must be aware of those deviations from norm, those thresholds being crossed, those anomalies being detected. It’s time to dig deeper!

Let me give you an example. I had a customer who over the course of 6 months had every server on his network fail two logons in a row every day. Prior to setting up his log management tools, he had NO visibility of it. None. What had been causing this event was a dictionary attack, and the crafty hacker knew that 3 logon failures = account lockout. By attempting twice per day for each machine, he was able to stay under the radar, not lock out any accounts, and continue the silent attack.

By reviewing the alerts, by reviewing the reports, by doing due diligence you’ll have visibility into these sorts of events.

The job of a security engineer is a continuous path. There is no finish line. The audit isn’t going to be the end, but rather the starting point. The audit is going to help you identify what is up to par and what needs work. From there, you now have another path to travel.

Stay tuned for the final piece, the Top 3 Mistakes of PCI Requirement 10.


Posted January 15, 2009 in Compliance | Permalink | Comments (0)

« December 2008 | Main | February 2009 »

Top three PCI compliance mistakes of Requirement 10

By Dimitri McKay

As an SE for LogLogic, I talk PCI (the payment card industry’s PCI-DSS) several days a week. I talk about requirement 10, I talk about retention requirements, I talk about evidencing log management. Out of all the common industry mandates and government compliance requirements, PCI exists as the one with the sharpest teeth. PCI can affect the purse by issuing fines, or raising the card swipe rate percentage.

With that, I’d like to talk quickly about the three most common PCI compliance mistakes of Requirement 10. This will hopefully aid in alleviating your headache from auditors, the headache of upper management and the headache of the Payment Card Industry.

Number 3: PCI Compliance isn’t about check boxes, it’s about security and accountability:

PCI Compliance isn’t about pleasing auditors and going through the list to mark yourself compliant. Sure, that's part of it, but the reason PCI exists is to secure your business from threat, secure your business from breach, secure your business from outside intruders. I’ve seen pre-sale customers run through a proof of concept of a log-management tool just to get through an audit. They then return the tool, immediately dropping Requirement 10, and dropping out of compliance. I found this to be absolutely insane. Here’s why.

We had a customer who was a high profile target. They had all the toys: the SIEM, segregated networks, tons of security, IDS/IPS, etc. Well, they were breached. Somehow, some way the attacker got in, got to their DB, and pulled a ton of account records: name, address, social, credit cards, etc. Now, in a situation like this, the customer had NO idea what was affected. Were his routers/switches/firewalls compromised? Their policies? Were their IOS’s re-written with a backdoor? The security officer had no idea. How about the servers on that network? Rooted? Compromised? Who knows? The scope of the breach was completely unknown. To identify a scope, most businesses would need to bring in a forensics team, go through a mountain of log-data, and identify the scope. However, as a LogLogic customer, they were able to go back and scope the breach based on the attacker's IP address(es) immediately. In a couple hours they knew where, when and how the attacker gained access. They knew what machines were affected, they knew what database was breached, they knew what user data was stolen. Log data to the rescue.

This is what PCI is about. It’s about security, it’s about doing to the best of your ability what you can to secure your network and, if you are breached, it’s about having the evidence to track down the hacker and, if able, prosecute them. Not just about check boxes, or passing audits.

Posted January 11, 2009 in Compliance | Permalink | Comments (0)

Visit loglogic.com

I ♥ Logs

Subscribe to this blog’s feed RSS

January 2010
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Categories
Archives
Blogroll
Blogroll
Compliance
Good Reading
LogLogic
LogLogic Partners
Sites We Watch