Research

Wrapping up our Software vs. Appliance series, I want to remind the audience this series was prompted by my desire to spotlight the FUD in Database Activity Monitoring sales processes. I have mentioned data collection as one of the topics Data collection matters. As much as we would like to say the deployment architecture is paramount for performance and effectiveness, data collection is crucial too, and we need to cover a couple of the competitive topics that get lumped into bake-offs. One of the most common marketing statements for DAM is, “We do not require agents.” This statement is technically correct, but it’s (deliberately) completely misleading. Let’s delve into the data collection issues that impact the Appliance vs. Software debate: Yes, We Have No Agents: No database activity monitor solution requires an agent. You’ll hear this from all of the vendors because they have to say that to address the competitive ‘poison pill’ left by the previous vendor. All but one DAM product can collect SQL and events without an agent. But the statement “We don’t require an agent” is just marketing. In practice all DAM products – software, hardware, and virtual – use agents. It’s just a fact. They do this because agents, of one form or another, are the only reliable way to make sure you get all important events. It’s how you get the whole picture and capture the activity you need for security and compliance. Nobody serious about compliance and/or security skips installing an agent on the target database. No Database Impact: So every DAM vendor has an agent, and you will use yours. It may collect SQL from the network stack by embedding into the OS; or by scanning memory; or by collecting trace, audit, or transaction logs. No vendor can credibly claim they have no impact on the target database. If they say this, they’re referring to the inadequate agent-less data collection option you don’t use. Sure, the vendor can provide a pure network traffic collection option to monitor for most external threats, but that model fails to collect critical events on the database platform. Don’t get me wrong – network capture is great for detecting a subset of security specific events, and it’s even preferable for your less-critical databases, but network scanning fails to satisfy compliance requirements. Agent-less deployments are common, but for cases where the database is a lower priority. It’s for those times you want some security controls, but it’s not worth the effort to enforce every policy all the time. Complete SQL Activity: DAM is focused on collection of database events. Agents that collect from the network protocol stack outside the database, or directly from the network, focus on raw unprocessed SQL statements in transit, before they get to the database. For many customers just getting the SQL statement is enough, but for most the result of the SQL statement is just as important. The number of rows returned, or whether the query failed, is essential information. Many network collectors do a good job of query collection, but poor result collection. In some cases they capture only the result code, unreliably – I have seen capture rates as low as 30% in live customer environments. For operations management and forensic security audits this is unacceptable, so you’ll need to verify during vendor review. Database Audit vs. Activity Audit: This is a personal pet peeve, something that bothers most DAM customers once they are aware of it. If your agents collects data from outside the database, you are auditing activity. If you collect data from inside the database you are auditing the database. It’s that simple. And this is a very important distinction for compliance, where you may need to know database state. It is considerably more difficult to collect from database memory, traces, transaction logs, and audit logs. Using these data sources has more performance impact – anywhere from a bit to much more impact than activity auditing, depending upon the database and the agent configuration. Worse, database auditing doesn’t always pick up the raw SQL statements. But these data sources are used because they give provide insight to the state of the database and transactions – multiple statements logically grouped together – that activity monitoring handles less well. Every DAM platform must address the same fundamental data collection issues, and no one is immune. There is no single ‘best’ method – every different option imposes its own tradeoffs. In the best case, your vendor provides multiple data collection options for you to choose from, and you can select the best fit for each deployment. Share:

If you read saw the press release title Symantec Introduces New Security Solutions to Counter Advanced Persistent Threats, what would you expect? Perhaps a detailed security monitoring solution, or maybe they bought a full packet capture solution, or perhaps really innovated with something interesting? Now what if told you that it’s actually about the latest version of Symantec’s endpoint protection product, with a management console for AV and DLP? You’d probably crap your pants from laughing so hard. I know that’s what I did, and my laundromat is not going to be happy. It seems someone within Symantec believes that you can stop an APT attack with a little dose of centrally managed AV and threat intelligence. If the NFL was in season right now, Symantec would get a personal foul for ridiculous use of APT. And then maybe another 15 yards for misdirection and hyperbole. To continue my horrible NFL metaphor, Symantec’s owners (shareholders) should lock the folks responsible for this crap announcement out of any marketing meetings, pending appeals that should take at least 4-5 years. From a disclosure standpoint, we got a briefing last week on Big Yellow’s Symantec Protection Center, its answer to McAfee’s Enterprise Policy Orchestrator (ePO). Basically the product is where ePO was about 5 years ago. It doesn’t even gather information from all of Symantec’s products. But why would that stop them from making outlandish claims about countering APT? Rich tore them into little pieces, politely rubbishing, in a variety of ways, their absurd claims that endpoint protection is an answer to stopping persistent attackers. He did it nicely. He told them they would lose all credibility with anyone who actually understands what an APT really is. The folks from Symantec thanked us for the candid feedback. Then they promptly ignored it. Ultimately their need to jump on a bandwagon outweighed their desire to have a shred of truth or credibility in an announcement. Sigh. Symantec contends that its “community and cloud-based reputation technology” blocks new and unknown threats missed by other security solutions. You know, like the Excel file that pwned RSA/EMC. AV definitely would have caught that, because another company would have been infected using the exact same malware, so the reputation system would kick into gear. Oh! Uh-oh… It seems Symantec cannot tell mass attacks from targeted 0-day attacks. So let me be crystal clear. You cannot stop a persistent attacker with AV. Not gonna happen. I wonder if anyone who actually does security for a living looked at these claims. As my boys on ESPN Sunday Countdown say, “Come on, man!” I’m sure this won’t make me many friends within Big Yellow. But I’m not too worried about that. If I were looking for friends I’d get a dog. I can only hope some astute security marketing person will learn that using APT in this context doesn’t help you sell products – it makes you look like an ass. And that’s all I have to say about that. Share:

Last weekend was a little oasis in the NFL desert that has been this offseason. It looked like there would be court-ordered peace, now maybe not so much. The draft reminded me of the possibilities of the new season, at least for a little while. One of the casualties of this non-offseason has been free agency. You know, where guys who have put in their time shop their services to the highest bidder. It’s not a lot different in the workforce. What most folks don’t realize is that everyone is a free agent. At all times. My buddy Amrit has evidently been liberated from his Big Blue shackles. Our contributor Dave Lewis also made the break. Both announced “Free Agent Status Engaged.” But to be clear, no one forced either guy to go to work at their current employer each day. They were not restricted (unless a heavy non-compete was in play) from taking a call from a recruiter and working for someone else. That would be my definition of free agency, anyway. But that mentality doesn’t appear to be common. When I first met Dave Shackleford, he was working for a reseller here in ATL. Then he moved over to the Center for Internet Security and we worked together on a project for them. I was a consultant, but he made it clear that he viewed himself as a consultant as well. In fact, regardless of whether he’s working on a contract or a full-time employee, Dave always thinks of himself as a consultant. Which is frickin’ brilliant. Why? Because viewing yourself as a consultant removes any sense of entitlement. Period. Consultants always have to prove their value. Every project, every deliverable, every day. When things get tight, the consultants are the first to go. Fail to execute flawlessly and add sufficient value, and you won’t be asked back. That kind of mindset seems useful regardless of job classification, right? Consultants also tend to be good at building relationships and finding champions. They get face time and are always looking for the next project to sink their teeth into. They actively manage their careers because no one else is going to do that for them. Again, that seems like a pretty good approach even inside an organization. Either you are managing your career or it is managing you. Which do you prefer? As happy as I am for Amrit and Dave as they embark on the next step of their journeys, I wish more folks would consider themselves perpetual free agents and start acting that way. And it’s not necessarily about always looking for a bigger and better deal. It’s about being in a position to choose your path, not have it chosen for you. -Mike Incite 4 U This is effective? I saw a piece on being an “effective security buyer” by Andreas Antonopoulos and I figured it was about managing the buying process. Like my eBook (PDF) on the topic. But no, it’s basically what to buy, and I have some issues with his guidance. Starting from the first, “never buy a single-purpose tool.” Huh? Never? I say you get leverage where you can, but there are some situations where you have to solve a single problem, with a single control. To say otherwise is naive. Andreas also talks about standards, which may or may not be useful depending on the maturity of what you are buying. Early products, to solve emerging problems, don’t know dick about standards. There are no standards at that point. And even if there are, I’d rather get stuff that works than something that plays with some arbitrary standard. But that’s just me. To be fair, there is some decent stuff in here, but as always: don’t believe everything you read. – MR Game over, man! Sony is on track to win the award for most fscked-up breach response of 2011. Any time you have to take your entire customer network down for two weeks, it’s bad. Telling 77 million customers their data might be compromised? Even worse. And 10 million of them might have had their credit cards compromised? Oh, joy. But barely revealing any information, and saying things like “back soon”? Heh. Apparently it’s all due to SQL injection? Well, I sure hope for their sake it was more complex than xp_cmdshell. But let’s be honest: there are some cultural issues at play here, and a breach of this magnitude is no fun for anyone. – RM ePurse chaser: eWallets are the easy part of mobile payment security. The wallet is the encrypted container where we store credit cards, coupons, signatures, and other means of identification. The trouble is in authenticating who is accessing the wallet. Every wallet has some form of an API to authenticate requests, and then return requested wallet contents to requesting applications. What worries me with the coming ‘eWallet revolution’ (which, for the record, started in 1996) is not the wallets themselves, but how financial institutions want to use them: direct access to point of sale devices through WiFi, Bluetooth, proximity cards, and other near-field technologies. Effectively, your phone becomes your ATM card. But rather than you putting your card into an ATM, near-field terminals communicate with your phone whenever you are ‘near’. See any problems with that? Ever had to replace your credit card because the number was ‘hacked’? Ever have to change your password because it was ‘snooped’ at Starbucks? Every near-field communication medium becomes a new attack vector. Every device you come into contact with has the ability to probe for weakness. The scope of possible damage escalates when you load arbitrary billing and payment to the phone. And what happens when the cell is cloned and your passwords are discovered through a – possibly unrelated – breach? It’s not that we don’t want financial capabilities on the phone – it’s that users need a one-to-one relationship with the bank to reduce exposure. – AL Mac users: BOO! A new version of scareware