Spotting That DAM(n) Fake

I awoke at 2:30am to a 90-degree bedroom. Getting up to discover why the air conditioning was not working, I found a dog pooped on my couch. Neatly in the corner – perhaps hoping I would not notice. Depositing the aforementioned ‘present’ in the garbage can, I almost stepped on both a bark scorpion and a millipede – eyeing one another suspiciously – just outside the garage door. After a while, air conditioning on and couch thoroughly scrubbed, I returned to bed only to find my wife had laid claim to all the covers and pillows. Since I was up, what the heck – I made coffee, ran the laundry, and baked muffins while the sun came up. I must admit I started work today with a jaundiced eye, and a strong desire to share some of my annoyance publicly. As part of some research work I am doing, I was looking at the breadth of functions from a couple different vendors in different security markets. In the process, I noticed many firms have decided Database Activity Monitoring (DAM) is sexy as hell, and are advertising that capability as a core part of their various value propositions. The only problem is that many of the vendors I reviewed don’t actually offer DAM. I went back to my briefing notes and, sure enough, what’s advertised does not match actual functionality. Imagine that! A vendor jumping on a hot market with some vapor. Today I thought at least someone should benefit from my sour mood, so I want to share my quick and dirty tips on how to spot fake DAM. First, as a reminder, here is the definition of DAM that Rich came up with 5 years ago: Database Activity Monitors capture and record, at a minimum, all Structured Query Language (SQL) activity in real time or near real time, including database administrator activity, across multiple database platforms; and can generate alerts on policy violations. So how do you spot a fake? If the product does not have the option of a kernel agent, memory scanner, or some equivalent way to collect all SQL activity – either on the server or inside the database – the product is not DAM. If the product does not store queries – along with their response codes – for a minimum of 30 days – the product is not DAM. If the product is blocking activity without understanding the FROM clause, the WHERE clause, or several query and metadata specific attributes, the product is not DAM. If the vendor claims ‘deep packet inspection’ is equivalent to DAM, they are wrong. That’s not DAM either. Do us a favor and call them on it. They probably aren’t even doing deep packet inspection, but that’s a different problem. IDS, IPS, DLP, Netflow analysis, and other technologies can provide a subset of the DAM analysis capabilities, but they are not DAM. Use these four checks to see who is telling you the truth. Remember, we are just talking about the basics here – not the more advanced and esoteric features that real DAM vendors have included over the years. Now I am off to the DMV – I figure that’s just the place for my current demeanor to fit right in. Share:

Read Post

Incite 8/24/2011: Living Binary

The Boss constantly reminds me I have no middle ground. On/Off. Black/White. No dimmer. No gray (besides on my head). Moderation is non-existent, which is why I never tried hard drugs. I knew myself well enough (even at a young age) to know it wouldn’t end well. Sure I’d be the best presenter in the crack den, but that would have impeded my plans for world domination. It’s not just the mind altering stuff where I don’t do moderation. Let’s talk food. I became a vegetarian about 3 years ago, mostly because I couldn’t eat just five chicken wings. I’d eat 20 and then feel like crap. As much as my logical brain would say ‘STOP’, my monkey brain would plow through the tray of wings. I want to live to be 90, so then my kids can change my diapers. So I needed to figure out a method to deal with this lack of control. I figured it would be easier to go cold turkey. No red meat, no chicken (or turkey), no pork. Done. I can shut it off. I just can’t moderate. A few weeks ago I needed to take some action. My weight was creeping up, mostly because I couldn’t work out with the intensity that used to keep things under control, because of injuries. I don’t eat terribly, but when we run out of veggies and fruit, I’ve been known to knock back some chips. OK, a bag of chips. Or a couple bowls of cereal. Or a few mini-bagels. It’s that moderation thing again. I’ve been hearing many of my friends talk about this Primal thing for a while. Stories of how they feel a lot better. They certainly look better. I’m used to eating a big ass salad most days, and a lot of fruit/veggies. It can’t be that hard, right? Best of all, it plays into my binary nature. If I just stop eating bread and most starchy carbs, that can work. Now I don’t have to worry about digging into the bag of chips or grabbing 3-4 mini-bagels. That switch is off. Binary. It’s actually gone pretty well. I haven’t dropped a ton of weight, but I adjusted pretty well. No headaches, no severe hunger pains. I’m not as draconian as I am with the meat. I don’t go nuts (no pun intended) if there are breaded do-dads on a salad. And I’ll eat potatoes, just not frequently. Maybe twice a week. Mostly with an omelet when I’m on the road (instead of 3 bagels). Living binary may not be for everyone, but it works for me. I know I have got little control. Rather than trying to figure out how to gain control, I put myself in situations where I can be successful. Is this forever? Who knows? But it’s OK for now, so I’ll go with it. -Mike Photo credits: “Binary cupcakes” originally uploaded by alicetragedy Incite 4 U Slowing down your denial: I’m not sure where it came from, but I love the idea of slowing down to speed up. Many times when things feel out of control, if I just take a step back and focus, I start moving things forward. Seems the denial of service attackers take a similar approach. Kick ass post here from Rybolov about slow denial of service (SDoS). Of course, our friend RSnake was one of the first (if not the first) guys to talk about slow HTTP attacks, so I’m glad he’s on our side. The post tells you what you need to know about this attack, delving into its devastating nature, the challenges of detecting it, and how to defend against it. It’s much harder to track, compared to brute force DDoS, so it seems likely we’ll see a lot more SDoS. Good thing Rybolov doesn’t miss the opportunity to reiterate that throwing a bunch of servers and bandwidth at SDoS may be one of the only mitigations we have. And good thing Akamai has a lot of both, eh? – MR Blood Donation: Having been to China a few times I’m pretty sure they have some of my biometric information. Just like in the US, they take a photo and fingerprint on entry to the country. While I don’t consider China evil by any means, they are definitely a bit more of a rival to most Western nations (and pretty much any democracy). So I’m amused at this project to collect DNA sequences for people with high intelligence. Now I think this is a real research project, but they do report to the government in the end. Is anything at risk? Probably not for any of us. Is it amusing, in light of everything else going on these days? Certainly! – RM You get the check… Cellarix is creating a mobile payment system. All you have to do is provide Cellarix (or more likely their credit card processing partner) with your credit card number – the merchant’s POS system essentially calls your phone to confirm payment. Think of it as a reverse Point-of-Sale system. I saw something almost identical to this demonstrated by Ericsson in 1997 – payment was handled simply by dialing the phone number on the front of a vending machine, in order to get train tickets or a pack of cigarettes. The idea was that you could leverage your phone provider’s existing payment relationships – at the end of the month, your phone bill would include your purchases. The obvious vulnerability is the device itself. If you lose your phone, you could have your bank account or credit card drained almost instantly, which is awesome. The Cellarix model is not much different, with the merchant calling you for verification. But nowdays losing the phone is just one of many threats – MITM and rogue apps could just as easily fake authorization by controlling that second factor. Most people can’t help leaking email credentials at Starbucks – is there any reason to believe your payment data would

