Research

The forensics use case we discussed previously is about taking a look at something that already happened. You presume the data is already lost, the horse is out of the barn, and Pandora’s Box is open. But what if we tried to look at some of these additional data types in terms of making security alerts better, with the clear goal of reducing the window between exploit and detection: reacting faster? Can we leverage something like network full packet capture to learn sooner when something is amiss and to improve security? Yes, but this presents many of the same challenges as using log-based analysis to detect what is going on. You still need to know what you are looking for, and an analysis engine that can not only correlate behavior across multiple types of logs, but also analyze a massive amount of network traffic for signs of attack. So when we made the point in Collection and Analysis that these Network Security Analysis platforms need to be better SIEMs than a SIEM, this is what we were talking about. Pattern Matching and Correlation Assuming that you are collecting some of these additional data sources, the next step is to turn said data into actionable information, which means some kind of alerting and correlation. We need to be careful when using the ‘C’ word (correlation), given the nightmare most organizations have when they try to correlate data on SIEM platforms. Unfortunately the job doesn’t get any easier when extending the data types to include network traffic, network flow records, etc. So we continue to advocate a realistic and incremental approach to analysis. Much of this approach was presented (in gory detail) in our Network Security Operations Quant project. Identify high-value data: This is key – you probably cannot collect from every network, nor should you. So figure out the highest profile targets and starting with them. Build a realistic threat model: Next put on your hacker hat and build a threat model for how you’d attack that high value data. It won’t be comprehensive but that’s okay. You need to start somewhere. Figure out how you would attack the data if you needed to. Enumerate those threats in the tool: With the threat models, design rules to trigger based on the specific attacks you are looking for. Refine the rules and thresholds: The only thing we can know for certain is that your rules will be wrong. So you will go through a tuning process to hone in on the types of attacks you are looking for. Wash, rinse, repeat: Add another target or threat and build more rules as above. With the additional traffic analysis you can look for specific attacks. Whether it’s looking for known malware (which we will talk about in the next post), traffic destined for a known command and control network, or tracking a buffer overflow targeted at an application residing in the DMZ, you get a lot more precision in refining rules to identify what you are looking for. Done correctly this reduces false positives and helps to zero in on specific attacks. Of course the magic words are “done correctly”. It is essential to build the rule base incrementally – test the rules and keep refining the alerting thresholds – especially given the more granular attacks you can look for. Baselining The other key aspect of leveraging this broader data collection capability is understanding how baselines change from what you may be used to with SIEM. Using logs (or more likely NetFlow), you can get a feel for what is normal behavior and use that to kickstart your rule building. Basically, you assume what is happening when you first implement the system is what should be happening, and alert if something varies too far from that normal. That’s not actually a safe assumption but you need to start somewhere. As with correlation this process is incremental. Your baselines will be wrong when you start, and you adjust them over time based with operational experience responding to alerts. But the most important step is the start, and baselines help to get things going. Revisiting the Scenario Getting back to the scenario presented in the Forensics use case, how would some of this more pseudo-real-time analysis help reduce the window between attack and detection? To recap that scenario briefly, a friend at the FBI informed you that some of your customer data showed up as part of a cybercrime investigation. Of course by the time you get that call it is too late. The forensic analysis revealed an injection attack enabled by faulty field validation on a public-facing web app. If you were looking at network full packet capture, you might find that attack by creating a rule to look for executables entered into the form fields of POST transactions, or some other characteristic signature of the attack. Since you are capturing the traffic on the key database segment, you could establish a content rule looking for content strings you know are important (as a poor man’s DLP), and alert when you see that type of data being sent anywhere but the application servers that should have access to it. You could also, for instance, set up alerts on seeing an encrypted RAR file on an egress network path. There are multiple places you could detect the attack if you know what to look for. Of course that example is contrived and depends on your ability to predict the future, figuring out the vectors before the attack hits. But at lot of this discipline is based on a basic concept: “Fool me once, shame on you. Fool me twice, shame on me.” Once you have seen this kind of attack – especially if it succeeds – make sure it doesn’t work again. It’s a bit of solving yesterday’s problems tomorrow, but many security attacks use very similar tactics. So if you can enumerate a specific attack vector based on what you saw, there is an excellent

Secure USB devices – ain’t they great? They offer us the ability to bring trusted devices into insecure networks, and perform trusted operations on untrusted computers. If I could drink out of one, maybe it would be the holy grail. Services like cryptographic key management, identity certificates and mutual authentication, sensitive document storage, and a pr0nsafe web browser platform. But over the last year, as I look at the mobile computing space – the place where people will want to use secure USB features – the more I think the secure USB market is in trouble. How many of you connect a USB stick to your Droid phone? How about your iPad? My point is that when you carry your smart device with you, you are unlikely to carry a secure USB device with you as well. The security services mentioned above are necessary, but there has been little integration of these functions into the devices we carry. USB hardware does offer some security advantages, but USB sticks are largely part of the laptop model (era) of mobile computing, which is being marginalized by smart phones. Secure on-line banking, go-anywhere data security, and “The Key to the Cloud” are clever marketing slogans. Each attempts to reposition the technology to gain user preference – and fails. USB sticks are going the way of the zip drive and the CD – the need remains but they are rapidly being marginalized by more convenient media. That’s really the key: the security functions are strategic but the medium is tactical. So where does the Secure USB market segment go? It should go with the users are: embrace the new platforms. And smart device users should look for these security features embedded in their mobile platforms. Just because the media is fading does not mean the security features aren’t just as important as we move on to the next big thing. These things all tend to cycles, but the current strong fashion is to get “an app for that” rather than carry another device. Lack of strong authenication won’t make users carry and use laptops rather than phones. It is unclear why USB vendors have been so slow to react, but they need to untie themselves from their fading medium to support user demand. I am not saying secure USB is dead, but saying the vendors need to provide their core value on today’s relevant platforms. Share:

Most organizations don’t really learn about the limitations of event logs, until forensic investigators hold up their hands and explain they know what happened, but aren’t really sure how. Huh? How could that happen? It’s pretty simple: logs are a backward-looking indicator. They can help you piece together what happened, but you can only infer how. In a forensic investigation inferring anything is suboptimal. You want to know, especially given the needs to isolate the root cause of the attack and to establish remediations to ensure it doesn’t happen again. So we need to look at additional data sources to fill in gaps in what the logs tell you. Let’s take a look at a simplified scenario to illuminate the issues. We’ll look at the scenario both from the standpoint of a log-only analysis and then with a few other data sources added. For a more detailed incident response scenario, check out our React Faster and Better paper. The Forensic Limitations of Logs It’s the call you never want to get. The Special Agent on the other end of the line called to give you a heads-up: they found some of your customer data as part of another investigation into some cyber-crime activity that helps fund a domestic terrorist ring. Normally the Feds aren’t interested in giving you a heads-up until their investigation is done, but you have a relationship with this agent from your work together in the local InfraGard chapter. So he did you a huge favor. The first thing you need to do is figure out what was lost and how. To the logs! You aren’t sure how it happened, but you see some strange log records indicating changes on a application server in the DMZ. Given the nature of the data your agent friend passed along, you check the logs on the database server where that data resides as well. Interestingly enough, you find a gap in the logs on the database server, where your system collected no log records for a five-minute period a few days ago. You aren’t sure exactly what happened, but you know with reasonable certainty that something happened. And it probably wasn’t good. Now you work backwards and isolate the additional systems compromised as the attackers made their way through the infrastructure to reach their target. It’s pretty resource intensive, but by searching in the log manager you can isolate devices with gaps in their logs during the window you identified. The attackers were pretty effective, taking advantage of unpatched vulnerabilities (Damn, Ops!) and covering their tracks by turning off logging where necessary. At this point you know the attack path, and at least part of what was stolen, thanks to the FBI. Beyond that you are blind. So what can you do to make sure you aren’t similarly suprised somewhere down the line? You can set the logging system to alert if you don’t get any log records from critical assets in any 2-minute period. Again, this isn’t perfect and will result in a bunch more alerts, but at least you’ll know something is amiss before the FBI calls. With only log data you can identify what was attacked but probably not how the attack happened. Forensics Driven by Broader Data Let’s take a look at an alternative scenario with a few other data sources such as full network packet capture, network flow records, and configuration files. Of course it is still a bad day when you get the call from your pal the Special Agent. Of course Applied Network Security Analysis cannot magically make you omniscient, but how you investigate breaches changes. You still start with the logs on the perimeter server and identify the device that served as the attacker’s initial foothold. But you’ve implemented the Full Packet Capture Sandwich architecture described in the last post, so you are capturing the network traffic in your DMZ. You proceed to the network analysis console (using the full packet capture stream) and search all the traffic to and from the compromised server. Most sessions to that server are typical – standard application traffic. But you find some reconnaissance, and then something pretty strange: an executable injected into the server via faulty field validation on the web app (Damn, Developers!). Okay, this confirms the first point of exploit. Next we go to the target (keeping in mind what data was compromised) and do a similar analysis. Again, with our full packet capture sandwich in place, we captured traffic to/from the database server as well. As in the log-only scenario, we pinpoint the time period when logging was turned off, then perform a search in our analysis console to figure out what happened during that 5-minute period on that segment. Yep, a privileged account turned off logging on the database server and added an admin account to the database. Awesome. Using that account, the attacker dumped the database table and moved the data to a staging server elsewhere on your network. Now you know which data was taken, but how? You aren’t capturing all the traffic on your network (infeasible), so you have some blind spots, but with your additional data sources you are able to pinpoint the attack path. The NetFlow records coming from the compromised database server show the path to the staging server. The configuration records from the staging server indicate what executables were installed, which enabled the attacker to package and encrypt the payload for exfiltration. Further analysis of the NetFlow data shows the exfiltration, presumably to yet another staging server on another compromised network elsewhere. It’s not perfect, because you are figuring out what already happened. But now you can get back to your FBI buddy with a lot more information about what tactics the attacker used, and maybe even evidence that might be helpful in prosecution. Can’t Everyone Get Along? Clearly this is a simplified scenario that perfectly demonstrates the need to collect additional data sources to isolate the root cause and attack path of any

I really enjoyed Marco Arment’s I finally cracked it post, both because he captured the essence of Apple TV here and now, and because his views on media – as a consumer – are exactly in line with mine. Calling DVRs “a bad hack” is spot-on. I went through this process 7 years ago when I got rid of television. I could not accept a 5 minute American Idol segment in the middle of the 30 minute Fox ‘news’ broadcast. Nor the other 200 channels of crap surrounding the three channels I wanted. At the time people thought I was nuts, but now I run into people (okay – only a handful) who have pulled the plug on the broadcast media of cable and satellite. Most people are still frustrated with me when they say “Hey, did you see SuperJunk this weekend?” and I say “No, I don’t get television.” They mutter something like ‘Luddite’ and wonder off. Don’t get me wrong, I have a television. A very nice one in fact, but I have been calling it a ‘monitor’ for the last few years because it’s not attached to broadcast media. But not getting broadcast television does not make me a Luddite – quite to the contrary, I am waiting for the future. I am waiting for the day when I can get the rest of the content I want just as I get streaming Netflix today. And it’s not just the content, but the user experience as well. I don’t want to be boxed into some bizarre set of rules the content owners think I should follow. I don’t want half-baked DRM systems or advertising thrust at me – and believe me, this is what many of the other streaming boxes are trying to do. I don’t want to interact with a content provider because I am not interested – it was a bad idea proven foul a long time ago. Just let me watch what I want to watch when I want to watch it. Not so hard. But I wanted to comment on Marco’s point about Apple and their ability to be disruptive. My guess is that Apple TV will go fully a la carte: Show by show, game by game, movie by movie. But the major difference is we would get first run content, not just stuff from 2004. Somebody told me the other day that HBO stands for “Hey, Beastmaster’s On!”, which is how some of the streaming services and many of the movie channels feel. SOS/DD. The long tail of the legacy television market. The major gap in today’s streaming is first run programming. All I really want that I don’t have today is the Daily Show and… the National Football League (queue Monday Night Football soundtrack). And that’s the point where Mr. Arment’s analysis and mine diverge – the NFL. I agree that whatever Apple offers will likely be disruptive because the technology will simplify how we watch, rather than tiptoeing around legacy businesses and perverse contracts. But today there is only one game in town: the NFL. That’s why all those people pay $60 (in many cases it’s closer to $120) a month – to watch football. You placate kids with DVDs; you subscribe to cable for football! Just about every man I know, and 30% of the women, want to watch their NFL home team on Sunday. It’s the last remaining reason people still pay for cable or satellite in this economy. Make no mistake – the NFL is the 600 lb. gorilla of television. They currently hold sway over every cable and satellite network in the US. And the NFL makes a ridiculous amount of money because networks must pay princely sums for NFL games to be in the market. Which is why the distributors are so persnickety about not having NFL games on the Internet. Why else would they twist the arm of the federal government to shut down a guy relaying NFL games onto the Internet? (Thanks a ton for that one you a-holes – metropolitan areas broadcast over-the-air for free but it’s illegal to stream? WTF?) Nobody broadcasts live games over the Internet!?! Why not?!? The NFL could do it directly – they are already set up with “Game Pass” and “Game Rewind” – but likely can’t because fat network contracts prohibit it. Someone would need to spend the $$$ to get Internet distribution rights. Someone should, because there is huge demand, but there are only a handful of firms which could ante up a billion dollars to compete with DirecTV. But when this finally happens it will be seriously disruptive. Cable boxes will be (gleefully) dumped. Satellite providers will actually have competition, forcing them to alter their contacts and rates, and go back to delivering quality picture. ISPs will be pressured to actually deliver the bandwidth they claim to be selling. Consumers will get what they want at lower cost and with greater convenience. Networks will scramble to license the rest of their content to any streaming service provider they can, increasing content availability and pushing prices lower. If Apple wants to be disruptive, they will stream NFL games over the Internet on demand. If they can get rights to broadcast NFL for a reasonable price, they win. The company that gets the NFL for streaming wins. If Apple doesn’t, bet that Amazon will. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on SaaS security services. Adrian quoted in SearchSOA. Compliance Holds Up Los Angeles Google Apps Deployment. Mike plays master of the obvious. Ask the auditor before you commit to something that might be blocked by compliance. Duh! Favorite Securosis Posts Adrian Lane: A Kick-Ass Cloud Database Security Automation Example. And most IaaS cloud providers have the hooks to do most of this today. You can even script the removal of base database utilities you don’t want. Granted, you still have to set permissions on data and users, but the

It all started with a simple tweet from The Mogull, which succinctly summed up a lot of the meat grinder of high tech marketing. You see the industry is based on upgrades and refreshes, largely driven by planned obsolescence. Let’s just look at Microsoft Word. I haven’t really used any new functionality since Office 2003. You? They have overhauled the UI and added some cloudiness (which they call Office Live), but it’s really moving deck chairs around. A word processor is a word processor for 95% of the folks out there. Rich was reacting to the constant barrage of “next generation” this and next generation that we are constantly get pitched, while most organizations can’t even make the current generation work. It is becoming rare to survive a vendor briefing without hearing about how their product is NextGen (only their product, of course). This is rampant in the spaces I cover: network and endpoint security. Who hasn’t heard of a next generation firewall? Now we have next generation IPS, and it’s just a matter of time before we see next generation TBD promising to make security easy. We know how this movie ends. To be fair, some innovations really are next generation, and they make a difference to leading edge companies that can take advantage of them. I mentioned NGFW in a tongue-in-cheek fashion, but the reality is that moving away from ports and protocols, to application awareness, is fundamentally different and can be better. But only if the customer can take advantage and build these new application-oriented policies. A NGFW is no better than a CGFW (current generation firewall) without a next-generation rule base to take advantage of the additional capabilities. I guess what I find most frustrating about the rush to the next generation is the arbitrary nature of what is called “next generation”. Our pals at the Big G (that’s Gartner for you Securosis n00bs) recently published a note on NGIPS (next generation IPS), which you can get from SourceFire (behind a reg wall). As the SourceFire folks kindly point out, they have offered many of these so-called next generation functions since 2003 – they just couldn’t tell a coherent story about it. Can something over 6 years old really be next generation? So next generation monikers are crap. Driven by backwards-looking indicators – like most big IT research. SourceFire did a crappy job of communicating why their IPS was different back in the day, and it wasn’t until some other companies (notably the NGFW folks) started offing application-aware IPS capabilities that the infinite wisdom in Stamford decided it was suddenly time for NGIPS. And now this will start a vendor hump-a-thon where every other IPS vendor (yeah, the two left) will need to spin their positioning to say ‘NGIPS’ a lot. Whether they really do NGIPS is besides the point. You can’t let the truth get in way of a marketing campaign, can you? What’s lost in all the NextGen quicksand? What customers need. Most folks don’t need a next generation word processor, but one shows up every 2-3 years like clockwork. Our infrastructure security markets are falling in line with this model. Do we need NextGen key management? NextGen endpoint security? NextGen application protection? Given how well the current generation works, I’d say yes. But here’s the problem. I know this is largely a marketing exercise, so let’s be clear about what we are looking for. Something that works. Call it what you want, but if it’s the same old crap that we couldn’t use before, rebranded as next generation… I’m not interested. And no one else will be either. Share:

Yesterday I was in Vegas to participate in a panel at IBM’s Information on Demand Conference. To my amusement and frustration, I was already in Vegas that weekend, drove 4.5 hours home to Phoenix on Sunday, then flew back Monday evening (4 hours door to door). The panel was on database security in the cloud, and at one point I came up with an example to show how this sh*t is seriously different than how we do security today. The example below would be nearly impossible in a non-cloud environment. It’s fictional, but there are no technical obstacles to implementing it right now. There is, however, one limitation I will mention at the end. Imagine a world where you have a robust internal cloud to support business units in a large enterprise. This is in contrast to current environments where, if a business unit wants an application or database resource: they submit a request, things are approved (maybe), then physical or virtual assets are acquired, configured, and assigned. You are one of those forward-thinking orgs which stood up your private cloud with a self-service portal where approved managers can dynamically provision a pre-established set of resources. No, this probably isn’t how most of you use the cloud today, but it will be. Now imagine that some of these resource stacks include databases. You are, obviously, concerned with the security and compliance of these databases. This is the sort of thing that used to constantly bite you in the ass, as teams ranging from developers to sub-departments installed their own stuff, loaded sensitive data, and then failed to secure it. But you now sleep soundly at night because… When the user requests the application stack, all operating systems and software are automatically patched to current levels using mandatory installation scripts. The installation scripts also configure the resources to a secure-by-default state, doing things like inserting user credentials, locking down ports, setting appropriate file permissions, configuring application defaults, and so on. You can even automate service account management and cross-link them between application components (heck, we do this in the CCSK Plus training class). All application components instantiate themselves in different, locked-down network security groups. Only required internal ports are open. This can be much more granular and restrictive than current application stacks which require physical hardware to protect. When the database spins up it registers itself with your Database Activity Monitoring (DAM) and assessment tools via their APIs. The DAM tool performs an initial database vulnerability assessment and registers the database for future scans. (Other stack components do similar things, but we’re focusing on the database for this example). Thanks to those cloud APIs, it knows where to look for the database and who created it, and the necessary firewall ports are opened. After the initial DAM scan is complete and passed, the DAM tool makes an API call to the cloud’s network controller to open up any additional ports needed for internal access. Depending on the script, this may be restricted to subnets, individual IPs, and so on. Similar processes are followed for the application and web server components and their various security tools (vulnerability assessment, asset registration, configuration management, etc.). Assuming everything is hunky dory, any last required ports to access the application can be opened up. The user won’t pick this – it will be handled automatically via API and policy scripts. The DAM tool will have installed its monitoring agent at initial launch. The agent connects back to the DAM server and activity is now monitored (including administrative SQL queries). On a specified schedule, the database is scanned for ongoing configuration compliance and vulnerabilities. It is also scanned for sensitive data, using the content discovery feature of your DAM tool and policies tied to the type of application stack deployed and the business unit assigned. If it isn’t supposed to have credit card numbers, but they start appearing, security gets an alert. Think about this for a moment – today people try to spin stuff up all over the place and it’s nearly impossible to find, never mind configure securely. In the example above we completely automate the configuration and security of the application stack (including the database) on a dynamic basis using APIs and policy scripts. The database spins up with secure settings in a secure network; it is centrally registered, actively monitored, and scanned for both problems and sensitive (read ‘regulated’) data on an ongoing basis. Today’s limitation is that very few security tools, by default, support the automation I described above. But things like initialization scripts and dynamic network management via APIs are fundamental to all cloud platforms. Cool, eh? And heck, I’m probably missing a bunch of things Share:

In the introduction to our Applied Network Security Analysis series, we talked about monitoring everything and the limitations of a log-centric data collection approach, in our battle to improve security operational processes. Now let’s dig in a little deeper and understand what kind of data collection foundation makes sense, given the types of analysis we need to deal with our adversaries. Let’s define the critical data types for our analysis. First are the foundational elements, which were covered ad nauseum in our Monitoring Up the Stack paper. These include event logs from the network, security, databases, and applications. We have already pointed out that log data is not enough, but you still need it. The logs provide a historical view of what happened, as well as the basis for the rule base needed for actionable alerts. Next we’ll want to add additional data commonly used by SIEM devices – that includes network flows, configuration data, and some identity information. These additional data types provide increased context to detect patterns of potential badness. But this is not enough – we need to look beyond these data types for more detail. Full Packet Capture As we wrote in the React Faster and Better paper: One emerging advanced monitoring capability – the most interesting to us – is full packet capture. These devices basically capture all traffic on a given network segment. Why? The only way you can really piece together exactly what happened is to use the actual traffic. In a forensic investigation this is absolutely crucial, providing detail you cannot get from log records. Going back to a concept we call the Data Breach Triangle, you need three components for a real breach: an attack vector, something to steal, and a way to exfiltrate it. It’s impossible to stop all potential attacks, and you can’t simply delete all your data, so we advocate heavy perimeter egress filtering and monitoring, to (hopefully) prevent valuable data from escaping your network. So why is having the packet stream so important? It is a critical facet of heavy perimeter monitoring. The full stream can provide a smoking gun for an actual breach, showing whether data actually left the organization, and which data. If you look at ingress traffic, the network capture enables you to pinpoint the specific attack vector(s) as well. We will discuss both these use cases, and more, in additional detail later in this series, but for now it’s enough to say that full network packet capture data is the cornerstone of Applied Network Security Analysis. Intelligence and Context Two additional data sources bear mentioning: reputation and malware. Both these data types provide extra context to understand what is happening on your networks and are invaluable for refining alerts. Reputation: Wouldn’t it be great if you knew some devices and/or destinations were up to no good? If you could infer some intent from just an IP address or other identifying characteristics? Well you can, at least a bit. By leveraging some of the services that aggregate data on command and control networks, and on other known bad actors, you can refine your alerts and optimize your packet capture based on behavior, not just on luck. Reputation made a huge difference in both email and web security, and we expect a similar impact on more general network security. This data helps focus monitoring and investigation on areas likely to cause problems. Malware samples: A log file won’t tell you that a packet carried a payload with known malware. But samples of known malware are invaluable when scrutinizing traffic as it enters the network, before it has a chance to do any damage. Of course nothing is foolproof, but we are trying to get smarter and optimize our efforts. Recognizing something that looks bad as it enters the network would provide a substantial jump for blocking malware. Especially compared to other folks, whose game is all about cleaning up the messes after they fail to block it. We will dive into how to leverage these data types by walking through the actual use cases where this data pays dividends later in the series. But for now our point is that more data is better than less, and without building a foundation of data collection analysis is likely futile. Digesting Massive Amounts of Data The challenge of collecting and analyzing a multi-gigabit network stream is significant, and each vendor is likely to have its own special sauce to collect, index, and analyze the data stream in real time. We won’t get into specific technologies or approaches – after all, beauty is in the eye of the beholder – but there are a couple things to look for: Collection Integrity: A network packet capture system that drops packets isn’t very useful, so the first and foremost requirement is the ability to collect network traffic at your speeds. Given that you are looking to use this data for investigation, it is also important to maintain traffic integrity to prove packets weren’t dropped. Purpose-built data store: Unfortunately MySQL won’t get it done as a data store. The rate of insertions required to deal with 10gbps traffic demand something built specifically that purpose. Again, there will be lots of puffery about this data store or that one. Your objective is simply to ensure the platform or product you choose will scale to your needs. High-speed indexing: Once you get the data into the store you need to make sense of it. This is where indexing and deriving metadata become critical. Remember this has to happen at wire speeds, is likely to involve identifying applications (like an application-aware firewall or IDS/IPS), and enriching the data with geolocation and/or identity information. Scalable storage: Capturing high-speed network traffic demands a lot of storage. And we mean a lot. So you need to calibrate onboard storage against archiving approaches, optimizing the amount of storage on the capture devices based on the number of days of traffic to keep. Keep in mind that the metadata

Flat Stanley has it pretty good. If you have elementary school age kids, you probably know all about him. Flat Stanley is a cute story about a kid who gets flattened, and then spends most of the book trying to regain his natural form. Many teachers have kids do a Flat Stanley project, where they color a picture and send it to a friend or relative. The recipient then takes pictures of Flat Stanley doing something from their daily routine and writes a letter to send back with the photo. The kids learn a bit about someone else, and they have to read the letter. Win/win. Last week, XX2 gave me her Flat Stanley to take on a trip. I started at SecTor CA up in Toronto, so Flat Stanley got to take a picture by the CN Tower. While I’m on this topic, I need to shout out for the folks behind SecTor CA. It’s a great conference, with great speakers and a great community. If you are in or around Toronto, you need to get to SecTor CA. They even invited Stanley to get up on stage and talk about his curious life (picture below). The audience was enthralled. Evidently Stanley doesn’t make too many high-profile keynote speeches, so XX2’s teacher showed the class the picture. It was a big hit. Turns out the wonderful Arlen clan also has lots of experience with Flat Stanley. So we traded stories of what they did with Flat Stanley. They even heard tales of Flat Stanley going to London and attending the Royal Wedding. That dude gets around. Then I took Flat Stanley on my annual golf trip with the boys. Why not? That keynote speech business is hard work, and Stanley needed a bit of R&R. I’m pretty sure I should have had Stanley hit a few drives for me since – he couldn’t have done worse. Let’s just say I should stick to writing and pontificating. I did get some good photos of Stanley in the golf cart, and putting in a birdie. Stanley is a child, so I put him to bed before the evening festivities. And that’s all I’ll say about that. But all told, Flat Stanley has a pretty good gig. He travels around the world and experiences interesting stuff. Which, when I come to think about it, is kind of what I do. And I’m not flat either. That would be a win for me. -Mike Photo credits: Mike Rothman on his rockin’ iPhone 4S Incite 4 U Getting Binary on Risk Assessment: If there is one thing I can say with a high level of confidence, it’s that math guys will defend math. Alex Hutton doesn’t disappoint, as he critiques Ben Sapiro’s Binary Risk Assessment thought balloon (presented at SecTor CA). Alex is balanced but objects to calling Ben’s approach risk assessment, instead he calls it a way to assess vulnerability severity. Vernacular and semantics – the tools of lawyers and, seemingly, math guys. What I like about Ben’s approach is that it’s simple and quick. Most real risk assessment methods are neither. And given the need to prioritize actions in real time, it’s better to be quick than right to 5 decimal places. So I like Ben’s approach – read it and use it. That doesn’t mean you shouldn’t still push toward true risk quantification (if you have that kind of threshold for pain), but understand that there is a time and place for each approach. – MR NoSQL on NoCloud: I am not surprised that Oracle launched a NoSQL database at OpenWorld. NoSQL threatens the relational DB status quo with cheaper, more agile capabilities, with greater data capacity. What does surprise me is their release of NoSQL on a big-ass big data appliance. So new, yet so old school. This is especially interesting in light of the news that Oracle’s acquiring RightNow while talkin’ smack about how Salesforce.com is the roach motel of cloud. I think some of this puffery is because Oracle was late to adopt the cloud, much as Microsoft was with the Internet, but they are certainly making a concerted cloudy push now. Regardless, the big appliance deployment could really work. It’s anti-cloud, but wears like a comfortable old jacket. And it’s so self-contained that it’s generic storage, like a SAN, and you’ll likely be able to outsource security and maintenance and just worry about pushing data. I think this will be very popular for small enterprises who just need to get work done without worrying too much about new technologies. – AL Security small guy syndrome: I think I have ranted about this one before, but one of my pet peeves is people in security talking about how “We have to educate the users/developers/business/whatever.” Because, more often than not, when they say ‘educate’ they really mean ‘indoctrinate’. To me it always sounds like small guy syndrome – you know, the kid who has all the answers if the stupid world would just listen! Chris Eng pokes at a recent presentation that sounds like it falls into this category. It isn’t that security shouldn’t talk to development or try to work with them, but we will never succeed if we don’t understand their priorities in the context of our own bias. Even then their priorities will never completely align with ours because we have different jobs. So my advice is try to work with developers, but don’t expect to change them – instead assume you will be adding whatever else you need to improve the end product (secure code, right?). – RM Cyber-insurance: Win or Futility? We are starting to see better analyses of whether cyber-insurance makes sense. I have been pretty negative because it wasn’t clear to me that the underwriting was based on any real loss data – which means the environment has been rife Ouija board pricing. There is a good primer on NetworkWorld explaining how to maybe use cyber-insurance effectively, and I have seen a

Back in 2007 we – it was actually just Rich back then – published Understanding and Selecting Database Activity Monitoring – the first in-depth examination of what was then a relatively new security technology. That paper is, and remains, the definitive guide for DAM, but a lot has happened in the past 4 years. The products – and the vendors who sell them – have all changed. The reasons customers bought four years ago are not the reasons they buy today. Furthermore, the advanced features of 2007 are now part of the baseline. Given the technology’s increased popularity and maturity, it is time to take a fresh look at Database Activity Monitoring – reassessing the technology, use cases, and market drivers. So we are launching Understanding and Selecting a Database Activity Monitoring Solution Version 2.0. We will update the original content to reflect our current research, and share what we hear now from customers. We’ll include some of the original content that remains pertinent, but largely rewrite the supporting trends, use cases, and deployment models, to reflect today’s market. A huge proportion of the original paper was influenced by vendors and the user community. I know because I commented on every post during development – a year or so before I joined the company. As with that first version, in accordance with our Totally Transparent Research process, we encourage user and vendors to comment during this series. It does change the resulting paper, for the better, and really helps the community understand what’s great and what needs improvement. All pertinent comments will be open for public review, including any discussion on Twitter, which we will reflect here. The areas we know need updating are: Architecture & Deployment: Basic architectures remain constant, but hardware-based deployments are slowly giving way to software and virtual appliances. Data collection capabilities have evolved to provide new options to capture events, and inline use has become commonplace. DAM “in the Cloud” requires a fresh examination of platforms to see who has really modified their products and who simply markets their products are “Cloud Ready”. Analytics: Content and query structure analysis now go hand in hand with rule and attribute based analysis. SQL injection remains a top problem but there are new methods to detect and block these attacks. Blocking: When the original paper was written blocking was a dangerous proposition. With better analytics and varied deployment models, and much-improved integration to react to ongoing threats, blocking is being adopted widely for critical databases. Platform Bundles: DAM is seldom used standalone – instead it is typically bundled with other technologies to address broad security, compliance, and operational challenges far beyond the scope of our 2007 paper. We will cover a handful of the ways DAM is bundled with other technologies to address more inclusive demands. SIEM, WAF, and masking are all commonly used in conjunction with assessment, auditing, and user identity management. Trends: When it comes to compliance, data is data – relational or otherwise. The current trend is for DAM to be applied to many non-relational sources, using the same analytics while casting a wider net for sensitive information housed in different formats. Adoption of File Activity Monitoring, particularly in concert with user and database monitoring, is growing. DAM for data warehouse platforms has been a recent development, which we expect to continue, along with DAM for non-relational databases (NoSQL). Use cases and market drivers: DAM struggled for years, as users and vendors sought to explain it and justify budget allocations. Compliance has been a major factor in its success, but we now see the technology being used beyond basic security and compliance – even playing a role in performance management. In our next post we will delve into architecture and deployment model changes – and discuss how this changes performance, scalability, and real-time analysis. Share:

My wife and I are pretty big Jimmy Buffett fans. I first got hooked way back in high school, working as a lifeguard. The summer of my freshman year in college I went with a group of friends down to the Orange Bowl, and we snuck off for a day trip to Key West and a short visit to the very first Margaritaville. I really got hooked when I was deep into paramedic school. In our program you worked or attended classes 80+ hours a week – bouncing around between a bunch of hospitals, fire stations, and ambulance bays throughout the entire Denver Metro area. In the middle of winter I survived all those hours on the road thanks only to a Buffett tape serenading me with sweet visions of beaches and beer. Later, it didn’t hurt that I met my wife at a Buffett show. While he tours consistently year after year, he only hits Phoenix every 2-3 years now. So when we didn’t see our home town on the schedule, a bunch of us decided to get tickets to the Vegas show. Then he added the Denver show. I lived in Boulder for 16 years and still have a big chunk of friends there who convinced me to pop over for the show – especially since I hadn’t seen some of them in 2 years, and Buffett hadn’t played Denver in 8. Then he added the Phoenix show. And that, my friends, is how I managed to sign up for three Jimmy Buffett shows, in three different cities, in three different states in one week. One of which is tonight, and I have to go assemble our new portable grill. So… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Quiet week. Guess even media whores need some time off. Favorite Securosis Posts Adrian Lane: Tokenization Guidance: Merchant Advice. Rich: Applied Network Security Analysis. Because Mike writes much better section headings than I do. Other Securosis Posts Incite 10/19/2011: The Inquisition. Database Security Market Sizing and Guesstimation. Favorite Outside Posts Adrian Lane: Secret iOS business; what you don’t know about your apps. There are scarier threats to all mobile platforms than what’s mentioned here, but the post does a great job of underscoring that security is only as good as the app developer. And if they want to spy on you… they will. Mike Rothman: The forever recession (and the coming revolution). Seth Godin is the philosopher king of the Internet age. This is a great post about how every recession gives way to unbounded growth. If you can figure out how to deal with the next thing. Read this. Read his stuff. Adapt. Pepper: Georgia Tech Turns iPhone into spiPhone. Fortunately not suitable for even half-decent passwords, but a very clever hack to eavesdrop via an accelerometer. Should work on Android phones too – for now. Rich: Michael Winslow gets the Led out. I know this has nothing to do with security. And I know it’s been all over Twitter. But it’s still the awesomest thing I’ve seen in a while. Research Reports and Presentations Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. Top News and Posts Venafi’s take on Duqu. W32.Duqu: The Precursor to the Next Stuxnet. Supposedly from the Stuxnet authors. New Jersey Transit Embraces Google Wallet. And so it begins. Oracle publishes major patch release. Many database and Java patches. Cloud Security in Datacenter Terms. Google embraces HTTPS. Social Security kept silent about private data breach. We missed this last week. APT – The Plain Hard Truth. RSA blames breach on two hacker clans working for China. I didn’t get to see the talk, and so am still slightly skeptical, but expect more info to come out at RSA this year. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Patrick, in response to Database Security Market Sizing and Guesstimation. This post raises an interesting issue for me – And that is, what is the purpose of measurement and estimation? Of anything, really – a market, an effect, a potential risk or loss magnitude? In my mind, it’s a matter of accuracy vs precision, bounded by the contextual requirements of how much reduction in uncertainty is required by the subject/decision at hand. Single point estimates, like the one referenced above – are usually not as informative as we might wish. A range, or even an estimated probability distribution, is much more useful, and not that hard to do quickly. How big is the database security market? I don’t know – but that doesn’t mean I couldn’t come up with something useful if I needed to make a decision. The key here is useful, not precise – just about measurement carries some uncertainty. Share: