Research

We have written a lot about Oracle’s acquisition of Secerno: the key points of the acquisition, the Secerno technology, and some of the business benefits Oracle gets with the Secerno purchase. We did so mainly because Database Activity Monitoring (DAM) is a technology that Rich and I are intimately familiar with, and this acquisition shakes up the entire market. But we suspect there is more. Rich and I have a feeling that this purchase signals Oracle’s mid-term security strategy, and the Secerno platforms will comprise the key component. We don’t have any inside knowledge, but there are too many signals to go unnoticed so we are making a prediction, and our analysis goes something like this: Quick recap: Oracle acquired a Database Activity Monitoring vendor, and immediately marketed the product as a database firewall, rather than a Database Activity Monitoring product. What Oracle can do with this technology, in the short term, is: “White list” database queries. Provide “virtual patching” of the Oracle database. Monitor activity across most major relational database types. Tune policies based on monitored traffic. Block unwanted activity. Offer a method of analysis with few false positives. Does any of this sound familiar? What if I changed the phrase “white list queries” to “white list applications”? If I changed “Oracle database” to “Oracle applications”? What if I changed “block database threats” to “block application threats”? Does this sound like a Web Application Firewall (WAF) to you? Place Secerno in front of an application, add some capabilities to examine web app traffic, and it would not take much to create a Web Application Firewall to complement the “database firewall”. They can tackle SQL injection now, and provide very rudimentary IDS. It would be trivial for Oracle to add application white listing, HTML inspection, and XML/SOAP validation. Down the road you could throw in basic XSS protections and can call it WAF. Secerno DAM, plus WAF, plus the assessment capabilities already built into Oracle Management Packs, gives you a poor man’s version of Imperva. Dude, you’re getting a WAF! We won’t see much for a while yet, but when we do, it will likely begin with Oracle selling pre-tuned versions of Secerno for Oracle Applications. After a while we will see a couple new analysis options, and shortly thereafter we will be told this is not WAF, it’s better than WAF. How could these other vendors possibly know the applications as well as Oracle? How could they possibly protect them as accurately or efficiently? These WAF vendors don’t have access to the Oracle applications code, so how could they possibly deliver something as effective? We are not trying to be negative here, but we all know how Oracle markets, especially in security: Oracle is secure – you don’t need X. All vendors of X are irresponsible and beneath consideration. Oracle has purchased vendor Y in market X because Oracle cares about the security of its customers. Oracle is the leading provider of X. Buying anything other than Oracle’s X is irresponsible because other vendors use undocumented APIs and/or inferior techniques. Product X is now part of the new Oracle Suite and costs 50% more than before, but includes 100% more stuff that you don’t really need but we couldn’t sell stand-alone. OK, so we went negative. Send your hate mail to Rich. I’ll field the hate mail from the technologists out there who are screaming mad, knowing that there is a big difference between WAF policies and traffic analysis and what Secerno does. Yes and no, but it’s irrelevant from a marketing standpoint. For those who remember Dell’s “Dude” commercials from the early 2000s, they made buying a computer easy and approachable. Oracle will do the same thing with security, making the choice simple to understand, and covering all their Oracle assets. They’d be crazy not to. Market this as a full-featured WAF, blocking malicious threats with “zero false positives”, for everything from Siebel to 11G. True or not, that’s a powerful story, and it comes from the vendor who sold you half the stuff in your data center. It will win the hearts of the security “Check the box” crowd in the short term, and may win the minds of security professionals in the long term. Do you see it? Does it make sense? Tell me I am wrong! Share:

Continuing our discussion of core SIEM and Log Management technology, we now move into event correlation. This capability was the holy grail that drove most investment in early SIEM products, and probably the security technology creating the most consistent disappointment amongst its users. But ultimately the ability to make sense of the wide variety of data streams, and use them to figure out what is under attack or compromised, is essential to any security practice. This means that despite the disappointments, there will continue to be plenty of interest in correlation moving forward. Correlation Defining correlation is akin to kicking a hornet’s nest. It immediately triggers agitated debates because there are several published definitions and every expert has their favorite. As usual, we need to revisit the definitions and level-set, not to create controversy (though that tends to happen), but to make things easy to understand. As we search for a pragmatic definition, we need to simplify concepts to make subjects understandable to a wider audience at the expense of precision. We understand our community is not a bunch of shrinking violets, so we welcome your comments and suggestions to make our research more relevant. Let’s get back to the end-user problem driving SIEM and log management. Ultimately the goal of this technology is to interpret security-related data to improve security, increase efficiency, and/or document security controls. If a single file contained all the information required for security analysis, we would not bother with the collection and association of events from multiple sources. The truth is that each log or event contains a piece of information, which forms part of the puzzle, but lacks context necessary to analyze the big picture. In order to make meaningful decisions about what is going on with our applications and within our network, we need to combine events from different sources. Which events we want, and what pieces of data from those events we need, vary based on the problem we are trying to solve. So what is correlation? Correlation is the act of linking multiple events together to detect strange behavior. It is the association of different but related events to provide broader context than a single event can provide. Keep in mind that we are using a broad definition of ‘event’ because as the breadth of analysis increases, data may expand beyond traditional events. Seems pretty simple, eh? Let’s look at an example of how correlation can help achieve one of our key use cases: increasing the efficiency of the security team. In this case an analyst gets events from multiple locations and device types (and/or applications), and is expected to figure out whether there is an issue. The attacker might first scan the perimeter and then target an externally facing web server with a series of known exploits. Upon successfully compromising the web server, the attacker sets up a new user account and start scanning internally to find more exploitable hosts. The data is available to catch this attack, but not in a single place. The firewalls see the initial scans. The IDS/IPS sees the series of exploits. And the user directory sees the new account on the compromised server. The objective of correlation is to see all these events come through and recognize that the server has been compromised and needs immediate attention. Easy in concept, very hard in practice. Historically, the ability to do near real time analysis and event correlation was one of the ways SIEM differed from log management, although the lines continue to blur. Most of the steps we have discussed so far (collecting data, then aggregating and normalizing it) help isolate the attributes that link events together to make correlation possible. Once data is in manageable form we apply rules to detect attacks and misuse. These rules are comprised of the granular criteria (e.g., specific router, user account, time, etc.), and determine if a series of events reaches a threshold requiring corrective action. But the devil is in the details. The technology implements correlation as a linear series of events. Each comparison may be a simple case of “if X=Y, then” do something else, but we may need to string several of these comparisons together. Second, note that correlation is built on rules for known attack patterns. This means we need some idea of what we are looking for to create the correlation rules. We have to understand attack patterns or elements of a compliance requirement in order to determine which device and event types should be linked. Third, we have to factor in the time factor, because events do not happen simultaneously, so there is a window of time within which events are likely to be related. Finally the effectiveness of correlation also depends on the quality of data collection, normalization, and tagging or indexing of information to feed the correlation rules. Development of rules takes time and understanding, as well as ongoing maintenance and tuning. Sure, your vendor will provide out-of-the-box policies to help get you started, but expect to invest significant time into tweaking existing rules for your environment, and writing new policies for security and compliance to keep pace with the very dynamic security environment. Further complicating matters: more rules and more potentially-linked events to consider increase computational load exponentially. There is a careful balancing act to be performed between the number of policies to implement, the accuracy of the results, and the throughput of the system. These topics may not immediately seem orthogonal, but generic rules detect more threats at a cost of more false positives. The more specific the rule, and the more precisely tailored to find specific threats, the less it will find new problems. This is the difficulty in getting correlation working effectively in most environments. As described in the Network Security Fundamentals series, it’s important to define clear goals for any correlation effort and stay focused on them. Trying to boil the ocean always yields disappointing results. Alerting Once events are correlated, analysis performed, and weirdness