Read Post

Fact-based Network Security: Outcomes and Operational Data

In our first post on Fact-based Network Security, we talked about the need to make decisions based on data, as opposed to instinct. Then we went in search of the context to know what’s important, because in order to prioritize effectively you need to know what presents the most value to your organization. Now let’s dig a little deeper into the next step, which is determining the operational metrics on which to base decisions. But security metrics can be a slippery slope. First let’s draw a distinction between outcome-based metrics and operational metrics. Outcomes are the issues central to business performance, and as such are both visible and important to senior management. Examples may include uptime/availability, incidents, disclosures, etc. Basically, outcomes are the end results of your efforts. Where you are trying to get to, or stay away from (for negative outcomes). We recommend you start by establishing some goals for improvement of these outcomes. This gives you an idea of what you are trying to achieve and defines success. To illustrate this we can examine availability as an outcome – it’s never bad to improve availability of key business systems. Of course we are simplifying a bit – availability consists of more than just security. But we can think about availability in the context of security, and count issues/downtimes due to security problems. Obviously many types of activities impact availability. Device configuration changes can cause downtime. So can vulnerabilities that result in successful attacks. Don’t forget application problems that may cause performance anomalies. Traffic spikes (perhaps resulting from a DDoS) can also take down business systems. Even seemingly harmless changes to a routing table can open up an attack path from external networks. That’s just scratching the surface. The good news is that you can leverage operational data to isolate the root causes of these issues. What kinds of operational data do we need? Configuration data: Tracking configurations of network and security devices can yield important information about attack paths through your network and/or exploitable services running on these devices. Change information: Understanding when changes and/or patches take place helps isolate when devices need to be checked or scanned again to ensure new issues have not been not introduced. Vulnerabilities: Figuring out the soft spots of any device can yield valuable information about possible attacks. Network traffic: Keeping track of who is communicating with whom can help baseline an environment, which is important for detecting anomalous traffic and deciding whether it requires investigation. Obviously as you go deeper into the data center, applications, and even endpoints, there is much more operational data that can be gathered and analyzed. But remember the goal. You need to answer the core question of “what to do first,” establishing priorities among a infinite number of possible activities. We want to focus efforts on the activities that will yield the biggest favorable impact on security posture. A simple structure for this comes from the Securosis Data Breach Triangle. In order to have a breach, you need data that someone wants, an exploit to expose that data, and an egress path to exfiltrate it. If you break any leg of the triangle, you prevent a successful breach. Data (Attack Path) If the attacker can’t see the data, they can’t steal it, right? So we can focus some of our efforts on ensuring direct attack paths don’t make it easy for an attacker to access the data they want. Since you know your most critical business systems and their associated assets, you can watch to make sure attack paths don’t develop which expose this data. How? Start with proper network segmentation to separate important data from unauthorized people, systems, and applications. Then constantly monitor your network and security devices to ensure attack paths don’t put your systems at risk. Operational data such as router and firewall configurations is a key source for this analysis. You can also leverage network maps and ongoing discovery activities to check for new paths. Any time there is a change to a firewall setting or a network device, revisit your attack path analysis. That way you ensure there’s no ripple effect from a change that opens an exposure. Think of it as regression testing for network changes. Given the complexity of most enterprise-class networks, this isn’t something you can do manually, and it’s most effective in a visual context. Yes, in this case a picture is worth a million log records. A class of analysis tools has emerged to address this. Some look at firewall and network configurations to build and display a topology of your network. These tools constantly discover new devices and keep the topology up to date. We also see evolution of automated penetration testing tools, which focus on continuously trying to find attack paths to critical data, without requiring a human operator. There is no lack of technology to help model and track attack paths. Regardless of the technology you select to analyze the attack paths, this is key to understanding what to fix first. If a direct path to important data results from a configuration change, you know what to do (roll it back!). Likewise, if a rogue access point emerges on a critical network (with a direct path to important data), you need to get rid of it. These are the kind of activities that make an impact and need to be prioritized. Exploit Even if an attack path exists, it may not be practical to exploit the target device. This is where server configuration, as well as patch and vulnerability monitoring, are very useful. Changes that happen outside of authorized maintenance windows tend to be suspicious, especially on devices either containing or providing access to important data. Likewise, the presence of an exploitable critical vulnerability should bubble to the top of the priority list. Again, if there is no attack path to the vulnerable device, the priority of fixing the issue is reduced. But overall you must track what needs to be fixed on

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.