Securosis

Research

Understanding and Selecting a Database Activity Monitoring Solution: Part 5, Advanced Features

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

Share:
Read Post

Prepping for RSA

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 Woe er, 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… Share:

Share:
Read Post

Separation of Duties vs. Concept of Least Privilege

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 straightforward. 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. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Least Privilege, Security, Separation of Duties Share:

Share:
Read Post

Uh Oh- Time To Take Cold Boot Encryption Attacks VERY Seriously

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. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Cold Boot, Encryption, CanSecWest, Vulnerability Share:

Share:
Read Post

Webcast: Database Security; Preventative Controls for Separation of Duties

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. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Database Security, Oracle, Separation of Duties, Webcast Share:

Share:
Read Post

Webcast: Web Application Vulnerability Management with Core Security

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… Share:

Share:
Read Post

Fighting Back Against Fraud; A True Story Part 2

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. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Cybercrime, Fraud Share:

Share:
Read Post

Fighting Back Against Fraud; A True Story

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… < p style=”text-align:right;font-size:10px;”>Technorati Tags: Fraud Share:

Share:
Read Post

Network Security Podcast, Episode 98 Up

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. < p style=”text-align:right;font-size:10px;”>Technorati Tags: Network Security Podcast Share:

Share:
Read Post

Another PCI Suggestion

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. < p style=”text-align:right;font-size:10px;”>Technorati Tags: PCI Share:

Share:
Read Post

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.