We get a lot of requests to sponsor this blog. We got several this week. Not just the spammy “Please link with us,” or “Host our content and make BIG $$$” stuff. And not the PR junk that says “We are absolutely positive your readers would just love to hear what XYZ product manager thinks about data breaches,” or “We just released 7.2.2.4 version of our product, where we changed the order of the tabs in our web interface!” Yeah, we get fascinating stuff like that too. Daily. But that’s not what I am talking about. I am talking about really nice, personalized notes from vendors and others interested in supporting the Securosis site. They like what we do, they like that we are trying to shake things up a bit, and they like the fact that we are honest in our opinions. So they write really nice notes, and they ask if they can give us money to support what we do. To which we rather brusquely say, “No”. We don’t actually enjoy doing that. In fact, that would be easy money, and we like as much easy money as we can get. More easy money is always better than less. But we do not accept either advertising on the site or sponsorship because, frankly, we can’t. We just cannot have the freedom to do what we do, or promote security in the way we think best, if we accept payments from vendors for the blog. It’s like the classic trade-off in running your own business: sacrifice of security for the freedom to do things your own way. We don’t say “No,” to satisfy some sadistic desire on our part to be harsh. We do it because we want the independence to write what we want, the way we want. Security is such a freakin’ red-headed stepchild that we have to push pretty hard to get companies, vendors, and end users to do the right thing. We are sometimes quite emphatic to knock someone off the rhythm of that PowerPoint presentation they have delivered a hundred times, somehow without ever critically examining its content or message. If we don’t they will keep yakking on and on about how they address “Advanced Persistant Threats.” Sometimes we spotlight the lack of critical reasoning on a customer’s part to expose the fact that they are driven by politics without a real plan for securing their environment. We do accept sponsorship of events and white papers, but only after the content has gone through community review and everyone has had a chance to contribute. Many vendors and a handful of end-users who talk with us on the phone know we can be pretty harsh at times, and they still ask if they economically support our research. And we still say, “No”. But we appreciate the interest, and we thank you all for for participating in our work. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on What Oracle Gets In The Secerno Buy. Rich quoted in a Dark Reading article on database passwords. Did we mention Rich was on NPR Science Friday? The full transcript is up. Unfortunately – since it has all the “you knows” and “ums” in it. Adrian’s DAM Deployment Issues to Avoid launched this week. Rich on the Network Security Podcast. Adrian quoted in CRN Tech on database security. Mike quoted in SC Magazine. Favorite Securosis Posts Rich: Code Re-engineering. This applies to so much more than code. I’ve been on everything from mountain rescues to woodworking projects where the hardest decision is to stop patching and nuke it from orbit. We are not mentally comfortable throwing away hours, days, or years of work; and the ability to step back, analyze, and start over is rare in any society. Mike Rothman: Code Re-engineering. Adrian shows his development kung fu. He should get pissed off more often. David Mortman: Gaming the Tetragon. Adrian Lane: The Secerno Technology. Just because you need to understand what this is now that Oracle has their hands on it. Other Securosis Posts Understanding and Selecting SIEM/LM: Aggregation, Normalization, and Enrichment. Quick Wins with DLP Presentation. Incite 5/26/2010: Funeral for a Friend. Understanding and Selecting SIEM/LM: Data Collection. A Phish Called Tabby. Thoughts on Diversity and False Diversity. FireStarter: The Only Value/Loss Metric That Matters. The Laziest Phisher in the World. Favorite Outside Posts Rich: Data Loss Prevention and Enterprise Rights Management; Complimentary or alternative? For 6 months or so I’ve been getting a lot of “which is better, DRM or DLP?” questions. The problem is that they are not alternative technologies, but complementary. The trick is to figure out which one might be more appropriate to implement first, not which can replace the other. Besides, I think they are on the path to complete convergence in the long term, and we already have early samples of combined solutions. Adrian: Bejtlich’s Forget Pre-Incident Cost, How Much Did Your Last Incident Cost? Almost picked Rich’s post The Only Value/Loss Metric That Matters for my internal fave of the week, but this is like a two-fer. Mike Rothman: Google Secure Search and Security Overkill. Boaz makes the point that not all security is worth it. Playing at a security theater near you…. David Mortman: Privacy Theater. Project Quant Posts DB Quant: Discovery And Assessment Metrics (Part 2) Identify Apps. DB Quant: Discovery And Assessment Metrics (Part 1) Enumerate Databases. DB Quant: Planning Metrics (Part 4). Research Reports and Presentations Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Report: Database Assessment. Top News and Posts TabNabbing was the big news this week. Three indicted on $100M Rogue Software Scam. Mozilla Plugin Check via Brian Krebs. Supposed Vuln in iPhone Encryption. Oopsie. Why does the IRS never have a problem like this? Your Privacy in Their Hands via LiquidMatrix. Can you have a PCI Compliant Virtual Site? Good question. New School blog announces The

In the last post on Data Collection we introduced the complicated process of gathering data. Now we need to understand how to put it into a manageable form for analysis, reporting, and long-term storage for forensics. Aggregation SIEM platforms collect data from thousands of different sources because these events provide the data we need to analyze the health and security of our environment. In order to get a broad end-to-end view, we need to consolidate what we collect onto a single platform. Aggregation is the process of moving data and log files from disparate sources into a common repository. Collected data is placed into a homogenous data store – typically purpose-built flat file repositories or relational databases – where analysis, reporting, and forensics occur; and archival policies are applied. The process of aggregation – compiling these dissimilar event feeds into a common repository – is fundamental to Log Management and most SIEM platforms. Data aggregation can be performed by sending data directly into the SIEM/LM platform (which may be deployed in multiple tiers), or an intermediary host can collect log data from the source and periodically move it into the SIEM system. Aggregation is critical because we need to manage data in a consistent fashion: security, retention, and archive policies must be systematically applied. Perhaps most importantly, having all the data on a common platform allows for event correlation and data analysis, which are key to addressing the use cases we have described. There are some downsides to aggregating data onto a common platform. The first is scale: analysis becomes exponentially harder as the data set grows. Centralized collection means huge data stores, greatly increasing the computational burden on the SIEM/LM platform. Technical architectures can help scale, but ultimately these systems require significant horsepower to handle an enterprise’s data. Systems that utilize central filtering and retention policies require all data to be moved and stored – typically multiple times – increasing the burden on the network. Some systems scale using distributed processing, where filtering and analysis occur outside the central repository, typically at the distributed data collection point. This reduces the compute burden on the central server and allows processing to occur on smaller, more manageable data sets. It does require that policies, along with the code to process them, be distributed and kept current throughout the network. Distributed agent processes are a handy way to “divide and conquer”, but increase IT administration requirements. This strategy also adds a computational burden o the data collection points, degrading their performance and potentially slowing enough to drop incoming data. Data Normalization If the process of aggregation is to merge dissimilar event feeds into one common platform, normalization takes it one step further by reducing the records to just common event attributes. As we mentioned in the data collection post, most data sources collect exactly the same base event attributes: time, user, operation, network address, and so on. Facilities like syslog not only group the common attributes, but provide means to collect supplementary information that does not fit the basic template. Normalization is where known data attributes are fed into a generic template, and anything that doesn’t fit is simply omitted from the normalized event log. After all, to analyze we want to compare apple to apples, so we throw away an oranges for the sake of simplicity. Depending upon the SIEM or Log Management vendor, the original non-normalized records may be kept in a separate repository for forensics purposes prior to later archival or deletion, or they may simply be discarded. In practice, discarding original data is a bad idea, since the full records are required for any kind of legal enforcement. Thus, most products keep the raw event logs for a user-specified period prior to archival. In some cases, the SIEM platform keeps a link to the original event in the normalized event log which provides ‘drill-down’ capability to easily reference extra information collected from the device. Normalization allows for predicable and consistent storage for all records, and indexes these records for fast searching and sorting, which is key when battling the clock in investigating an incident. Additionally, normalization allows for basic and consistent reporting and analysis to be performed on every event regardless of the data source. When the attributes are consistent, event correlation and analysis – which we will discuss in our next post – are far easier. Technically normalization is no longer a requirement on current platforms. Normalization was a necessity in the early days of SIEM, when storage and compute power were expensive commodities, and SIEM platforms used relational database management systems for back-end data management. Advances in indexing and searching unstructured data repositories now make it feasible to store full source data, retaining original data, and eliminating normalization overhead. Enriching the Future In reality, we are seeing a number of platforms doing data enrichment, adding supplemental information (like geo-location, transaction numbers, application data, etc.) to logs and events to enhance analysis and reporting. Enabled by cheap storage and Moore’s Law, and driven by ever-increasing demand to collect more information to support security and compliance efforts, we expect more platforms to increase enrichment. Data enrichment requires a highly scalable technical architecture, purpose-built for multi-factor analysis and scale, making tomorrow’s SIEM/LM platforms look very similar to current business intelligence platforms. But that just scratches the surface in terms of enrichment, because data from the analysis can also be added to the records. Examples include identity matching across multiple services or devices, behavioral detection, transaction IDs, and even rudimentary content analysis. It is somewhat like having the system take notes and extrapolate additional meaning from the raw data, making the original record more complete and useful. This is a new concept for SIEM, so the enrichment will ultimately encompass is anyone’s guess. But as the core functions of SIEM have standardized, we expect vendors to introduce new ways to derive additional value from the sea of data they collect. Other Posts in Understanding and Selecting SIEM/LM Introduction. Use Cases,

I just ran across a really interesting blog post by Joel Spolsky from last April: Things You Should Never Do, Part 1. Actually. the post pissed me off. This is one of those hot-button topics that I have had to deal with several times in my career, and have had to manage in the face of entrenched beliefs. His statement is t hat you should never rewrite a code base from scratch. The reasoning is “No major firm has ever successfully survived a product rewrite. Just look at Netscape … ” Whatever. I am a fixer. I was the guy who was able to make code reliable. I was the guy who found and fixed the obscure bugs. As I progressed in my career and started to manage teams of developers, more often than not I was handed the really crummy re-engineering projects because I could fix the problems and make customers happy. Sometimes success is its own penalty. I have inherited code so bad that bug fixes cost 4x in time and usually created new bugs in the process. I have inherited huge bodies of Java code written entirely as if Java were a 3G procedural language – ignoring the object-oriented paradigm completely. I have been tasked with fixing code that – for a simple true/false comparison – made 12 comparisons, 8 database, insertions and 7 deletions – causing an 180x performance penalty. I have inherited code so bad it broke the compiler. I have inherited code so bad that you could not change a back-end database query without breaking the GUI! It takes a real gift for bad programming to do these things. There are times when the existing code – all or part – simply needs to be thrown away. There are times that code is so tightly intertwined that you cannot simply fix one piece at a time. And in some cases there are really good business reasons, like your major customers say your code is crap and needs to be thrown away. Bad code can bleed a company to death with lost sales, brand impairment, demoralization, and employee turnover. That said, I agree with Joel’s basic premise that re-writing your product can kill your company. And I even agree about a lot of the social behaviors he describes that create failure. There is absolutely no reason to believe that the people who developed bad code the first time will not do the same thing the next time. But I don’t agree that you should never rewrite. I don’t agree that it has never been done successfully. I know because I have done it successfully. Twice. Out of three attempts, but hey, I got the important projects right. We tend not to hear about successful rewrites because the companies that carried it off really don’t want everyone knowing that previous versions were terrible. They would rather focus on happy customers and competitive products. It’s very likely that companies who need to rewrite code will screw up a second time. Honestly, there are a lot more historic rewrite flameouts than success stories. Companies know what they want to fix in the code, but they don’t understand what they need to fix in the company. I contend this is because there are company behaviors that promote failure, and if they did it once, they are likely to do it again. And again. Until, mercifully, the company goes down in flames. There are a lot of reasons why re-architecture and re-implementations projects fail. In no particular order … Big eyes: You are the chief developer and you hate your current product. You have catalogued everything that is wrong with it and how you would fix it. You have extensive lists of features you would like to implement. You have a grand vision of how this product should function, how it should be architected, and how it will be implemented. This causes your re-engineering effort to fail because you think that you are going to build perfect software, tackle every problem, and build every feature, in the first revision. And you commit to do so, just to get the project green-lighted. Resources: You current product sucks. It really sucks. It has atrocious quality and low performance, and is miserable to manage. It’s so freaking bad that customers ask for their money back, and sales falter. This causes your re-engineering effort to fail because there is simply not enough time, and not enough revenue to pay for your rebuild. Not with customers breathing down management’s neck, and investors looking for the quick “liquidity event”. So marketing keeps on marketing, sales keeps on selling, and you keep on supporting the old mess you have. Bad blood: When you car gets old and dies, you don’t expect someone to give you a new one for free. When your crappy old code no longer supports your customers, in essence you need to pay for new code. Yes, it is unfortunate that you bought a lemon last time, but you need to make additional investments in time and development resources, and fix the problems that led you down the wrong path. Your project fails because management is so bitter about the failure that they muck around with development practices, apply more pressure and try to get more involved with day-to-day development, when the opposite is needed. Expectations: Not only is the development team excited at not having to work on the atrocious code you have now, but they are really looking forward to working on a product that has semi-modern design. The whole department is buzzing, and so is management! This causes your re-engineering effort to fail because the Chickens think that no only are you going to deliver perfect software, but you are going to deliver every feature and function of the old crappy product, as well as a handful of new and extraordinary features as well. And it’s unlikely that management will let you adjust the ship date to accommodate the new demands.

The first four posts our the SIEM series dealt with understanding what SIEM is, and what problems it solves. Now we move into how to select the right product/solution/service for your organization, and that involves digging into the technology behind SIEM and log management platforms. We start with the foundation of every SIEM and Log Management platform: data collection. This is where we collect data from the dozens of different types of devices and applications we monitor. ‘Data’ has a pretty broad meaning – here it typically refers to event and log records but can also include flow records, configuration data, SQL queries, and any other type of standard data we want to pump into the platform for analysis. It may sound easy, but being able to gather data from every hardware and software vendor on the planet in a scalable and reliable fashion is incredibly difficult. With over 20 vendors in the Log Management and SIEM space, and each vendor using different terms to differentiate their products, it gets very confusing. In this series we will define vendor-neutral terms to describe the technical underpinnings and components of log data collection, to level-set what you really need to worry about. In fact, while log files are what is commonly collected, we will use the term “data collection”, as we recommend gathering more than just log files. Data Collection Overview Conceptually, data collection is very simple: we just gather the events from different devices and applications on our network to understand what is going on. Each device generates an event each time something happens, and collects the events into a single repository known as a log file (although it could actually be a database). There are only four components to discuss for data collection, and each one provides a pretty straight-forward function. Here are the functional components: Fig 1. Agent data collector Fig 2. Direct connections to the device Fig 3. Log file collection Source: There are many different sources – including applications, operating systems, firewalls, routers & switches, intrusion detection systems, access control software, and virtual machines – that generate data. We can even collect network traffic, either directly from the network for from routers that support Netflow-style feeds. Data: This is the artifact telling us what actually happened. The data could be an event, which is nothing more than a finite number of data elements to describe what happened. For example, this might record someone logging into the system or a service failure. Minimum event data includes the network address, port number, device/host name, service type, operation being performed, result of the operation (success or error code), user who performed the operation, and timestamp. Or the data might just be configuration information or device status. In practice, event logs are pretty consistent across different sources – they all provide this basic information. But each offers additional data, including context. Additional data types may include things such as NetFlow records and configuration files. In practice, most of the data gathered will be events and logs, but we don’t want to arbitrarily restrict our scope. Collector: This connects to a source device, directly or indirectly, to collect the events. Collectors take different forms: they can be agents residing on the source device (Fig. 1), remote code communicating over the network directly with the device (Fig. 2), an agent writing code writing to a dedicated log repository (Fig. 3), or receivers accepting a log file stream. A collector may be provided by the SIEM vendor or a third party (normally the vendor of the device being monitored). Further, the collector functions differently, depending upon the idiosyncrasies of the device. In most cases the source need only be configured once, and events will be pushed directly to the collector or into a neutral log file read by it. In some cases, the collector must continually request data be sent, polling the source at regular intervals. Protocol: This is how collector communicates with the source. This is an oversimplification, of course, but think of it as a language or dialect the two agree upon for communicating events. Unfortunately there are lots of them! Sometimes the collector uses an API to communicate directly with the source (e.g., OPSEC LEA APIs, MS WMI, RPC, or SDEE). Sometimes events are streamed over networking protocols such as SNMP, Netflow, or IPFIX. Sometimes the source drops events into a common file/record format, such as syslog, Windows Event Log, or syslog-ng, which is then read by the collector. Additionally, third party applications such as Lasso and Snare provide these features as a service. Data collection is conceptually simple, but the thousands of potential variations makes implementation a complex mess. It resembles a United Nations meeting: you have a whole bunch of people talking in different languages, each with a particular agenda of items they feel are important, and different ways they want to communicate information. Some are loquacious and won’t shut up, while others need to be poked and prodded just to extract the simplest information. In a nutshell, it’s up to the SIEM and Log Management platforms to act as the interpreters, gathering the information and putting it into some useful form. Tradeoffs Each model for data collection has trade-offs. Agents can be a powerful proxy, allowing the SIEM platform to use robust (sometimes proprietary) connection protocols to safely and reliably move information off devices; in this scenario device setup and configuration is handled during agent installation. Agents can also take full advantage of native device features, and can tune and filter the event stream. But agents have fallen out of favor somewhat. SIEM installations cover thousands of devices, which means agents can be a maintenance nightmare, requiring considerable time to install and maintain. Further, agents’ processing and data storage requirements on the device can affect stability and performance. Finally, most agents require administrative access, which creates am additional security concern on each device. Another common technique streams events to log files, such as syslog or the Windows Event

I ran long on yesterday’s Oracle Buys Secerno, but it is worth diving into Secerno’s technology to understand why this is a good fit for Oracle. I get a lot of questions about Secerno product, from customers unclear how the technology works. Even other database activity monitoring vendors ask – some because they want to know what the product is really capable of, others who merely want to vent their frustration at me for calling Secerno unique. And make no mistake – Secerno is unique, despite competitor claims to the contrary. Unlike every other vendor in the market, Secerno analyzes the SQL query construct. They profile valid queries, and accept only queries that have the right structure. This is not content monitoring, not traditional behavioral monitoring, not context monitoring, and not even attribute-based monitoring, but looking at the the query language itself. Consider that any SQL query (e.g., SELECT, INSERT, UPDATE, CREATE, etc.) has dozens of different options, allowing hundreds of variations. You can build very complex logic, including embedding other queries and special characters. Consider an Oracle INSERT operation as an example. The (pseudo) code might look like: INSERT INTO Table.Column VALUE ‘XYZ’ Or it might look like … INSERT INTO User.Table.@db_Link ColumnA, ColumnC VALUE ‘XYZ’, ‘PDQ’ | SELECT * FROM SomeSystemTable … WHERE 1=1; We may think of INSERT as a simple statement, but there are variations which are not simple at all. Actually they get quite complex, and enable me to all sorts of stuff to confuse the query parser into performing operations on my behalf. There are ample opportunities for me to monkey with the WHERE clause, embed logic or reference other objects. Secerno handles this by mapping every possible SQL query variation for the database platform it is protecting, but depending upon the application, only allows a small subset of known variations to be accepted. Everything else can be blocked. In the examples above, the first would be permitted while the latter blocked. Attackers commonly abuse query syntax to confuse the database query parser into doing something it is not supposed to do. The more obscure uses of the SQL query language are ripe targets for abuse. In essence you remove a lot of the possible attacks because you simply do not allow unacceptable query structures or variations. This is a different way to define acceptable use of the database. Secerno calls this a “Database Firewall”, which helps the general IT audience quickly get the concept, but I call this technology query White Listing, as it is a bit more accurate. Pick the acceptable queries and their variations, and block everything else. And it can ‘learn’ by looking at what the application sends the database – and if my memory serves me, can even learn appropriate parameters as well. It’s less about context and content, and more about form. Other vendors offer blocking and advertise “Database Firewall” capabilities. Some sit in front of the database like Secerno does, and others reside on the database platform. The real difference is not whether or not they block, but in how they detect what to block. As with any technology, there are limitations. If Secerno is used to block queries, it can create a performance bottleneck. Similarly to a network firewall, more rules means more checking. You can quickly build a very detailed rule set that creates a performance problem. You need to balance the number of rules with performance. And just like a firewall or WAF, if your application changes queries on a regular basis, your rule set will need to adapt to avoid breaking the application. The real question is “Is this technology better?” The answer depends upon usage. For detection of insider misuse, data privacy violation, or hijacked accounts, either stateful inspection and behavioral monitoring will be a better choice. For databases that support a lot of ad hoc activity, content inspection is better. But for web applications, especially those that don’t add/change their database queries very often, this query analysis method is very effective for blocking injection attacks. Over and above the analysis capabilities, the handful of customers I have spoken with deployed the platform very quickly. And from the demos I have seen, the product’s interface is on par with the rest of the DAM providers. Secerno is not revolutionary and does not offer extraordinary advantages over the competition. It is a good technology and a very good fit for Oracle, because it fills the gaps they in their security portfolio. Just keep in mind that each Database Activity Monitoring solution offers a different subset of available analysis techniques, deployment models, and supporting technologies – such as WAF, Assessment and Auditing. And each vendor provides a very different experience – in terms of user interface quality, ease of management, and deployment. DAM is a powerful tool for your arsenal, but you need to consider the whole picture – not just specific analysis techniques. Share:

This morning Oracle announced that it has entered into an agreement to acquire Secerno, the UK-based Database Activity Monitoring firm. Oracle posted a FAQ on the acquisition with some generic data points. Terms of the deal have not been disclosed and, knowing Oracle, won’t be. Many of us in the security industry are chuckling at this purchase as Oracle – at least to customers – has been disparaging Database Activity Monitoring technologies as a whole and pushing Audit Vault as an equivalent solution. But when your database is Unbreakable™, maybe you don’t need a database firewall, eh? Seriously, DAM has been a hole in their security offerings for years, and after much blustering to the contrary, they have finally plugged the hole. And from the synergies of the platforms, I’d say they did a pretty good job of it. Key Points about the Acquisition Here are the most important top-level points: The deal is clearly about the security alerting and blocking features of Secerno. Oracle calls it a “Database Firewall”, and never says Database Activity Monitoring. Oracle sees Audit Vault as their DAM equivalent, and has heavily disparaged that market and the techniques used by DAM vendors. Customers really struggle with Oracle patching, which makes it very difficult to keep systems compliant and secure. Positioning Secerno as a stopgap to protect the database from particular exploits so you have time to patch is reasonable and appropriate. It’s also a good straight up security play. Secerno was always stronger on security than activity monitoring for compliance, which makes it more complementary to the existing Oracle product line and security messaging. Oracle may include this in Oracle Advanced Security, or keep it standalone. We’ll have to see, but based on the current physical architecture I’d bet on stand-alone for at least a few years. In terms of messaging, expect Audit Vault to remain the focus for building those audit trails, with Secerno positioned for real-time alerting and blocking. Expect to see Oracle market “Database Firewall” with “Zero False Positives”, but those claims overlook the real world difficulties in building and maintaining query rules. Let’s delve deeper into the specifics. What the Acquisition Does for Oracle Fills big technology gaps: Secerno provides Oracle a lot of security technology they did not have. Secerno includes real-time analysis not available from current Oracle products, which is a growing requirement – especially for customer-facing web applications. It also gives Oracle a security tool that offers genuine heterogenous database support for Oracle, Microsoft, and Sybase (IBM support is in beta). Oracle hates to admit it, but nearly all of their enterprise clients have several different databases in use, and customers want a common platform for security or compliance when possible. Secerno provides blocking capabilities – importantly before queries reach the database – to reduce DB load and risk. Secerno has a much better UI than Oracle Audit Vault, and hopefully Oracle will continue to use it rather than standardize on their own weaker UI. Prevention: Privately we have been calling Secerno a Query White Listing technology, as we think that better encompasses what they provide. “Database Firewall” is one of those throw-away marketing terms used by several DAM vendors, but fails to differentiate what Secerno provides. Yes, Secerno will block queries, and will do so before they get to the database, reducing processing and filtering load on the database engine. I’ll get into technology details later in this post, but Oracle now has a viable way to block many unwanted queries. Web Applications: Like it or not, web applications are a huge part of the Oracle database business, and auditing is totally inappropriate for securing web applications from things like SQL injection. This helps address Oracle’s repeated issues with patching and playing catch-up with vulnerabilities, finally helping prevent some attacks without totally disrupting business operations for database updates that applications don’t support. Circumvents a perception problem: Oracle Audit still has a serious perception problem, and correctly or not is considered a performance and operations burden. On paper, Oracle’s native audit trail can provide many of the same functions as other DAM and Auditing tools, but in practice Oracle Audi pales in the light of the competition – or even Audit Vault. This helps escape serious a perception problem for compliance and security adoption. What This Means to the DAM Market Validation: Let’s face it – when Oracle and IBM both make investments into Database Activity Monitoring, we are past wondering when DAM will be considered viable technology. Even though Oracle isn’t positioning this as DAM, Secerno did, and this serves as high-profile validation of the market. Business to be won: There were many unhappy IPLocks customers who Fortinet was unable to bring into the fold with their upgraded offerings. Some of Guardium’s business has been at risk for a while, and some of their resellers started looking for other relationships after the IBM purchase. Oracle’s customers have looked at – and in many cases purchased – other security products to close the gaps. Imperva still needs to do a better job of converting WAF customers to DB Security customers, and Application Security still needs to do a better job at holding onto the customers they already have. All this shows that the leader of this segment has yet to be determined, and there is a lot of potential business. One less vendor: Tizor went to Netezza. IPLocks went to Fortinet. Guardium went to IBM. Now Secerno to Oracle. That leaves Application Security and Imperva as the major database security providers out there, with Sentrigo the best of the smaller niche players in the market. EMC needs this technology next, perhaps followed by Symantec or McAfee, but the price of entry just increased. Investors: Secerno’s investors, Amadeus Capital Parners, must be happy. They did a logical reset and re-investment back in early 2008, a decision that was clearly the right one. They also had considerably less initial investment than the competitors in this space. While we do not

*Updated:** 8/25/2010 Storefront-Backtalk magazine had an interesting post on Too Much Encrypt = Cyberthief Gift. And when I say ‘interesting’, I mean the topics are interesting, but the author (Walter Conway) seems to have gotten most of the facts wrong in an attempt to hype the story. The basic scenario the author describes is correct: when you encrypt a very small range of numbers/values, it is possible to pre-compute (encrypt) all of those values, then match them against the encrypted values you see in the wild. The data may be encrypted, but you know the contents because the encrypted values match. The point the author is making is that if you encrypt the expiration date of a credit card, an attacker can easily guess the value. OK, but what’s the problem? The guys over at Voltage hit the basic point on the head: it does not compromise the system. The important point is that you cannot derive the key from this form of attack. Sure, you can you confirm the contents of the enciphered text. This is not really an attack on the encryption algorithm, nor the key, but poorly deployed cryptography. It’s one of the interesting aspects of encryption or hashing functions; if you make the smallest of changes to the input, you get a radically different output. If you add randomness (Updated: per Jay’s comments below, this was not clear; Initialization Vector or feedback modes for encryption) or even somewhat random “salting” (for hashing) we have an effective defense against rainbow tables, dictionary attacks, and pattern matching. In an ideal world we would do this. It’s possible some places don’t … in commodity hardware, for example. It did dawn on me that this sort of weakness lingers on in many Point of Sale terminals that sell on speed and price, not security. These (relatively) cheap appliances don’t usually implement the best security: they use the fastest rather than the strongest cryptography, they keep key lengths short, they don’t do a great job at gathering randomness, and generally skimp on the mechanical aspects of cryptography. They also are designed for speed, low cost, and generic deployments: salting or concatenation of PAN with the expiration date is not always an option, or significant adjustments to the outbound data stream would raise costs. But much of the article talks about data storage, or the back end, and not the POS system. The premise of “Encrypting all your data may actually make you more vulnerable to a data breach” is BS. It’s not an issue of encrypting too much, it’s in those rare cases where you encrypt in very small digestible fields. “Encrypting all cardholder data that not only causes additional work but may actually make you more vulnerable to a data breach” is total nonsense. If you encrypt all of the data, especially if you concatenate the data, the resulting ciphertext does not suffer from the described attack. Further, I don’t believe that “Most retailers and processors encrypt their entire cardholder database”, making them vulnerable. If they encrypt the entire database, they use transparent encryption, so the data blocks are encrypted as whole elements. The block contents are random so each has some degree of natural randomness going on because the database structure and pointers are present. And if they are using application layer or field level encryption, they usually salt alter the initialization vector. Or concatenate the entire record. And that’s not subject to a simple dictionary attack, and in no way produces a “Cyberthief Gift”. Share:

I will be presenting a webinar: “Understanding and Selecting a Database Assessment Solution” with Imperva this Wednesday, May 19th at 11am PST / 2pm EST. I’ll cover the deployment models, key features, and ways to differentiate assessment platforms. I’ll spend a little more time on applicability for compliance, as that is the key driver for adoption now, but cover other use cases as well. You can register and sign up for the webinar. As always, if you have questions you would like addressed, you can email me prior to the presentation. Share: