We’re going to be finishing the series off this week, in large part so I can get it compiled together into a whitepaper with SANS, sponsored by Imperva, Guardium, and Sentrigo, before the big RSA show. I won’t be sleeping much this week as I compile and re-write the posts, add additional content that didn’t make it into the blog, create some images, and toss it back and forth with my editor. What? You didn’t think all I did was cut and paste this stuff, did you?

For review, you can look up our previous entries here:

Part 1
Part 2
Part 3
Part 4

What do I mean by advanced features? In our other posts we focused on the core solution set, but most of the products have quite a bit more to offer. There’s no way we can cover everything, and I don’t intend this to be an advertisement for any particular solution set, but there are a few major features we see appearing in more than one product. I’m going to highlight a few I think are particularly interesting and worthy of consideration in the selection process.

Content Discovery

As much as we like to think we know our databases, the reality is we really don’t always know what’s inside them. Many of our systems grew organically over the years, some are managed by external consultants or application vendors, and others find sensitive data stored in unusual locations. To counter these problems, some database activity monitoring solutions are adding content discovery features similar to DLP. These tools allow you to set content-based policies to identify the use of things like credit card numbers in the database, even if they aren’t located where you expect. Discovery tools crawl through registered databases, looking for sensitive content based on policies, and generate alerts for sensitive content in new locations. For example, you could create a policy to identify any credit card number in any database, and generate a report for PCI compliance. The tools can run on a scheduled basis so you can perform ongoing assessments, rather than combing through everything by hand every time an auditor comes knocking.

Some tools allow you to then build policies based on the discovery results. Instead of manually identifying every field with Social Security Numbers and building a different protection policy for each, you create a single policy that generates an alert every time an administrator runs a SELECT query on any field which matches the SSN rule. As the system grows and changes over time, the discovery component identifies the fields matching the protected content, and automatically applies the policy.

We’re also starting to see DAM tools that monitor live queries for sensitive data. Policies are then freed from being tied to specific fields, and can generate alerts or perform enforcement actions based on the result set. For example, a policy could generate an alert any time a query result contains a credit card number, no matter what columns were referenced in the query.

Connection Pooled User Identification

One of the more difficult problems we face in database security is the sometimes arbitrary distinction between databases and applications. Rather than looking at them as a single system, we break out database and application design and administration, and try to apply controls in each without understanding the state of the other. This is readily apparent in the connection pooling problem. Connection pooling is a technique where we connect large applications to large databases using a single shared connection running under a single database user account. Unless the application was carefully designed, all queries come from that single user account (e.g., APP_USR) and we have no way, at the database level, to identify the user performing the transaction. This creates a level of abstraction which makes it difficult, if not impossible, to monitor specific user activity and apply user policies at the database level.

An advanced feature of some database activity monitoring solutions allows them to track and correlate individual query activity back to the application user. This typically involves integration or monitoring at the application level. You now know which database transactions were performed by which application users, which is extremely valuable for both audit and security reasons.

Blocking and Enforcement

Today, most users just deploy database activity monitoring to audit and alert on user activity, but many of the tools are perfectly capable of enforcing preventative policies. Enforcement happens at either the network layer or on the database server itself, depending on the product architecture.

Enforcement policies tend to fall into two categories. The first, similar to many of the monitoring policies we’ve described, are focused on user behaviors like viewing or changing sensitive records. Rather than just alerting after a DBA pulls every account number out of the system, you can block the query. The second is focused on database exploits; similar to an intrusion prevention solution, the system blocks queries matching signatures for known attacks like SQL injection.

The nature and level of blocking will vary based on the architecture of the DAM tool. Integrated agent solutions may offer features like transaction rollback, while network tools block the traffic from hitting the DBMS in the first place. Digging into the specific architectures and benefits is beyond the scope of this post.

Application Activity Monitoring

Databases rarely exist in a vacuum; more often than not they are an extension of applications, yet we tend to look at them as isolated components. Application Activity Monitoring adds the ability to watch application activity, not just the database queries that result. This information can be correlated between the application and the database to gain a clear picture of just how data is being used at both levels, and identify anomalies which may indicate a security or compliance failure.

Since application design and platforms vary even more than databases, products can’t cover every custom application in your environment. We see vendors focusing on major custom application platforms, like SAP and Oracle, and monitoring web-based application activity.

Pre-Configured Application Policies

With or without application monitoring, some DAM solutions come with pre-configured policies for common applications (e.g., PeopleSoft). Although you’ll need to tune them to account for any application customization, they can jump-start the policy building process and save you from manually building all your compliance and security policies.

Pre-Configured Compliance Policies

Although no tool will make you compliant out of the box, pre-configured compliance policies for common platforms give you a head start on the process, especially when you don’t know where to start. Most vendors hire or partner with auditors to help them build their compliance policy and reporting packages for common regulations like SOX and PCI-DSS that frequently impact databases.

Change Management

Although many organizations have rigorous change management policies for the database platform and underlying system, far fewer enforce change management at the query level (which is invisible to traditional change management tools). An advanced feature of certain DAM solutions integrates with change management tools for closed-looped tracking of query-level changes. The requested change is approved in the change management system and a ticket number issued. The DBA enters that ticket number as part of their session, and all database changes (even to individual field updates) are recorded and correlated back to the original change ticket.

Vulnerability Assessment

Vulnerability assessment in databases is a topic worthy of its own series of posts (wink wink), but is sometimes offered as a feature (usually at additional cost) of a DAM solution. Database vulnerability assessment tools look deeper than patch levels, down to specific configurations and even an analysis of user entitlements. Some tools integrate the results of VA to DAM policies to generate alerts or block activity that’s suspected of targeting an identified vulnerability. This is a huge area on its own, and is beyond the scope of this post.

This list is far from exhaustive; I’ve tried to highlight some of the more common advanced features you’ll see through the selection process. I’m sure I’ve missed a few and I encourage those of you on the vendor side to add them in the comments, just avoid too much marketing fluff or I’ll filter the comment. If they’re good (and clearly a big feature starting to appear in multiple products) they might even make it into the white paper.

This post concludes our coverage of DAM features. By now you should have a good idea of how the technology works and the different options available to you. In the final post (probably tomorrow, considering my deadlines) we’ll dig into how to run a successful product selection process.

Technorati Tags: Application and Database Monitoring and Protection, Database Activity Monitoring, Tools, Tutorial

There’s only one week left until RSA and it’s looking to be a doozy this year. For me that is, not really sure about the entire information security market.

I wanted to highlight a couple of things. First, of course, is the Security Blogger’s Meetup. This once private event is now open to any security blogger out there, although if you haven’t signed up by now it’s a little too late. Martin and I will be recording and streaming live audio and video from the event, so stand by for more on that.

I’m giving a few talks at RSA, both as a conference speaker and at some outside events. The first is Tuesday morning where I’m presenting on “Understanding and Preventing Data Breaches” at a breakfast sponsored by Vericept. I update this presentation every time I give it, so even if you’ve seen it before there will be some new content in there. I believe that event is totally booked out already.

Twice each day (at 11 and 2 on Wednesday/Thursday, still TBD for Tuesday) I’ll be giving a short overview on data breaches and encryption at the WinMagic booth. The title is, “Encryption and Data Breaches, Why, When, and How” although we’re still tweaking it. Encryption is really misused a lot more than we like to admit, so I’ll use some statistics and analysis to help provide direct implementation guidance. As always, it’s my regular objective content you read here day to day, no matter where I’m presenting it.

I’m speaking in two track sessions this year, both panels. The first, on Tuesday is “Analyst Anarchy: Wall Street Mashes it up With the Pundits” in Red Room 301 at 1:30 PM. It’s a few industry analysts and myself on a panel moderated by a Wall Street analyst. I did this last year, and never know what to expect; hopefully we’ll have some hard hitting questions to answer.

The second session, Thursday morning in the same room, is with many of my colleagues from the Security Catalyst Community, including Big Bad Mike Rothman, Securosis Contributor David Mortman, Ron Woerner, and my Network Security Podcast co-host Martin McKeay. Here’s the description:

Avoiding the Security “Groundhog Day”

It’s deja vu all over again. As an industry, we’re rolling out widgets to solve the same old problems - and it’s not working. In this session, a panel of experts debates the history of security for clues on building tomorrow’s defenses. Together, we’ll learn from the past how to build a safer tomorrow. Given the stakes, no security practitioner can afford to make the same mistakes again.

We plan on killing some sacred cows- the description might seem bland, but no way will Rothman and I let you fall asleep.

Other than that I’ll be at all the usual social events. My schedule is pretty much booked up with clients, but feel free to track me down anyway, especially if you like to pay for drinks (you know us cheap-ass consultants). Email is best, rmogull@securosis.com. I do have some time reserved to wander the show floor and see what’s going on out there that I don’t know about.

It should be fun, and I’ll be posting as much as I can. Martin and I will be posting short podcasts every day up at NetSecPodcast.com with our summary of events.

Hope to see you there…

Reports are flying in over Twitter about the latest Cold Boot attack demonstrations at CanSecWest. Looks like the folks over at Intelguardians are showing practical exploits using different techniques, including USB devices and iPods.

We’ve talked about this before, and it’s time to start asking your encryption vendors for their response.

I’m definitely heading up to Vancouver next year; there’s a lot of great stuff coming out of the show.

Technorati Tags: Cold Boot, Encryption, CanSecWest, Vulnerability

When I’m preparing for a webcast I usually send the sponsor a copy of the presentation so they can prepare their section. While I’m a huge stickler for keeping my content objective, they also usually provide feedback. Some of it I have to ignore, since I don’t endorse products and won’t “tune” content in ways that break objectivity (I’m quickly worthless if I do that), but I often get good general feedback ranging from spelling errors to legitimate content mistakes.

In prepping for the Oracle webcast on Friday, they caught a big gaping hole that I think is becoming a common mistake (at least, I hope I’m not the only one making it). It’s one of those things I know, but when running through the presentation it’s clear I drifted off track and muddled a couple of concepts.

Although the presentation is about preventative controls for separation of duties, many of my recommendations were really about least privilege. When I talk with people around the industry I’m not the only one who’s started to blur the lines between them.

According to Wikipedia (yes, validated with other sources), separation of duties is defined as:

“Separation of duties (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.”

Pretty straight forward.

But we often say things along the lines of, “you need to monitor administrators for separation of duties”. Well, when you get down to it that isn’t really SoD since the one user can still technically complete an entire task. We also talk about restricting what users have access to, which is clearly the concept of least privilege. Even auditors I’ve worked with make this mistake, so it isn’t just me.

So I don’t have to completely trash my presentation I’m using an informal term I call, “Real World SoD”. It’s a combination of detective controls, real SoD, and least privilege, Basically, we restrict any single individual from completing a task or having unfettered access without either preventative or detective controls.

Before you nail me in the comments, I’ll be the first to admit that this *is not* SoD, but for conversation and general discussions I think it’s reasonable to recognize that the common vernacular doesn’t completely match the true definition, and in some cases splitting hairs doesn’t do us any favors.

Just something to keep in mind. True SoD means splitting a task into parts, and we need to be clear about that; but I think it’s okay if we mess up sometimes and talk about multiple people also reviewing a task as a form of SoD. I *do* think we should be clearer about least privilege vs. SoD, but, again, I’m not going to lose sleep over it if we sometimes drift in our discussions as long as we have the controls in place.

Because that’s the really important part.

Technorati Tags: Least Privilege, Security, Separation of Duties

Yep, it’s all webcasts all the time for me this week. I wonder if I can get my own TV channel?

I’m pretty excited to do this one; I’m presenting Integrating Web Applications into Your Vulnerability Management Program with Core Security, the makers of Core Impact.

That’s right, folks, I actually know about something other than information-centric security and Macs.

This is going to be a bit of a different one designed to walk the line between the tactical and the strategic. I’ll start by talking about the major web application threats at a high level, then dig into the different ways you can manage web app vulnerabilities and link it into your broader vulnerability management program. We’re going to talk a lot about the interplay of different vulnerability scanning techniques and testing, including penetration testing (of course).

If you’re already deep into pen testing this will give you a broader context on how to link into enterprise-level programs. If you want to get a higher level overview of some of the web application issues and management techniques, you should walk away pretty happy.

I suppose I should go write it now. You can register here…

This Friday I’ll be giving another webcast with ZDNet/Oracle. This time we’re focusing in on preventative controls for separation of duties. The formal title is Enforcing Separation of Duties for Database and Security Administrators, and registration is open.

You may have noticed I’m spending a lot of time on this theme of crossing the lines between security and database administration. We’ve found that most security types aren’t the most experienced with databases, and DBAs, while perhaps technically proficient with aspects of database security, are still pretty limited when it comes to broader security skills.

The last webcast highlighted 5 important areas of database security and compliance, one of which was separation of duties. This presentation, and one in April, are digging deeper into the SoD problem. We’re going to start with preventative controls, ranging from access controls to advanced security features, and finish next month with monitoring/detective controls.

In both cases I’ll be on for about 30 minutes with the high level view, followed by the Oracle folks with more details on how to implement it in their systems.

Technorati Tags: Database Security, Oracle, Separation of Duties, Webcast

Yesterday, Jay shared with us his experience with eBay fraud and his attempts to work with law enforcement, Today, he takes matters (legally) into his own hands and… well, you’ll just have to read the story…

Now in between these phone calls I had been pursuing the email address the seller used. The address was a hotmail account. I figured if it’s a hotmail account then they must be using a web browser to read it. I crafted an email linking in a 1×1 transparent gif image hosted on my web server. Sure enough, within a day I had a log entry from a dial-up IP address in Georgia. I really wanted to find out who this person was so I crafted another one, this time with logging information maxed. I also tried to include tantalizing messages, “The good and bad thing about the internet is that people never really know who they are dealing with.” and “Yum, AOL users are my favorite” after one of the connections was through an AOL proxy. That last one must’ve hit their pride because I got a response bashing AOL and my lame attempts.

Throughout this time I continued to keep in touch with John in D.C. Once I had identified that most of the IP addresses centered on the same town in Georgia. He remembered that some of the purchases on his credit card were shipped to an address in Georgia. Sure enough the address was the same area as my IP addresses.

I didn’t want to give up on our justice system so I called the local police in Georgia. In spite of my efforts to educate them on computers, the internet and EBay, they thought I was insane. There was no amount of haggling, pleading or demanding that would get the long arm of the law to that address based on me calling.

Of course I kept my baiting emails going. I had sent seven unique image emails and by chance I had a window open watching the logs when the seventh popped up. I poked and prodded the host on that IP… windows PC, this time with an EarthLink branded browser dialed up through UU-Net (backbone provider, commonly resold). With my scans running, I got on the phone to UU-Net support, told them the person connected *right now* on *this IP* had committed internet fraud. Of course they couldn’t tell me anything, but they put the record into a ticket and gave me the ticket number. They said they would release it if they had a subpoena. I called the Georgia police back with this information and they still thought I was crazy.

I had gotten the address John had from the purchases in Georgia. Google told us it was a secluded family home outside of town nestled in the woods. I converted the address to a phone number and John called. Turned out there was a teenager at the address whose father was very interested in our tales. The father was able to correlate the appearance of items with John’s fraud activity and yes, the father did use EarthLink.

Should I have known better? Absolutely. Could I have done things differently? Sure. But I learned several valuable lessons as a result. The biggest lesson was that there was no big brother out there for me, there wasn’t an internet beat cop willing to help. They just don’t exist for small time crime. In the end my friend ended up getting his money back since they never cashed the cashier’s check (I think they waited 6 months) and the police in Georgia still thought I was nuts.

Technorati Tags: Cybercrime, Fraud

As part of our Debix contest (which is open for a few more days, if you want to enter) one reader relayed a great story on how he was scammed on eBay, and fought back. With a little ingenious detective work, he… well, I’ll just let Jay tell his own story (split into two parts)…

Back in 2001 I worked in a small ISP, it was so small that I represented half of the staff. I had offered to help a friend and his wife buy a laptop. Money was tight for them, so after doing some comparison shopping we decided to snipe a laptop off of EBay.

Shortly after winning an auction on a good laptop, the seller sent an email with a story about his brother having financial problems. It was written inconsistently and I couldn’t tell if this guy was lying or just a bad writer. The seller asked that I send a cashiers check to his brother in Indiana. I had gotten a great price on the laptop for my friend, so greed won out over logic but my warning lights were flashing. After a few more emails I sent the check and communication stopped. I waited for a few silent days before I went back to EBay. It turns out EBay had (and has) this great service where you can look up the account information of a seller. EBay provided the name and address of a person living just outside of Washington D.C. With the help of a reverse lookup, that led to a phone number which brought me to my first of many interesting phone calls.

I reached the seller, who we’ll call John, on the phone. After an awkward opening, I learned that John had been battling identify theft and had nothing to do with the EBay listing. He’s had fraudulent credit card charges from online purchases. He was just as interested in finding these folks as I was… I was stuck before I began.

I had two leads, the email address and the address in Indiana where I sent the check. I used Google maps to find the Indiana address. From the aerial photography I learned the address was at a large apartment complex. I called the local police in Indiana, “EBay?” “Yes, an online auction site.” “…On the internet?” They told me that they couldn’t help me since I was in Minneapolis and that I had to contact my local police department. I tried to get them to drive by the address and check out the mail boxes. They wouldn’t budge. My local police were a little more well versed, “Yeah, Haha, EBay again”. They told me that since I mailed the check to Indiana the crime really happened in Indiana and there wasn’t anything they could do. After a few rounds I was told I could show up at my local police to fill out a report but that they wouldn’t do anything but file it.

At this point I figured I could call the FBI because they’d have to help. I assumed since it was across state lines and it was a crime on the internet it must be against all sorts of laws I didn’t know about. Plus I’d been to DEFCON, I knew the feds were out there and watching. Turns out I was a little off about the feds. Once I found someone willing to talk about the case, I learned that fraud for the price a laptop was a little below the FBI radar by, oh, a 1000 percent or so.

Come back tomorrow, when Jay will share his efforts to track down the culprit…

Technorati Tags: Fraud

Make the list of who is compliant (and by default, not compliant) public. Allow consumers to decide if they want value security enough to do something about it.

Technorati Tags: PCI

The conference season is upon us. This week we discuss SOURCE in Boston and RSA with our guest, Jennifer Leggio. We spend a bit of time on the Hannaford breach and my Mac antivirus article.

As always, full show notes and the podcast are here.

Technorati Tags: Network Security Podcast