Research

I have been debating (in my head) whether or not to write anything about what’s going on in Japan. This is about as serious as it gets, and there is far too much under-informed material out there. But the thing is I’m actually qualified to talk about disaster response. Heck, probably more qualified than I am to talk about information security. I have over 20 years experience in emergency services, including work as a firefighter (volunteer), paramedic (paid), ski patroller, mountain rescuer (over 10 years with Rocky Mountain Rescue), and various other paid and volunteer roles. Plus, for about 10 years now, I’ve been on a federal disaster and terrorism (WMD) response team. I’ve deployed on a bunch of exercises, as standby at a few national security events, and for real to Katrina and some smaller local disasters with other agencies. Yes, I’m trained to respond to something like what’s happening right now in Japan, and might deploy if it happened here in the US. The reason I’m being borderline-exploitative is that I know it’s human nature to ignore major risks until it’s too late, or for a brief period during and after a major event. I honestly expect that out of our thousands of readers, a handful of you might pay attention, and maybe one of you will do something to prepare. Words are cheap, so I figure it won’t hurt to try. I have far too many friends in disaster magnets like California who, at best, have a commercial earthquake bag lying around, and no real disaster plans whatsoever. Instead of a big post with all the disaster prep you should do (and yes, that I’ve done, despite living in a very stable area), I will focus on three quick items to give you a place to start. First: know your risks. Figure out what sorts of disasters (natural or human) are possible in your area. Phoenix is very stable, so I focus mostly on wildfires, flash floods, nuclear (there’s a plant outside the metro area, but weather could cause a panic), and biological (pandemic). Plus standard home disasters like fire (e.g., our smoke detector is linked to a call center/fire department). My disaster kits and plans focus around these, plus some personal plans around travel related incidents (I have an medical evac service for some trips). Second: know yourself. My disaster plans when I was single, without family or pets, and living in a condo in Boulder, were very different than the ones I have now. Back then it was, “grab my go bag and lock the door”, becauase I’d be involved in any major response. These days I have to plan for my family… and for being called away from my family if something big happens (the downside of being a fed). Have pets? Do you have enough pet carriers for all of them? And some spare food? Finally: layer your plan. I suggest you have a three-tiered plan: Eject: Your bugout plan. Something so serious hits that you get the hell out immediately. At best you’ll be able to grab 1 or 2 things. I’m not joking when I say this, but there are areas of this country where, if I lived in them, I’d bury supply caches along my escape routes. Heck, when I travel I usually have essentials and survival stuff ready to go in 30 seconds in case the hotel alarm goes off. Evac: You need to leave, but have more than a few minutes to put things together… or something (like a wildfire or radiological event) happens where you might need to go on sudden notice, but not have to drop everything. I have a larger list of items to take if I had 60-90 minutes to prep, which would go in a vehicle. There’s a much smaller list if I have to go on foot – we have 2 kids and cats to carry. Entrench: For blizzards, pandemics, etc.: whatever you might need to settle in. There are certain events I would previously have evacuated for but with a family I would now entrench for. What do you need, accounting for your climate, to survive where you are and for how long? The usual rule is 3 days of supplies, but that’s a load of crap. Realistically you should plan on a minimum of 7-10 days before getting help. We could make it 30-60 days if we had to, perhaps longer if needed – but the cats wouldn’t like it. For each option think about how you get out, what you take with you, what you leave behind, how you communicate and meet up (who gets the kids?), and how to secure what you’re leaving behind. I won’t lie – my plans aren’t perfect and there is still some gear I want on my list (like backup radio communications). But I’m in pretty good shape – especially with emergency rations and base supplies. A lot of it wasn’t in place until after I got back from Katrina and realized how important this all is. Long intro, and hopefully it helps at least one of you prep better. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading post on DB Security in the Cloud. Adrian’s Database Activity Monitoring Tips for Search Security. The Network Security Podcast, Episode 233. Rich quoted in Federal Computer Week on tokenization. Favorite Securosis Posts Mike Rothman: Table Stakes. Hopefully you are detecting a theme here at Securosis. Stop bitching and start doing. Rage and bitching don’t get much done. David Mortman: Technology Caste System. Adrian Lane: Greed Is (fill in the blank). Other Securosis Posts Updated RSA Breached – SecureID Affected. The Problem with Open Source in Commercial Software. Is the Virtual Desktop Hype Real?. Incite 3/16/2011: Random Act of Burrito. The CIO Role and Security. Security Counter Culture. FAM Introduction. Technical Architecture. Market Drivers, Business Justifications, and Use Cases. Network Security in the Age of Any Computing Quick Wins. Integration. Policy Granularity. Enforcement. Containing Access. Favorite Outside Posts Mike Rothman: REVEALED: Palantir Technologies. Not much is known about HBGary’s partner

I’ve been hearing a lot about Virtual Desktops lately (VDIs), and am struggling to figure out how interested you all really are in using them. For those of you who don’t track these things, a VDI is an application of virtualization where you run a bunch of desktop images on a central server, and employees or external users connect via secure clients from whatever system they have handy. From a security standpoint this can be pretty sweet. Depending on how you configure them, VDIs can be on-demand, non-persistent, and totally locked down. We can use all sorts of whitelisting and monitoring technologies to protect them – even the persistent ones. There are also implementations for deploying individual apps instead of entire desktops. And we can support access from anywhere, on any device. I use a version of this myself sometimes, when I spin up a virtual Windows instance on AWS to perform some research or testing I don’t want touching my local machine. Virtual desktops can be a good way to allow untrusted systems access to hardened resources, although you still need to worry about compromise of the endpoint leading to lost credentials and screen scraping/keyboard sniffing. But there are technologies (admittedly not perfect ones) to further reduce those risks. Some of the vendors I talk with on the security side expect to see broad adoption, but I’m not convinced. I can’t blame them – I do talk to plenty of security departments which are drooling over these things, and plenty of end user organizations which claim they’ll be all over them like a frat boy on a fire hydrant. My gut feeling, though, is that virtual desktop use will grow, but be constrained to particular scenarios where these things make sense. I know what you’re thinking, “no sh* Sherlock”, but we tend to cater to a … more discerning reader. I have spoken with both user and vendor organizations which expect widespread and pervasive deployment. So I need your opinions. Here are the scenarios I see: To support remote access. Probably ephemeral desktops. Different options for general users and IT admin. For guest/contractor/physician access to a limited subset of apps. This includes things like docs connecting to check lab results. Call centers and other untrusted internal users. As needed to support legacy apps on tablets. For users you want to let use unsupported hardware, but probably only for a subset of your apps. That covers a fair number of desktops, but only a fraction of what some other analyst types are calling for. What do you think? Are your companies really putting muscle behind virtual desktops on a large scale? I think I know the answer, but want a sanity check for my ego here. Thanks… Share:

This morning I published a column over at Dark Reading that kicked off some cool comments on Twitter. Since, you know, no one leaves blog comments anymore. The article is the upshot from various frustrations that have annoyed me lately. To be honest, I could have summarized the entire thing as “grow the f* up”. I’m just as tired of the “security is failing” garbage as I am with ridonkulous fake ROI models, our obsession with threats as the only important metric, and the inability of far too many security folks to recognize operational realities. Since I’m trying to be better about linking to major articles, here’s an excerpt: There’s been a lot of hand-wringing in the security community lately. Complaints about compliance, vendors and the industry, or the general short-sightedness of those we work for who define our programs based on the media and audit results. Now we whine about developers ignoring us, executives mandating support for iPads we can’t control (while we still use the patently-insecureable Windows XP) executives who don’t always agree with our priorities, or bad guys coming after us personally. We’re despondent over endless audit and assessment cycles, FUD, checklists, and half-baked products sold for fully-baked prices; with sales guys targeting our bosses to circumvent our veto. My response? Get over it. These are the table stakes folks, and if you aren’t up for the game here’s a dollar for the slot machines. Share:

Now that we have defined File Activity Monitoring it’s time to talk about why people are buying it, how it’s being used, and why you might want it. Market Drivers As I mentioned earlier the first time I saw FAM was when I dropped the acronym into the Data Security Lifecycle. Although some people were tossing the general idea around, there wasn’t a single product on the market. A few vendors were considering introducing something, but in conversations with users there clearly wasn’t market demand. This has changed dramatically over the past two years; due to a combination of indirect compliance needs, headline-driven security concerns, and gaps in existing security tools. Although the FAM market is completely nascent, interest is slowly growing as organizations look for better handles on their unstructured file repositories. We see three main market drivers: As an offshoot of compliance. Few regulations require continuous monitoring of user access to files, but quite a few require some level of audit of access control, particularly for sensitive files. As you’ll see later, most FAM tools also include entitlement assessment, and they monitor and clearly report on activity. We see some organizations consider FAM initially to help generate compliance reports, and later activate additional capabilities to improve security. Security concerns. The combination of APT-style attacks against sensitive data repositories, and headline-grabbing cases like Wikileaks, are driving clear interest in gaining control over file repositories. To increase visibility. Although few FAM deployments start with the goal of providing visibility into file usage, once a deployment starts it’s not uncommon use it to gain a better understanding of how files are used within the organization, even if this isn’t to meet a compliance or security need. FAM, like its cousin Database Activity Monitoring, typically starts as a smaller project to protect a highly sensitive repository and then grows to expand coverage as it proves its value. Since it isn’t generally required directly for compliance, we don’t expect the market to explode, but rather to grow steadily. Business Justifications If we turn around the market drivers, four key business justifications emerge for deployment of FAM: To meet a compliance obligation or reduce compliance costs. For example, to generate reports on who has access to sensitive information, or who accessed regulated files over a particular time period. To reduce the risk of major data breaches. While FAM can’t protect every file in the enterprise, it provides significant protection for the major file repositories that turn a self-constrained data breach into an unmitigated disaster. You’ll still lose files, but not necessarily the entire vault. To reduce file management costs. Even if you use document management systems, few tools provide as much insight into file usage as FAM. By tying usage, entitlements, and user/group activity to repositories and individual files; FAM enables robust analysis to support other document management initiatives such as consolidation. To support content discovery. Surprisingly; many content discovery tools (mostly Data Loss Prevention), and manual processes, struggle to identify file owners. FAM can use a combination of entitlement analysis and activity monitoring to help determine who owns each file. Example Use Cases By now you likely have a good idea how FAM can be used, but here are a few direct use cases: Company A deployed FAM to protect sensitive engineering documents from external attacks and insider abuse. They monitor the shared engineering file share and generate a security alert if more than 5 documents are accessed in less than 5 minutes; then block copying of the entire directory. A pharmaceutical company uses FAM to meet compliance requirements for drug studies. The tool generates a quarterly report of all access to study files and generates security alerts when IT administrators access files. Company C recently performed a large content discovery project to locate all regulated Personally Identifiable Information, but struggled to determine file owners. Their goal is to reduce sensitive data proliferation, but simple file permissions rarely indicate the file owner, which is needed before removing or consolidating data. With FAM they monitor the discovered files to determine the most common accessors – who are often the file owners. Company D has had problems with sales executives sucking down proprietary customer information before taking jobs with competitors. They use FAM to generate alerts based on both high-volume access and authorized users accessing older files they’ve never touched before. As you can see, the combination of tying users to activity, with the capability to generate alerts (or block) based on flexible use policies, makes FAM interesting. Imagine being able to kick off a security investigation based on a large amount of file access, or low-and-slow access by a service or administrative account. File Activity Monitoring vs. Data Loss Prevention The relationship between FAM and DLP is interesting. These two technologies are extremely complementary – so much that in one case (as of this writing) FAM is a feature of a DLP product – but they also achieve slightly different goals. The core value of DLP is its content analysis capabilities; the ability to dig into a file and understand the content inside. FAM, on the other hand, doesn’t necessarily need to know the contents of a file or repository to provide value. Certain access patterns themselves often indicate a security problem, and knowing the exact file contents isn’t always needed for compliance initiatives such as access auditing. FAM and DLP work extremely well together, but each provides plenty of value on its own. Share:

A new approach to an old problem One of the more pernicious problems in information security is allowing someone to perform something they are authorized to do, but catching when they do it in a potentially harmful way. For example, in most business environments it’s important to allow users broad access to sensitive information, but this exposes us to all sorts of data loss/leakage scenarios. We want to know when a sales executive crosses the line from accessing customer information as part of their job, to siphoning it for a competitor. In recent years we have adopted tools like Data Loss Prevention to help detect data leaks of defined information, and Database Activity Monitoring to expose deep database activity and potentially detect unusual activity. But despite these developments, one major blind spot remains: monitoring and protecting enterprise file repositories. Existing system and file logs rarely offer the level of detail needed to truly track activity, generally don’t correlate across multiple repository types, don’t tie users to roles/groups, and don’t support policy-based alerts. Even existing log management and Security Information and Event Management tools can’t provide this level of information. Four years ago when I initially developed the Data Security Lifecycle, I suggested to a technology called File Activity Monitoring. At the time I saw it as similar to Database Activity Monitoring, in that it would give us the same insight into file usage as DAM provides for database access. Although the technology didn’t yet exist it seemed like a very logical extension of DLP and DAM. Over the past two years the first FAM products have entered the market, and although market demand is nascent, numerous calls with a variety of organizations show that interest and awareness are growing. FAM addresses a problem many organizations are now starting to tackle, and the time is right to dig into the technology and learn what it provides, how it works, and what features to look for. Imagine having a tool to detect when an administrator suddenly copies the entire directory containing the latest engineering plans, or when a user with rights to a file outside their business unit accesses it for the first time in 3 years. Or imagine being able to hand an auditor a list of all access, by user, to patient record files. Those are merely a few of the potential uses for FAM. Defining FAM We define FAM as: Products that monitor and record all activity within designated file repositories at the user level, and generate alerts on policy violations. This leads to the key defining characteristics: Products are able to monitor a variety of file repositories, which include at minimum standard network file shares (SMB/CIFS). They may additionally support document management systems and other network file systems. Products are able to collect all activity, including file opens, transfers, saves, deletions, and additions. Activity can be recorded and centralized across multiple repositories with a single FAM installation (although multiple products may be required, depending on network topology). Recorded activity is correlated to users through directory integration, and the product should understand file entitlements and user/group/role relationships. Alerts can be generated based on policy violations, such as an unusual volume of activity by user or file/directory. Reports can be generated on activity for compliance and other needs. You might think much of this should be possible with DLP, but unlike DLP, File Activity Monitoring doesn’t require content analysis (although FAM may be part of, or integrated with, a DLP solution). FAM expands the data security arsenal by allowing us to understand how users interact with files, and identify issues even when we don’t know their contents. DLP, DAM, and FAM are all highly complementary. Through the rest of this series we will dig more into the use cases, technology, and selection criteria. Note – the rest of the posts in the series will appear in our Complete Feed. Share:

By now you have probably seen that the U.S. Department of Health and Human Services (HHS) fined Cignet healthcare a whopping $4.3M for, and I believe this is a legal term, being total egotistical assholes. (Because “willfull neglect” just doesn’t have a good ring to it). This is all over the security newsfeeds, despite it having nothing to do with security. It’s so egregious I suggest that, if any vendor puts this number in their sales presentation, you should simply stand up and walk out of the room. Don’t even bother to say anything – it’s better to leave them wondering. Where do I come up with this? The fine was due to Cignet pretty much telling HHS and a federal court to f* off when asked for materials to investigate some HIPAA complaints. To quote the ThreatPost article: Following patient complaints, repeated efforts by HHS to inquire about the missing health records were ignored by Cignet, as was a subpoena granted to HHS’s Office of Civil Rights ordering Cignet to produce the records or defend itself in any way. When the health care provider was ordered by a court to respond to the requests, it disgorged not just the patient records in question, but 59 boxes of original medical records to the U.S. Department of Justice, which included the records of 11 individuals listed in the Office of Civil Rights Subpoena, 30 other individuals who had complained about not receiving their medical records from Cignet, as well as records for 4,500 other individuals whose information was not requested by OCR. No IT. No security breach. No mention of security issues whatsoever. Just big boxes of paper and a bad attitude. Share:

In the relatively short period of time I have been on this planet, there are three time periods that really stand out to me as watershed moments in computing technology. The first was the dawn of the personal computing era that conveniently overlapped with the golden age of video arcades. For me it started the day my elementary school teacher introduced us to a Commodore PET, through the first Mac, and tapered off in the late 80s when home computers stopped being an anomaly. I don’t think the excitement I felt was merely the result of being an enthusiastic young male. ASCII porn didn’t really cut it, even for a 14 year old geek. Next was the dot-com era: around the time I should have graduated college if I hadn’t dragged out my undergrad a solid 8 years. In my memories it started when I signed up with my first dial-up ISP and played with Gopher and newsgroups – through the emergence of Mosaic, Netscape, and my first web sites (ugly) – and faded with the dot-com crash and crappy TV studio websites (which still, mostly, suck). Personally I went from paramedic, to PC tech, to sysadmin, to network admin, to developer in these short years. (Fast learner, I guess). The third era? Right now. It started with the dual emergences of the iPhone and Amazon Web Services, and it’s years away from ending. For me the bellwether moments were my first Intel-based MacBook Pro running Parallels (I converted the official Gartner image into a VM to run it there), followed by the iPhone, with a little Dropbox mixed in. The overlapping models of mobility and cloud computing are creating one of the most exciting times to be in technology I can remember. With lower barriers to entry in terms of costs and hardware, and near-ubiquitous accessibility (even accounting for AT&T wireless), I’m more psyched today than even when I built my first little company to make doinky web apps and do a little security consulting. I seriously wish I was out there doing startups, but it’s not quite the time for a career change. When I can spin up 5 different servers, on 5 different operating systems, in 5 minutes for under $5? From my iPad? That kicks so much more ass than making a crappy embossed background for my old ‘professional’ looking site. As for security? Oh my god, is this a freaking awesome time to do what we do. The threats matter, the assets are important, and the opportunities are nearly endless. I realize a lot of people are depressed about the whole industry game and compliance cycle, but that’s a small penalty to pay for the excitement and meaning of our work. You don’t get a seat at the table unless the stakes are high. Life is good. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Video of Rich on MSNBC. He apologizes for the eyebrow thing. Mort cited talking about cloud security at Bsides. Rich quoted at SearchSecurity on cloud. RSA Podcast on Agile development, Security Fail. Protegrity calls Securosis one of their favorite blogs. Data is Safe – Until It’s Not. Apparently Adrian telling the retail sector they suck at security has legs. And fortunately for us WhiteHat Security published data to back up his claim. Clearing The Air On DAM. Adrian’s Dark Reading post. Favorite Securosis Posts Rich: FireStarter: The New Cold War. There seems to be lots of naivete out there. Guess what – they hack us, we hire people to hack them. The world goes on. Mike Rothman & Adrian Lane: What You Really Need to Know about Oracle Database Firewall. Rich calls out marketing buffoonery. FTW. Other Securosis Posts React Faster and Better: Respond, Investigate, and Recover. Could This Be WikiLeaks for the Criminal Computer Underground?. What I Learned at RSAC. Incite 2/23/2011: Giving up. RSA: the Only Difference Between a Rut and a Grave Is the Depth. RSA: We Now Go Live to Our Reporters on the Scene. How to Encrypt Block Storage in the Cloud with SecureCloud. RSA 2011: A Few Pointers. The Securosis Guide to RSA 2011: The Full Monty. Favorite Outside Posts Rich: Gunnar follows the Heartland cash. I haven’t seen anyone else track the financials of a company involved in a major breach so closely. Before we start talking “dollars per record lost”, we need more of this kind of work. Mike Rothman: The obsession with next. Given that next is all we saw at RSA, this was a timely post on the 37Signals blog. Adrian Lane: Russian Cops Crash Pill Pusher Party. Oddly no arrests have been reported, but a great story. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Top News and Posts Zeus malware integrating SMS for hacking out of band authentication. More on HBGary Hack. Lion Watch. With new FileVault. When to implement that is an open question. SSDs resistant to erasure. Updated SAFEcode Development Practices. Oracle Releases Database Firewall. 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 Shrdlu, in response to What I Learned at RSAC. Nice piece, Adrian–and it was good to meet you too. The general sentiment I heard from vendors I talked to was that the overall mood was better at RSA this year and there were more end-users (as opposed to vendors and partners selling to one another). I can’t form an opinion, as this was my first RSA, but I’ve been to a lot of other conferences and I really didn’t see much difference between this one and other “commercial” ones. That being said, I did see some interesting stuff going on, and I think it’s our job to seek it out and

When Brian Krebs sent me a link to his latest article on illegal pharmacy networks my only response was: Holy friggin’ awesomesauce!!! Brian got his hands on 9GB of financial records for what is likely the world’s biggest online spammer/illegal pharmacy network: In total, these promoters would help Glavmed sell in excess of 1.5 million orders from more than 800,000 consumers who purchased knockoff prescription drugs between May 2007 and June 2010. All told, Glavmed generated revenues of at least $150 million. Brian told me this is merely the first of a lengthy series he is putting together as he digs through the data and performs additional research. This is true investigative reporting, folks. Here’s why I think this could be a watershed moment in computer crime. While this may only be the books for a big criminal pharmacy, it shows all the linkages to other corners of the global criminal networks. Spammers, black hat hackers, SEO, money launderers… it’s probably in there. Especially once Brian correlates with his other sources. He did answer one little question I’ve always had… do they actual send people the little blue pills? Yep. And Brian has the shipping records to prove it. Share:

After you have validated and filtered the initial alert, then escalated to contain and respond to the incident, you may need to escalate for further specialized response, investigation, and (hopefully) recovery. This progression to the next layer of escalation varies more among organizations we have talked with than the others – due to large differences in available resources, skill sets, and organizational priorities, but as with the rest of this series the essential roles are fairly consistent. Tier 3: Respond, Investigate, and Recover Tier 3 is where incident response management, specialized resources, and the heavy hitters reside. In some cases escalation may be little more than a notification that something is going on. In others it might be a request for a specialist such as a malware analyst for endpoint forensics analysis. This is also the level where most in-depth investigation is likely to occur – including root cause analysis and management of recovery operations. Finally, this level might include all-hands-on-deck response for a massive incident with material loss potential. Despite the variation in when Tier 3 begins, the following structure aligns at a high level with the common processes we see: Escalate response: Some incidents, while not requiring the involvement of higher management, may need specialized resources that aren’t normally involved in a Tier 2 response. For example, if an employee is suspected of leaking data you may need a forensic examiner to look at their laptop. Other incidents require the direct involvement of incident response management and top-tier response professionals. We have listed this as a single step, but it is really a self-contained response cycle of constantly evaluating needs and pulling in the right people – all the way up to executive management if necessary. Investigate: You always investigate to some degree during an incident, but depending on its nature there may be far more investigation after initial containment and remediation. As with most steps in Tier 3, the lines aren’t necessarily black and white. For certain kinds of incidents – particularly advanced attacks – the investigation and response (and even containment) are carried out in lockstep. For example, if you detect customized malware, you will need to perform a concurrent malware analysis, system forensic analysis, and network forensic analysis. Determine root cause: Before you can close an incident you need to know why it happened and how to prevent it from happening again. Was it a business process failure? Human error? Technical flaw? You don’t always need this level of detail to remediate and get operations back up and running on a temporary basis, but you do need it to fully recover – and more importantly to ensure it doesn’t happen again. At least not using the same attack vector. Recover: Remediation gets you back up and running in the short term, but in recovery you finish closing the holes and restore normal operations. The bulk of recovery operations are typically handled by non-security IT operations teams, but at least partially under the direction of the security team. Permanent fixes are applied, permanent holes closed, and any restored data examined to ensure you aren’t re-introducing the very problems that allowed the incident in the first place. (Optional) Prosecute or Discipline: Depending on the nature of the incident you may need to involve law enforcement and carry a case through to prosecution, or at least discipline/fire an employee. Since nothing involving lawyers except billing ever moves quickly, this can extend many years beyond the official end of an incident. Tier 3 is where the buck stops. There are no other internal resources to help if an incident exceeds capabilities. In that case, outside contractors/specialists need to be brought in, who are then (effectively) added to your Tier 3 resources. The Team We described Tier 1 as dispatchers, and Tier 2 as firefighters. Sticking with that analogy, Tier 3 is composed of chiefs, arson investigators, and rescue specialists. These are the folks with the strongest skills and most training in your response organization. Primary responsibilities: Ultimate incident management. Tier 3 handles incidents that require senior incident management and/or specialized skills. These senior individuals manage incidents, use their extensive skills for complex analysis and investigation, and coordinate multiple business units and teams. They also coordinate, train, and manage lower level resources. Incidents they manage: Anything that Tier 2 can’t handle. These are typically large or complex incidents, or more-constrained incidents that might involve material losses or extensive investigation. A good rule of thumb is that if you need to inform senior or executive management, or involve law enforcement and/or human resources, it’s likely a Tier 3 incident. This tier also includes specialists such as forensics investigators, malware analysts, and those who focus on a specific domain as opposed to general incident response. When they escalate: If the incident exceeds the combined response capabilities of the organization. In other words, if you need outside help, or if something is so bad (e.g., a major public breach) that executive management becomes directly involved. The Tools These responders and managers have a combination of broad and deep skills. They manage large incidents with multiple factors and perform the deep investigations to support full recovery and root cause analysis. They tend to use a wide variety of specialized tools, including those they write themselves. It’s impossible to list all the options out, but here are the main categories: Network (full packet capture) forensics: You’ve probably noticed this category appearing at all the levels. While the focus in the other response tiers is more on alerting and visualization, at this level you are more likely to dig deep into the packets to fully understand what’s going on for both immediate response and later investigation. If you don’t capture it you can’t analyze it, and full packet capture is essential for the advanced incident response which provides the focus here. Once data is gone you can’t get it back – thus our incessant focus on capturing as much as you can, when you can. Endpoint

Nothing amuses me more than some nice vendor-on-vendor smackdown action. Well, plenty of things amuse me more, especially Big Bang Theory and cats on YouTube, but the vendor thing is still moderately high on my list. So I quite enjoyed this Dark Reading article on the release of the Oracle Database Firewall. But perhaps a little outside perspective will help. Here are the important bits: As mentioned in the article, this is the first Secerno product release since their acquisition. Despite what Oracle calls it, this is a Database Activity Monitoring product at its core. Just one with more of a security focus than audit/compliance, and based on network monitoring (it lacks local activity monitoring, which is why it’s weaker for compliance). Many other DAM products can block, and Secerno can monitor. I always thought it was an interesting product. Most DAM products include network monitoring as an option. The real difference with Secerno is that they focused far more on the security side of the market, even though historically that segment is much smaller than the audit/monitoring/compliance side. So Oracle has more focus on blocking, and less on capturing and storing all activity. It is not a substitute for Database Activity Monitoring products, nor is it “better” as Oracle claims. Because it is a form of DAM, but – as mentioned by competitors in the article – you still need multiple local monitoring techniques to handle direct access. Network monitoring alone isn’t enough. I’m sure Oracle Services will be more than happy to connect Secerno and Oracle Audit Vault to do this for you. Secerno basically whitelists queries (automatically) and can block unexpected activity. This appears to be pretty effective for database attacks, although I haven’t talked to any pen testers who have gone up against it. (They do also blacklist, but the whitelist is the main secret sauce). Secerno had the F5 partnership before the Oracle acquisition. It allowed you to set WAF rules based on something detected in the database (e.g., block a signature or host IP). I’m not sure if they have expanded this post-acquisition. Imperva is the only other vendor that I know of to integrate DAM/WAF. Oracle generally believes that if you don’t use their products your are either a certified idiot or criminally negligent. Neither is true, and while this is a good product I still recommend you look at all the major competitors to see what fits you best. Ignore the marketing claims. Odds are your DBA will buy this when you aren’t looking, as part of some bundle deal. If you think you need DAM for security, compliance, or both… start an assessment process or talk to them before you get a call one day to start handling incidents. In other words: a good product with advantages and disadvantages, just like anything else. More security than compliance, but like many DAM tools it offers some of both. Ignore the hype, figure out your needs, and evaluate to figure out which tool fits best. You aren’t a bad person if you don’t buy Oracle, no matter what your sales rep tells your CIO. And seriously – watch out for the deal bundling. If you haven’t learned anything from us about database security by now, hopefully you at least realize that DBAs and security don’t always talk as much as they should (the same goes for Guardium/IBM). If you need to be involved in any database security, start talking to the DBAs now, before it’s too late. BTW, not to toot our own horns, but we sorta nailed it in our original take on the acquisition. Next we will see their WAF messaging. And we have some details of how Secerno works. Share: