Login  |  Register  |  Contact
Thursday, July 01, 2010

Understanding and Selecting SIEM/LM: Integration

By Adrian Lane

They say that no man is an island, and in the security space that’s very true. No system is, either – especially those tasked with some kind of security management. We get caught up in SIEM and Log Management platforms to suck in every piece of information they can to help with event correlation and analysis, but when it comes down to it security management is just one aspect of an enterprise’s management stack. SIEM/Log Management is only one discipline in the security management chain, and must feed some portion of its analysis to supporting systems. So clearly integration is key, both to getting value from SIEM/LM, and to making sure the rest of the organization is on board with buying and deploying the technology.

For a number of enterprise IT management systems it is important to integrate with the SIEM/Log Management platform, ranging from importing data sources, to sending alerts, even up to participating in an IT organization’s workflow. We’ve broken the integrations up into inbound (receiving data from another tool) and outbound (sending data/alerts to another tool).

Inbound integration

  1. Security management tools: We discussed this a bit when talking about data collection, regarding the importance of broadening the number of data sources for analysis and reporting. These systems include vulnerability management, configuration management, change detection, network behavioral analysis, file integrity monitoring, endpoint security consoles, etc. Typically integration with these systems is via custom connectors, and most SIEM/LM players have relationships with the big vendors in each space.
  2. Identity Management: Identity integration was discussed in the last post on advanced features and is another key system for providing data to the SIEM/LM platform. This can include user and group information (to streamline deployment and ongoing user management) from enterprise directory systems like Active Directory and LDAP, as well as provisioning and entitlement information to implement user activity monitoring. These integrations tend to be via custom connectors as well.

Because these inbound integrations tend to require custom connectors to get proper breadth and fidelity of data, it’s a good idea to learn a bit about each vendor’s partner program. Vendors use these programs to gain access to the engineering teams behind their data sources; but more importantly devote the resources to developing rules, policies, and reports to take advantage of the additional data.

Outbound integration

  1. IT GRC: Given that SIEM/Log Management gathers information useful to substantiate security controls for compliance purposes, clearly it would be helpful to be able to send that information to a broader IT GRC (Governance, Risk, and Compliance) platform that is presumably managing the compliance process at a higher level. So integration(s) with whatever IT GRC platform is in use within your organization (if any) is an important consideration for deciiding to acquire of SIEM/Log Management technology.
  2. Help Desk: The analysis performed within the SIEM/Log Management platform provides information about attacks in progress and usually requires some type of remediation action once an alert is validated. To streamline fixing these issues, it’s useful to be able to submit trouble tickets directly into the organization’s help desk system to close the loop. Some SIEM/Log Management platform have a built-in trouble ticket system, but we’ve found that capability is infrequently used, since all companies large enough to utilize SIEM/LM also have some kind of external help desk system. Look for the ability to not only send alerts (with sufficient detail to allow the operations team to quickly fix the issue), but also to receive information back when a ticket is closed, and to automatically close the alert within the SIEM platform.
  3. CMDB: Many enterprises have also embraced configuration management databases (CMDB) technology to track IT assets and ensure that configurations adhere to corporate policies. When trying to ensure changes are authorized, it’s helpful to be able to send indications of changes at the system and/or device level to the CMDB for confirmation.

Again, paying attention to each vendor’s partner program and announced relationships can yield valuable information about the frequency of true enterprise deployment, as large customers demand their vendors work together – often forcing some kind of integration. It also pays to as vendor references about their integration offerings – because issuing a press release does not mean the integration is functional, complete, or useful.

—Adrian Lane

IBM gets a BigFix for Tivoli Endpoint Management

By Mike Rothman

IBM continues to be aggressive with acquisitions, grabbing BigFix today for an undisclosed amount. Given BigFix’s aspirations (they were moving toward a public offering), I’m a bit surprised the economics weren’t disclosed, but it was likely a decent sized deal.

IBM and BigFix have a fairly long history of working together, and strategically this deal makes a lot of sense – especially given that IBM’s Tivoli systems management offerings weren’t very competitive on the endpoint. Once we got past the “Smarter Planet” branding hogwash on the analyst conference call, the leverage of IBM/BigFix became apparent. First, BigFix always positioned itself as a platform, driven by content and their Fixlets: applications that plug into the platform. You have to figure the IBM Global Services folks are drooling a bit to finally control an endpoint management integration platform – and the billable hours to build thousands more Fixlets.

BigFix as a stand-alone company wasn’t a long-term option. Small companies don’t get to play in the platform space, not over long periods of time anyway. But hats off to the BigFix folks – they focused on bringing specific use cases to market to show the power of their platform and knock down some big enterprise deployments. On the other hand, IBM is strictly a platform player, so the idea of Big Blue rolling out a comprehensive endpoint management offering is a no-brainer.

If anything, this solves a big operational problem for IBM, given their 500,000+ employees around the world (they plan to eat their own dog food with an enterprise-wide deployment) and millions of endpoints managed through their outsourcing business. From that perspective, this is very much like the HP/Opsware deal a few years ago. Yes, the deal gets justified by the big opportunity to sell the software, but the internal operational leverage of the technology is a big sweetener (and likely a deal size multiplier).

Additionally, IBM needed to make a move to bolster their security product capabilities, which are getting a bit long in the tooth. They’ve seen the former ISS erode to irrelevance; they moved the ISS products into the Tivoli group, but it’s too little too late. With BigFix they ger an opportunity to bring a far more strategic offering into the bag. Symantec has this capability through their Altiris acquisition and EMC/RSA bought ConfigureSoft a while back to get better endpoint management. You have to wonder if McAfee was a player in this deal, because they’ve got a big hole in their offering around endpoint management.

Customer Impact

If you are a BigFix customer, you likely have mixed feelings. Now you get to deal with IBM, which can be a nightmare. And if you have a very heterogenous environment, over time that is at risk. Of course, both IBM and BigFix will maintain their commitment to supporting a heterogeneous world, but you figure IBM platforms will get priority for new features and Fixlets. That’s the way of the world.

IBM outsourcing customers should be tickled. If you can get an endpoint change request through the gauntlet of change orders, contract (re)negotiations, and the other roadblocks IBM puts in your way, they’ll actually have a slick way to make the change. This also adds a number of other cool service offerings (energy management, endpoint remediation, asset management, etc.) that may actually add value to your services relationship. Imagine that.

Obviously you’ll see all the competition, both big (Symantec, RSA, HP) and little (LanDesk, Lumension, Shavlik) throw some FUD (fear, uncertainty, and doubt) balloons your way during the procurement process. Clearly there will be some impact to the product roadmap, and likely support, as the newly wealthy BigFixers move on and Tivoli starts putting their imprint on company operations. If anything, you should be able to use the FUD as more leverage to get additional pricing and T&C concessions when negotiating your purchase or renewal.

Issues

Like any other deal, most of the risk is in integration. Can IBM maintain the people and continue to drive the product to take advantage of the leverage they just paid for? I can say I was impressed with the three-phase integration plan IBM presented during the analyst call. The first phase is to get more exposure for BigFix within the customer base and good things should happen. After that, they integrate with the existing Tivoli stuff from a product and console standpoint.

Given the existing relationship, the integration issues are somewhat manageable. That doesn’t mean they don’t exist or that IBM won’t screw it up – just ask ISS about that. But given the work already done to drive integration (you’ve got to figure the deal has been in the works for a while) and the existing partnership, they have done what they can to contain the risk.

Bottom Line

The only outstanding question is how much of a premium did BigFix cost? From almost every other standpoint the strategic rationale of this deal is strong and even the issues are not that big. This likely means other big Security/IT companies (think McAfee, BMC, Oracle, etc.) need to grab some real estate in the endpoint management space. So not only is this a good day for the folks at BigFix, but Shavlik, Lumension, and LanDesk (once their emancipation from Emerson goes through) are well positioned to be next.

—Mike Rothman

Know Your Adversary

By Mike Rothman

I spent some time on the road this week, and it was great to see some old friends, meet some new ones, come up to speed on some topics, and more than anything take some time to listen. With my head full of dancing fairies relative to what’s really going on out there, I was interested when I came across Jack Freund’s post on the RiskAnalysis blog called “Executives are not Stupid.” Jack leads off the discussion by mentioned that “You don’t fall into a job to run a company or a line of business.”

You rise to your level of incompetence.Actually in my experience, continually validated by my primary research, many executives are in over their heads. The Peter Principle is not only alive and well, it gets in the way of the security professional’s charter on a daily basis. Come on, don’t make like you’ve never asked yourself what kind of pictures said executive has on the CEO to keep falling upward. You know you have, and you are probably right. Success in corporate life isn’t just restricted to the talented, that’s for sure.

The lore has been known for years that to be good at security you have to think like a hacker. All that really means is that you have to understand the attacker’s motivations, get familiar with the tools they use, and use that knowledge to discover the path of least resistance (which tends to be the most significant attack vector). When we recommend that you systematically hack yourself, this is really to familiarize yourself with what the attacker sees.

The same goes for dealing with senior management. A lot of folks just get grumpy when a decision doesn’t go their way. They grumble about how senior management “doesn’t get it,” but in reality it’s a failure on our part to anticipate the (often obvious) reaction of the senior team. Most executives are, frankly, predictable. They act in their own best interests, always. And that means if you want to get anything done, you have to convince the executive that going down the path your suggest is in their best interest.

I know, this clearly involves political machinations and that is likely deplorable to many of you. It’s not my favorite thing to do, which is why I work with Rich and Adrian. But if you want the big title (or even a little title), part of that is playing the game. So you need to plan for success. That means before you pitch a senior exec on your pet project, you need to actively plan a strategy for lining up support. It’s not that hard, but it doesn’t happen by itself. You have to sit down and understand the playing field.

Start by asking yourself two questions, but you need to answer as the executive(s) rather than as yourself. And no, the questions do not include which new BMW you want or which Four Seasons you will visit on holiday.

  • How will this make my life better? You need to have a crisp understanding of why it’s in this executive’s best interest to support your project, and that usually gets down to two things: more money or making him/her look good. If you can position your project for either of these, you have a chance.
  • What is the risk? There is no risk without reward, so you need to really consider the downside for the executive. Where can this go wrong? How would this alienate him/her with peers or higher ups? Basically you have to build a threat model from the executive’s perspective. And you then you need to be able to overcome those objections, or he/she will kill your project. Guaranteed.

Building the threat model and overcoming the objections isn’t easy, which is why so many security folks don’t get what they want. Always remember, it’s not about protection or security. It’s about understanding the goals and success criteria for your organization and every executive that can say no. I know your senior executives aren’t necessarily adversaries, but since they can get in your way and derail your plans you need to map out a strategy to bring them to your side – or at least neutralize them.

And keep in mind that you will not win every battle. Sometimes they’ll still say no, regardless of your strategy or efforts. Keep each setback in context of the entire war, and move on to the next battle. Or decide it was more fun to configure firewalls. That’s always an option.

Photo credit: The Peter Principle: Why Things Go Wrong available on Amazon

—Mike Rothman

Tokenization: the Business Justification

By Rich

Justifying an investment in tokenization is actually two separate steps – first justifying an investment to protect the data, and then choosing to use tokenization.

Covering all the justifications for protecting data is beyond the scope of this series, but a few common drivers are typical:

  • Compliance requirements
  • Reducing compliance costs
  • Threat protection
  • Risk mitigation

We’ve published a full model (and worksheet) on this problem in our paper The Business Justification for Data Security.

Once you’ve decided to protect the data, the next step is to pick the best method. Tokenization is designed to solve a very narrow but pervasive and critical problem: protecting discreet data fields within applications, databases, storage, and across networks.

The most common use for tokenization is to protect sensitive key identifiers, such as credit card numbers, Social Security Numbers, and account numbers. Less commonly, we also see tokenization used to protect full customer/employee/personal records. The difference between the two (which we’ll delve into more in our architectural discussion) is that in the first case the tokenization server only stores the token and the sensitive field, while in the second case it includes additional data, such as names and addresses.

Reasons to select tokenization include:

  • Reduction compliance scope and costs: Since tokenization completely replaces a sensitive value with a random value, systems that use the token instead of the real value are often exempt from audits/assessments that regulations require for the original sensitive data. For example, if you replace a credit card number in your application environment with tokens, the systems using the tokens may be excluded from your PCI assessment – reducing the assessment scope and cost.
  • Reduction of application changes: Tokenization is often used to protect sensitive data within legacy application environments where we might previously have used encryption. Tokenization allows us to protect the sensitive value with an analogue using the exact same format, which can minimize application changes. For example, encrypting a Social Security Number involves not only managing the encryption, but changing everything from form field logic to database field format requirements. Many of these changes can be avoided with tokenization, so long as the token formats and sizes match the original data.
  • Reduction of data exposure: A key advantage of tokenization is that it requires data consolidation. Sensitive values are only stored on the tokenization server(s), where they are encrypted and highly protected. This reduces exposure over traditional encryption deployments, where cryptographic access to sensitive data tends to show up in many locations.
  • Masking by default: Since the token value is random, it also effectively functions as a data mask. You don’t need to worry about adding masking to applications, since the real value is never exposed (the exception being where even the token value could lead to misuse within your environment). Tokenization solutions do not offer as many formatting options to preserve value for reporting and analytics, but fully tokenized solutions provide greater security and less opportunity for data leakage or reverse engineering.

For the most part, the primary reason organizations select tokenization over alternatives is cost reduction: reduced costs for application changes, followed by reduced audit/assessment scope. We also see organizations select tokenization when they need to update security for large enterprise applications – as long as you have to make a lot of changes, you might as well reduce potential data exposure and minimize the need for encryption at the same time.


Understanding and Selecting a Tokenization Solution:

—Rich

Understanding and Selecting a Tokenization Solution: Introduction

By Rich

Updated: 06/30/2010

One of the most daunting tasks in information security is protecting sensitive data in (often complex and distributed) enterprise applications. Even the most hardened security professionals enters these projects with at least a modicum of trepidation. Coordinating effective information protection across application, database, storage, and server teams is challenging under the best of circumstances – and much tougher when also facing the common blend of legacy systems and conflicting business requirements.

For the most part our answer to this problem has been various forms of encryption, but over the past few years we’ve seen increasing interest in and adoption of tokenization.

Encryption, implemented properly, is one of the most effective security controls available to us. It renders information unreadable except to authorized users, and protects data both in motion and at rest. But encryption isn’t the only data protection option, and there are many cases where alternatives make more sense. Sometimes the right choice is to remove the data entirely.

Tokenization is just such a technology: it replaces the original sensitive data with unsensitive placeholders. Tokenization is closely related to encryption – they both mask sensitive information – but its approach to data protection is different. With encryption we protect the data by scrambling it using a process that’s reversible if you have the right key. Anyone with access to the key and the encrypted data can regenerate the original values.

With tokenization the process is not reversible. Instead we substitute a token value that’s only associated with the “real” data within a well-protected database. This token can even have the exact same format (size & structure) as the original value, helping minimize application changes. But the token is effectively random, rather than a scrambled version of the original data. The token cannot be compromised to reveal sensitive data.

The power of tokenization is that although the token value is usable within its native application environment, it is completely useless outside. So tokenization is ideal to protect sensitive identifying information such as credit card numbers, Social Security Numbers, and the other personally identifiable information bad guys tend to steal and use or sell on the underground market. Unless they crack the tokenization server itself to obtain the original data, stolen tokens are worthless.

Interest in tokenization has accelerated because it protects data at a lower overall cost. Adding encryption to systems – especially legacy systems – introduces a burden outside the original design. Making application changes to accomodate encrypted data can dramatically increase overhead, reduce performance, and expand the responsibilities of programmers and systems management staff. In distributed application environments the need to encrypt, decrypt, and re-encrypt data in different locations results in exposures that attackers can take advantage of. More instances where systems handle keys and data mean more opportunities for compromise. For example, one growing attack is the use of memory parsing malware: malicious software installed on servers and capable of directly accessing memory to pull encryption keys or data from RAM, even run without administrative privileges.

Aside from minimizing application changes, tokenization also reduces potential data exposure. When properly implemented, tokenization enables applications to use the token throughout the whole system, only accessing the protected value when absolutely necessary. You can use, store, and transact with the token without fear of exposing the sensitive data it represents. Although at times you need to pull out the real value, tokenization allows you to constrain its usage to your most secure implementations.

For example, one of the most common uses for tokenization is credit card transaction systems. We’ll go into more depth later, but using a token for the credit card number allows us to track transactions and records, only exposing the real number when we need to send a transaction off to the payment processor. And if the processor uses tokenization as well, we might even be able to completely eliminate storing credit card numbers.

This doesn’t mean tokenization is always a better choice than encryption. They are closely related and the trick is to determine which will work best under the particular circumstances.

In this series we’ll dig deep into tokenization to explain how the technology works, explore different use cases and deployment scenarios, and review selection criteria to pick the right option. We’ll cover everything from tokenization services for payment processing and PCI compliance to rolling your own solution for internal applications.

In our next post we’ll describe the different business justifications, and follow up with a high-level description of the different tokenization models. After that we’ll post on the technology details, deployment, use cases, and finally selection criteria and guidance.

If you haven’t figured it out by now, we’ll be pulling all this together into a white paper for release later this summer. Just keep this in mind: sometimes the best data security choice is to avoid keeping the data at all. Tokenization lets us remove sensitive data while retaining much of its value.

—Rich

Wednesday, June 30, 2010

Understanding and Selecting SIEM/LM: Advanced Features

By Adrian Lane

We’ve already discussed the basic features of a SIEM/Log Management platform, including collection, aggregation and normalization, correlation and alerting, reporting and forensics, and deployment architectures. But these posts cover the core functions, and are part of what each products in the space will bring to the table.

As markets evolve and vendors push to further differentiate themselves, more and more capabilities are integrated into the platforms. In the case of SIEM/LM, this means pumping more data into the analysis engine, and making engine smarter. The idea is to make 1+1 produce 5, as multiple data types provide more insight than a single source – that’s the concept, anyway. To be clear, having more data does not make directly the product any better. The only way to really leverage additional data is to build correlation rules and alerts and reports that utilize the extra data.

Let’s take a tour through some of the advanced data types you’ll see integrated into SIEM/LM platforms.

Flow

Network flow data is the connection records that stream out of a router or switch. These small and simple data files/streams typically list source, destination, and packet type. Flow data was really the first new data type which, when integrated with event and log data, really made the systems smarter. Flow data allowed the system to establish a baseline and scan for anomalous network traffic as the first indication of a problem.

An entire sub-market of network management – network behavioral analysis – revolves around analyzing and visualizing flow data to understand the traffic dynamics of networks, and pinpointing performance and capacity issues before they impact users. Many of the NBA vendors have been unsuccessfully trying to position their products in the security market; but in combination with events and logs, flow data is very useful.

As an example, consider a typical attack where a web server is compromised and then used as a pivot to further compromise an application server and the backend database server. The data needs to be exfiltrated in some way, so the attackers establish a secure pipe to an external zombie device. But the application server doesn’t typically send data to an external device, so flow data would show an anomalous traffic flow. At that point an administrator could analyze the logs, with correlated activity showing a new account created on the database server, and identifying the breach.

Could an accurate correlation rule have caught the reconnaissance and subsequent compromise of the servers? Maybe. But the network doesn’t lie, and at some point the attackers need to move the data. These types of strange network flows can be a great indicator of a successful attack, but remember strange flows only appear after the attack has occurred. So flow data is really for reacting faster to attacks already underway.

Even more powerful is the ability to set up compound correlation rules, which factor in specific events and flow scenarios. Of course setting up these rules is complicated and they require a lot of tuning, but once the additional data stream is in place, there are many options for how to leverage it.

Identity

Everyone wants to feel like more than just a number, but when talking about SIEM/Log Management, your IP address is pretty much who you are. You can detect many problems by just analyzing all traffic indiscriminately, but this tends to generate plenty of false positives. What about the scenario where the privileged user makes a change on a key server? Maybe they used a different device, which had a different IP address. This would show up as an unusual address for that action, and could trigger an alert.

But if the system were able to leverage identity information to know the same privileged user was making the change, all would be well, right? That’s the idea behind identity integration with SIEM/LM. Basically, the analysis engine pulls in directory information from the major directory stores (Active Directory & LDAP) to understand who is in the environment and what groups they belong to, which indicates what access rights they have. Other identity data – such as provisioning and authentication information – can be pulled in to enable advanced analysis, perhaps pinpointing a departed user accessing a key system.

The holy grail of identity integration is user activity monitoring. Yup, Big Brother lives – and he always knows exactly what you are doing. In this scenario you’d be able to set up a baseline for a group of users (such as Accounting Clerks), including which systems they access, who they communicate with, and what they do. There are actually a handful of other attributes that help identify a single user even when using generic service accounts. Then you can look for anomalies, such as an accounting clerk accessing the HR system, making a change on a sensitive server, or even sending data to his/her Gmail account. This isn’t a smoking gun, per se, but it does give administrators a place to look for issues.

Again, additional data types beyond plain event logs can effectively make the system smarter and streamline problem identification.

Database Activity Monitoring

Recently SIEM/LM platforms have been integrating Database Activity Monitoring (DAM), which collects very detailed information about what is happening to critical data stores. As with the flow data discussed above, DAM can serve up activity and audit data for SIEM. These sources not only provide more data, but add additional context for analysis, helping with both correlation and forensic analysis. Securosis has published plenty of information on DAM, which you can check out in our research library.

The purpose of DAM integration is to drive analysis deeper into database transactions, gaining the ability to detect patterns which indicate successful compromise or misuse. As a simple example, if a mobile user gets infected at Starbucks (like that ever happens!) and then unwittingly provides access to the corporate network, the attacker then proceeds to compromise the database.

The DAM device monitors the transactions to and from the database, and should see the attack traffic. At that point the admin must go to another system to figure out the issue with the rogue device. But if all the data is available within a single platform, the admin would be able to instantly know about the compromised device and remediate.

Additionally, powerful correlation rules can be set up to look for account changes and other significant events on certain servers, followed up by a data dump from the database (recorded by DAM), and a bulk file transfer to an external location (detectable in flow data). This is certainly getting closer to a smoking gun, if the attack scenarios are modeled and implemented as rules in the SIEM/LM.

Application Monitoring

Like DAM, some SIEM/LM platforms are climbing up to the application layer by ingesting application logs, as well as performing simple content analysis on specific application types – typically email or web traffic. Again, baseline models can identify how applications should behave; then alerts can be set up for behavior which is not normal.

The problem with application monitoring is the amount of work required to get it right. Each application works differently in each environment, so significant tuning is required to get the rules right and tighten thresholds enough to provide relevant alerts. With the number of application in a typical organization, getting useful coverage within an environment takes substantial time and resources.

But over time this capability will continue to improve and become much more useful in practice. We expect that to take another 12-18 months.

Configuration Monitoring

Another data type useful for SIEM/LM integration is configuration data. This means many different things to different folks, so let’s level set a bit. We are referring to the configuration settings for security, applications, network, and computing devices. Most attacks involve some type of configuration change, whether it’s a service turned on or off, a new user added, a new protocol allowed, or a destination address added. Monitoring for these changes can again provide key hints to an attack in progress.

This integration can happen with the SIEM/LM platform directly collecting and monitoring the configurations (many of the vendors can monitor network and security device configurations) or by taking an alert or log stream from a standalone configuration monitoring product. Either way works, so long as the correlation rules and reports are built to take advantage of the configuration data.

Let’s run through a quick scenario. In the event of an attack on a retailer’s POS system, events would show reconnaissance activity on a store wireless network, which happens frequently and so shouldn’t trigger any alarms. The attacker than breaks the WEP key and gains access to the POS network, then compromising the POS devices, which run on an un-patched version of embedded Windows XP. Yes, I know this organization deserves to be pwned for using WEP and unpatched XP, but indulge me a bit. None of this would necessarily be caught through typical event logs.

But then the attacker enable FTP on the POS terminal, which would change the configuration and be detected by configuration monitoring. So the admin can investigate FTP being active on a POS device, which indicates badness. Combine that with other event and logging activity, and a case for further investigation can be made – which is the point of having the SIEM/LM platform in the first place.

File Integrity Monitoring

The last data type we’ll discuss is file integrity data. This involves monitoring for changes on key system files such as the IP stack. If one of these files changes (and it’s not traceable to a legitimate patching), it usually indicates some kind of unauthorized activity. So this data is similarly useful for helping to narrow the scope of analysis for a security analyst.

If the analyst sees system files changing on a critical server, in combination with strange network flows, other configuration changes, and IDS alerts, that’s a good indication of a successful attack. Remember, it isn’t necessary to find a smoking gun. SIEM/LM is useful if it can make us a bit smarter and enable a security analyst to react faster to an attack.

Direct or Indirect Integration?

One of the ways vendors try to differentiate is by whether their product takes the data in directly and does the analysis within the SIEM/LM platform, or partners with leading vendors of standalone solutions – such as NBA or configuration monitoring. We aren’t religious one way or the other.

There are advantages to direct integration – all the data is in one location, which facilitates forensic investigation; this may also enable more detailed correlation rules and compliance reports. On the other hand, a standalone NBA system is more useful to the network administrator, at the expense of fewer capabilities built into the SIEM. If it’s the network administrator’s budget they will buy NBA, and the security team will get alerts. Either way is fine, since it’s about making the SIEM/LM smarter and focusing investigations.

Additional Data = More Complexity

As we described in the series introduction, making SIEM/LM work is a fairly complicated endeavor, and that’s just dealing with logs and events. When you add a couple or more additional data types, you multiply the number of rules and reports the system can generate. Couple that with enrichment and activity profiles, and you have seriously increased complexity. That can be positive (by supporting broader analysis) as well as negative (because tuning and performance become bigger issues), so be careful what you wish for.

Ultimately, the use cases need to drive the advanced features needed during the procurement process. If you are just trying to meet a compliance automation requirement, then flow data may not be that useful and shouldn’t weigh heavily in the vendor analysis. But if you are trying to gain operational efficiencies, then something like configuration monitoring should allow your analysts to kill both birds with the same platform, so the data type becomes more important.

—Adrian Lane

Incite 6/30/2010: Embrace Individuality

By Mike Rothman

I still go see a lot of live music. Yes, it’s a luxury, but I’d rather give something else up than my handful (OK, maybe two handfuls) of shows every year. On Monday night we saw Sting with his big orchestra. It was definitely a more mellow show than when we saw him a few years ago with his band (right, The Police), but it was a good show nonetheless.

We are all individuals -- to a point. I usually go to shows with the Boss and we each have different things that we like and don’t like about live music. Over the past few years we’ve learned to accept each other’s show angst. She likes to sit close and sometimes when the budget and availability work out, we get decent seats.

In the event we don’t get close, she’s usually looking for an opportunity to move up. That gives me angst. Bordering on paranoia. When I’m in someone else’s seat I’m figuring each person who walks by wants their seats back and will probably hit me with a bat. I know, it’s not logical, but it causes me angst. It kills my proverbial show buzz.

The Boss has no irrational seat squatting fear, so she just waits to be ejected and is cool with that. But she’s got show issues too. It makes her nuts when someone around us is talking. I mean nuts. I should call her Ms. Shush. Since she’ll usually just tell them to uh, quiet down. She does have a point in that these people pay a hundred bucks to go to a show and then talk about their goiters or sports teams or some asshat at work. Go figure. But the extraneous noise doesn’t bother me. I focus on the performer and tune everything else out.

I could get annoyed that she’ll disappear for most of a show and meet me later if she gets a better seat. And she could get annoyed that the chatter doesn’t bother me. But that’s not productive. Now we know each other’s angsts and we accommodate. I let her go walkabout and if she does stay in our seats, I’ve become a burgeoning Mr. Shush because I know her experience is better if everyone shuts their traps.

And it works for us. But only if you embrace your partner’s individuality and learn to roll with it. Maybe I have learned something after 13+ years of marriage.

– Mike.

Photo credits: “Individuality Redux” originally uploaded by spaceamoeba


Recent Securosis Posts

  1. Friday Summary: June 25, 2010
  2. Understanding and Selecting a Tokenization Solution: Introduction
  3. Are Secure Web Apps Possible?
  4. NSO Quant: Manage Firewall Process Map
  5. NSO Quant: Manage IDS/IPS Process Map
  6. Adrian and Rich are wrapping up DB Quant

Incite 4 U

  1. Toothless FTC ‘Settles’ with Twitter – So it seems Twitter got a slap on the wrist recently from the Federal Trade Commission for misleading consumers about protecting their privacy. The Twitter folks settled to make the problem go away, which was the right thing to do. Twitter is now barred for 20 years “from misleading consumers about the extent to which it maintains and protects the security, privacy, and confidentiality of nonpublic consumer information.” That’s a relief. And they need to be subjected to a security program review every other year for 10 years. Again, what major service provider doesn’t do this? In the article it does talk about some stuff that Twitter was (or wasn’t) doing, which are good practices. Like requiring strong admin passwords and not allowing administrators to store those passwords in their personal email. Duh. Anyhow, the FTC getting involved is fine, but if they want organizations to be more serious about privacy, they need more impactful consequences. – MR

  2. Assured Integrity on Bogus Data – Richard Bejtlich’s post on Dealing with Security Instrumentation Failures, along with the referenced articles on Si(EM)lent Witness hits on a trifecta of weaknesses in security monitoring devices at large: dropped or missing events, capturing only one side of a conversation, and touting the integrity of an already suspect data stream. In everything from IDS to DAM, dropped transactions are a real problem. Network monitoring that captures a request but fails to capture the response is a real problem. Both receive hand-waves from vendors and surprisingly from security practitioners as well, who assume the other 98% of events is enough. But have they quantified the loss, or the percentage of records that are missing? The percentage that are missing a portion of the data? Examine carefully the claims of SIEM, DAM, and other event storage vendors that the data is totally secure – privacy and integrity are typically 100% assured. But the stream before it arrives at its destination? Suspect! I used to play the injection game, throwing garbage statements on the wire that were completely ignored by the application, but picked up by the monitor because it had the right IP and port. Since they failed to collect response codes, this counted as legit traffic. I am not saying that you can necessarily do anything about it, but give it some thought, and have some test cases to verify how your tools handle them, or what the packet loss expectancy really is. – AL

  3. A Different Kind of Disclosure – We all know the disclosure debate will never end. It’s basically religion on all sides; with few willing to change their positions and little more than anecdotal evidence available, you can spin it however you want. But I think we can all agree that no one wants to find out about a vulnerability like WellPoint did. A customer figured out she could see others’ records by manipulating the URL (yes, about the most basic vulnerability a web application can have). Instead of reporting it to WellPoint she called her lawyer. WellPoint found out they were vulnerable when she sued them for breach of privacy. Then again, it seems the exposure may have mostly been limited to her and her lawyers poking around. WellPoint fixed the problem in 12 hours, and I’ll be curious to see whether they counter-sue or pursue criminal charges. Or whether the FBI busts in and arrests her on drug charges. – RM

  4. The Location Middle Ground – Although I have embraced some social networking stuff, I still consider myself a Luddite, and I’m OK with that. When I was recently at my college reunion, a friend was all into FourSquare, broadcasting his whereabouts to the Interwebs. I don’t get it. First off, I don’t want anyone to know where I am at any given time – it’s my business if I want to work at a Starbuck’s or a park or my home office. But for some aspects of location, I’m not sure how we lived before mobile phones and GPS. I mean, how else would you figure out where the closest Baja Fresh is in a new city? But privacy is still a major exposure, as pointed out in a recent NetworkWorld post. How are these companies using that data? And what’s to stop someone from extracting a crapload of stuff from FourSquare or Google or anywhere else, which could be used for who knows what? So as opposed to most 20-somethings today, who don’t seem to care about privacy, I’ll keep my location to myself, thank you very much. – MR

  5. A Small Exhaust Port, Just above the Main Port – A few years ago I gave a presentation on Web 2.0 (whatever that means) security. One of the issues I highlighted was inclusion of third party code/functionality. You may not realize it, but I’d say 99.999% of you have some sort of external code running through your site; anything from Google Analytics to advanced JavaScript libraries hosted elsewhere. I know this because I block a heck of a lot of it using various browser plugins. This inclusion is a very common practice, but means you are funneling someone else’s programming right to your customers via your site. One thing I hadn’t thought about for that presentation is that when you perform a vulnerability assessment against your own site, the odds are you can’t really scan the embedded code, since it’s running someplace else that might consider your scan an attack. WhiteHat Security ran into this problem even though they are vulnerability assessment experts. Jeremiah does an amazing job of disclosing their (minor) security foible, why it happened, and the limits of assessing external code. For the record, that’s one reason we try and host everything on our site, mirroring the code locally. – RM

  6. Dealing with the New Workforce – Our job as security professionals is to make sure the sensitive data within our organizations remains safe without adversely impacting how business operates (too much). But we can certainly get to the point of being a bit aggressive in our recommendations. I’m with the Imperva folks, as they point out some good recommendations from SecureWorks about protecting financial transactions against attacks like the Zeus Trojan, but I agree that others – like using a dedicated machine/VM for online banking – just won’t happen much because they’re too much of a hassle. But that’s not my point here – it’s that our workforce is changing and that means our protection strategies must change too. As a recent survey from Cisco shows, our new recruits are likely to work around our security controls, and will leave if we don’t let them do what they want. It’s not good or bad, it just is. So the idea of traditional command and control is out the window. Instead we focus on reacting faster/better and containing the damage, and grumble about how those crazy kids are screwing everything up. – MR

  7. Killing Innovation, One Startup at a Time – I spent a weekend earlier in the year ripping most of my CDs into iTunes. With Apple Lossless encoding it took about 170gb of space. I realized then that when I buy a Mac mini to become a music server, I will need to move all that content over. I was thinking about how cool it would be if I could just put the library in Dropbox and share it to any device. It appears that someone else had the idea, as mSpot is offering a service to do half of it. For me that would mean some $28.00 a month(!!!) just to store my own music. Plus it only supports one device, and I have 3 computers and four devices I want to use. I started thinking about the security aspects when I read the bottom of their press release: “The Recording Industry Association of America calls cloud-based music servers ‘an exciting development in the market place’”. Yeah, provided they can make money and not worry about security. What happens when people XSS their site and start grabbing other libraries? How exciting will it be when not just a single CD is stolen, but a huge music library? Odds are that if mSpot’s pricing and service model don’t kill them, the RIAA will, as soon as they get hacked. – AL

  8. As Things Move Faster, Standards Slow down – Last week, the PCI Security Standards Council announced they were changing the standards timeline (PDF), basically lengthening the time between updates to the PCI-DSS from two years to three years. That’s a relief, since we all know the rate of technology adoption and emergence of new attack vectors is slowing down accordingly. Not. The logical part of my brain understands that many retailers have lots of stores and it’s hard to change things quickly enough to even keep up with the current two year cycle. Then the pragmatic part remembers that my credit card number has been compromised at least 3 times that I know about (involving new card issuance), and I lose my empathy for the ‘poor’ retailers. Actually the truth is somewhere in the middle – the DSS is pretty stable at this point and shops adhering to the 12 requirements are in decent shape. Yes, they can get pwned, but that goes for anyone. And this gives us another opportunity to stress the fact that any standard/guidance/regulation is going to the lowest common denominator for your security posture. If you think you are done once you get the stamp, you are sorely mistaken. – MR

—Mike Rothman

Tuesday, June 29, 2010

Understanding and Selecting SIEM/LM: Data Management

By Adrian Lane

We covered SIEM and Log Management deployment architectures in depth to underscore how different models are used to deal with scalability and data management issues. In some cases these deployment choices are driven by the underlying data handling mechanism within the product. In other words each platform stores and manages data differently – these decisions have significant impact on product scalability, data management, and reporting & forensics capabilities. Here we discuss the different internal data storage models, with advantages and disadvantages of each.

Relational Database

In the early days of this technology, most SIEM and log management systems were built on relational database engines to store events and log records. In this model the SIEM platform maps data attributes from each data source into database columns, so each event is stored in a single database row. There are numerous advantages to this model, including:

  • Data Validation – As data is inserted into the column, the database verifies data type and range settings. Integrity check failures indicate corrupted files and are omitted from the import, with notification to administrators.
  • Event Consistency – An event from a Cisco router now looks just like an event from a Juniper router, and vice-versa, as events are normalized before being stored in the table.
  • Reporting – Reports are easier to generate from validated data columns, and the database can format data when generating the report. Reports run far faster thanks to column indices, effectively filtering and ordering events.
  • Analytics – An RDBMS facilitates complex queries across all available attributes, inspected content, and correlation.

This model for data storage has fallen out of favor due to the overhead of data insertion: as each row is inserted the database must perform the checks and periodically rebuild indices. As daily event volumes scaled from millions to hundreds of millions and billions, this overhead became problematic and resulted in significant scalability issues with SIEM offerings built on RDBMS.

Further, data that does not fit into the tables defined in the relational model is typically left out. Unless there is some other method to maintain the fidelity and integrity of the original event records, this is problematic for forensics. This “selective memory” can also result in data accuracy issues, as truncated records may not correlate properly and can hamper analysis.

As a result SIEM/LM architectures based on RDBMS are waning, as products in this space re-architect their backend data stores to address these issues. On the other hand, RDBMS storage is not totally dead – some vendors have instead chosen to streamline data insertion, basically by turning off some RDBMS checks and integrity verification. Others use an RDBMS to supplement a flat file architecture (described below), leveraging the advantages above for reporting and forensics.

Flat File

Flat files, or just ‘files’, are now the most common way to store events for SIEM and Log Management. Files are serve as a blank canvas for the vendor; as they can introduce any structure they choose to help define, format, and delineate events. Anything that helps with correlation and speeds up future searches is included, and each vendor has their own secret sauce for building files. Each file typically contains a day’s events, possibly from a single source, with each event clearly delineated. The files (in some cases each event) can be tagged with additional information – this is called “log enrichment”. These tags offer some of the contextual benefits of a relational database, and help to define attributes. Some even include a control structure similar to VSAM files. The events may be stored in their raw form, or be normalized prior to insertion. Flat files offer several advantages.

  • Performance – Since normalization (to the degree necessary) happens before data insertion, there is very little work to be performed prior to insertion compared to a relational database. Data is stored as quickly as the physical media can handle, and often available immediately for searching and analysis.
  • Flexibility – Stored events are not limited to specific normalized columns as they are in a relational database, but can take any form. Changes to internal file formats are much easier.
  • Search – Searches can be performed without understanding the underlying structures, using simple keyword search. At least one log management vendor provides a Google-style search capability across data files. Alternately, search can rely upon tags and keywords established by the vendor.

The flat file tradeoffs are twofold. First, any data management capabilities – such as indexing and data integrity – must be built from scratch by the vendor, since no RDBMS capabilities are provided by the underlying platform. This means the SIEM/LM vendor must provide any needed facilities for data integrity, normalization, filtering, and indexing. Second, there is an efficiency tradeoff. Some vendors tag, index, and normalize prior to insertion; others initially record raw events, later re-reading the data in order to normalize it, and then rewrite the reformatted data. The later method offers faster insertion, at the expense of greater total storage and processing requirements.

The good news is that a few years ago most vendors saw the scalability wall of RDBMS approaching, and began investing in their own back-end data management environments. At this point many platforms feature purpose-built high-performance data stores, and we believe this will be the underlying architecture for these products moving forward.

Of course, we don’t live in an either/or world, so many of the platforms combine some RDBMS capabilities with flat file aspects. Yes, the answer can be ‘both’.

—Adrian Lane

Friday, June 25, 2010

DB Quant: Manage Metrics, Part 3, Change Management

By Rich

Believe it or not, we are down to our final metrics post! We’re going to close things out today with change management – something that isn’t specific to security, but comes with security implications.

Our change management process is:

  1. Monitor
  2. Schedule and Prepare
  3. Alter
  4. Verify
  5. Document

Monitor

Variable Notes
Time to gather change requests
Time to evaluate each change request for security implications

Schedule and Prepare

Variable Notes
Time to map request to specific actions/scripts
Time to update change management system
Time to schedule downtime/maintenance window and communicate

Alter

Variable Notes
Time to implement change request

Verify

Variable Notes
Time to test and verify changes

Document

Variable Notes
Time to document changes
Time to archive scripts or backups

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking
  35. DB Quant: Protect Metrics, Part 4, WAF

—Rich

DB Quant: Manage Metrics, Part 2, Patch Management

By Adrian Lane

Continuing with management process metrics, we move into Patch Management. The specified process is sufficiently granular that we do not need to break these steps apart to capture the appropriate metrics as we have done with previous tasks. The vast majority of metrics will be amounts of time, with only sunk costs needed for database licensing or maintenance fees to acquire the patch and associated documentation.

<

div class=”bodyTable”>

Patch Management

Variable Notes
Monitor: Time to monitor for patch releases/advisories i.e. sift through patch release notices to identify what you need
Acquire: Time to obtain patch and documentation Optional costs for vendor support/maintenance
Evaluate: Time to perform initial ‘paper’ evaluation i.e. How does this affect the database? Are workarounds advisable?
Prioritize & Schedule: Time to coordinate resources for testing and deployment Include people and machines needed, with relative priorities
Test & Certify: Time to perform tests
Optional: Cost of test servers
i.e. verify patch fixed what it was supposed to and did not break anything else
Create Deployment Package: Time to package certified version i.e. Pull together certified patch revisions, documents and config changes
Deploy: Time to install the patch
Confirm Deployment: Time to verify patches were deployed Verify patches installed without error. Run sanity checks on database functions
Clean up: Time to clean up failed installs; time to clean up temp files i.e. remove temp files, failed installs, uncertified patches, logs, etc.
Document: Time to document changes Record changes, archive certified patch bundle, update internal revisions guide

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking
  35. DB Quant: Protect Metrics, Part 4, WAF
  36. DB Quant: Manage Metrics, Part 1, Configuration Management

—Adrian Lane

Friday Summary: June 25, 2010

By Adrian Lane

Thursday was totally shot. I wasted the entire day standing around. Eight hours and twenty nine minutes standing in line. I got in line at 5:50 AM and did not get back in my car until 3:00.

Yep, it was Apple iPhone day. And I did not have a reservation.

If you like people-watching, this is about as much fun as you will ever have. There were some 700 people at the mall by 6:30 AM. Close to me in line were two women with infants, and they were there all day. There were small children with their grandparents. The guy next to me had a shattered foot from a recent car accident. There were people calling their bosses, not to call in sick, but to tell them they were taking the day off to buy iPhones. These people were freakin’ dedicated.

I have not stood in line for any length of time since 1983, trying to get a good seat for Return of the Jedi. I have not stood in line without knowing whether I would get what I was there for since the Tutankhamun exhibit in, what, 1979? This is not something I do, but I wanted the phone. And actually I did not want the ‘phone’, but everything else. I wanted a (mostly) secure way to get email on the road. I wanted a mobile device to surf the web. I wanted a way to find Thai food. I wanted a better camera. I wanted a way to get directions when traveling. I wanted to have music with me. I wanted to access files in Dropbox whenever and wherever. And the BlackBerry did none of these thing well, if at all. Plus, as a device, the BlackBerry is a poorly-engineered turd in comparison. I was just done with it, and I wanted the iPhone, and I wanted it before Black Hat.

So there I stood, for eight and a half hours, holding a place in line for a guy with a broken foot so he could sit on the mall couch.

I have to say the Apple employees were great. Every 30 minutes they brought us water and Starbucks coffee. Every 15 minutes they brought snacks. They sent employees into the line to chat. They brought sample phones and sat with us, in line, to demo the differences. They thanked us for sticking it out. They asked us if we needed anything, holding places in line and bringing food. They took care of every part of the transaction, including dealing with AT&T and their inability to process credit cards without dialing up Equifax. Great products and great service … it’s like I was transported back in time to an age when those things mattered.

All in all I am glad I waited it out and got my phone. Camera is amazing. Display is crystal-clear. The phone does not have the hideous ‘pops’ in audio that blow my ears out, or randomly shut off for 20 seconds like the BlackBerry. And the FaceTime feature works really well, for what it’s worth. Would I do it again? Would I stand there for 8.5 hours? Ask me in another 25 years.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Project Quant Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. I was going to call Mike out for having male menopause, bu this week’s best comment goes to LonerVamp for taking the high road in response to Security Incite: Competitive Fire.

@Mike: Amen! Play the game the makes you happy and you win. Who knows, maybe for some of those guys it’s no win, no booty!

RE: Cyber-insurance: Yikes. What if the PCI Council offered insurance. They’d say something like, meet these checklist requirements. If you meet these requirements and get hacked, we’ll pay you out. If you say you meet these requirements, but get hacked due to not truly meeting these requirements, you don’t get paid out. The problem is this leads down the road of the PCI Council being your consultants and managed services provider, because you need to be meeting those requirements constantly. Not just during the audit week. It doesn’t help that few orgs know what data they even have let alone know what they’re doing to protect it appropriately. Cyber-insurance stills feels about as useful as Lifelock, to me.

—Adrian Lane

Thursday, June 24, 2010

Are Secure Web Apps Possible?

By Mike Rothman

We security folks are a tough crowd, and we have trouble understanding why stuff that is obvious to us isn’t so obvious to everyone else. We wonder why app developers can’t understand how to develop a secure application. Why can’t they grok SDL or run a damn scanner against the application before it goes live? Q/A? Ha. Obviously that’s for losers. And those sentiments aren’t totally misplaced. There is a tremendous amount of apathy regarding software security, and the incentives for developers to do it right just aren’t there.

But it’s not all the developers fault, because for the most part secure coding is a dream. Yeah, maybe that’s harsh and I’m sure the tool vendors will be hanging me in effigy soon enough, but that’s how it seems to me. Says the guy who hasn’t developed real code for 18+ years and leaves the application security research to folks (like Adrian) who are qualified to have an opinion. But not being qualified never stopped me from having an opinion before.

I come to this conclusion after spending some time trying to digest a post by Errata Security’s Rob Graham on the AT&T iPad hack. Rob goes through quite a few application security no-nos, quoting chapter and verse, pointing them out in this rather simple attack.

This specific attack vector doesn’t appear in the OWASP Top 10 list, nor should it. But it underscores the difficulty of really securing an application and the need to not just run a scanner against the code, but to really exercise the business logic before turning the app loose on the world.

Rob’s post talks about information leakage, security via obscurity, the blurring line between internal and external, and other ways to make an application do unintended things, usually ending in some kind of successful attack.

So does that mean we give up, which seemed to be one of the messages from the Gartner show this week (hat tip to Ed at Securitycurve)? Not so much, but we have to continue aggressively managing expectations. If you have smart guys like Rob, RSnake, or Jeremiah beat the crap out of your application, they will find problems. Then you’ll have an opportunity to fix them before the launch. In a perfect world, this is exactly what you would do, but it certainly isn’t the cheapest or fastest option.

On the other hand, you can run a scanner against the code and eliminate much of the lowest-hanging fruit that the script kiddies would target. That’s certainly an option, but the key to this approach is to make sure everyone knows a talented attacker specifically targeting your stuff will win. So when an attack not explicitly mentioned in your threat model (like the AT&T/iPad attack) happens, you will have to deal with it. And if you have some buddies in the FBI, maybe you can even get the hacker arrested on drug charges…

Or you could do nothing like most of the world, and seem surprised when a 12-year-old in Estonia sells your customers on a grey-market website.

To think we can really develop secure web applications is probably a pipe dream – depending on our definition of ‘secure’, obviously. But we certainly can make our apps more secure and outrun our slower competitors, if not the bear. Most of the time that’s enough.

—Mike Rothman

Wednesday, June 23, 2010

DB Quant: Manage Metrics, Part 1, Configuration Management

By Rich

We are finally entering the last phase of the database security process – Manage. Now we switch our focus from assessment and installation of security controls to ongoing management – keeping our systems up to date, properly configured, and (relatively) free from known vulnerabilities.

Our configuration management process is:

  1. Plan
  2. Assess
  3. Mitigate
  4. Verify
  5. Document

We changed “Control” from our initial post to “Mitigate”.

Plan

Variable Notes
Time to map database to configuration standard Developed in the Planning phase
Time to determine, approve, and document exceptions to the standard Individual databases may need exceptions to general standards

Assess

Variable Notes
Time to assess configuration This is the ongoing process of assessing the configuration, which should be run on a schedule, as opposed to the assessment run in the Discovery phase. Note that if you already have an ongoing discovery process, that covers this step.

Mitigate

Variable Notes
Time to adjust the configuration of the system to address violations

Verify

Variable Notes
Time to re-test and validate configuration updates

Document

Variable Notes
Time to document changes
Time to update baseline settings

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking
  35. DB Quant: Protect Metrics, Part 4, WAF

—Rich

The Open Source Database Security Project

By Adrian Lane

I am thinking about writing a guide to secure open source databases, including verification queries. Do you all think that would be useful?

For the most part, when I write about database security, I write about generic approaches that apply to all database platforms. I think this is helpful for database managers, as well as security and IT professionals who have projects that span multiple database types. When writing the Database Security Fundamentals series, my goal was to provide a universal checklist of the database security basics that anyone with basic DBA skills could accomplish in a week. DBAs who work in large enterprise may have established guidelines, but small and medium sized firms generally don’t, and I wanted the series to provide an awareness on what to look for and what to do. I also find that mainstream Oracle DBAs tune out because I don’t provide specific queries or discuss native features.

The downside is that the series covers what to do, but not how to do it. By taking a more abstract look at the problems to be solved across security and compliance, I cannot provide specific details that will help with Oracle, Sybase, Teradata, PostgreSQL, or others – there are simply too many policies for too many platforms for me to sufficiently cover. Most DBAs know how to write the queries to fulfill the policies I outlined. For the non-DBA security or IT professional, I recognize that what I wrote leaves a gap between what you should do and how to do it. To close this gap you have a couple of options:

  1. Acquire tools like DAM, encryption, and assessment from commercial vendors
  2. Participate on database chat boards and ask questions
  3. RTFM
  4. Make friends with a good DBA

Yes, there are free tools out there for assessment, auditing, and monitoring. They provide limited value, and that may be sufficient for you. I find that the free assessment tools are pretty bad because they usually only work for one database, and their policies are miserably out of date. Further, if you try to get assessment from a commercial vendor, they don’t cover open source databases like Derby, PostgreSQL, MySQL, and Open Ingres. These platforms are totally underserved by the security community but most have very large installed user bases. But you have to dig for information, and cobble together stuff for anything that is not a large commercial platform.

So here is what I am thinking: through the remainder of the year I am going to write a security guide to open source databases. I will create an overview for each of the platforms (PostgreSQL, Derby, Ingres and MySQL), and cover the basics for passwords, communications security, encryption options, and so forth, including specific assessment polices and rules for baselining the databases. Every week I’ll provide a couple new rules for one platform, and I will write some specific assessment policies as well. This is going to take a little resourcefulness on my part, as I am not even sure my test server boots at this point, and I have never used Derby, but what the heck – I think it will be fun. We will post the assessment rules much like Rich and Chris did for the ipfw Firewall Rule Set.

So what do you think? Should I include other databases? Should I include under-served but non-open-source such as MS Access and Teradata? Anyone out there want to volunteer to test scripts (because frankly I suck at query execution plans and optimization nowdays)?

Let me know because I have been kicking this idea around for a while, but it’s not fully fleshed out, and I would appreciate your input.

—Adrian Lane

DB Quant: Protection Metrics, Part 4, Web Application Firewalls

By Adrian Lane

Web Application Firewall deployment metrics are next up in the protection phase. This process is somewhat truncated compared to our other deployment processes, as the database administrator is tasked with only a subset of the overall effort that goes into WAF deployment. Regardless, there is a lot of work to be done for policy development and testing, and the process will be repeated many times over.

Our WAF deployment process is:

  1. Identify
  2. Profile
  3. Test
  4. Review
  5. Document

Identify

Variable Notes
Time to identify which databases are part of web applications

Profile

Variable Notes
Time to gather application query and parameter profiles i.e., What does the web application send to the database? Provide to the WAF team to generate rules/policies.

Test

Variable Notes
Time to analyze pre-deployment test results
Optional: time to retest

Review

Variable Notes
Variable: periodically review logs for failures e.g., check to see if rules broke any functionality
Variable: repeat Investigate task to adjust rules i.e., failed tests or policies need to be fixed
Time to investigate and remediate incidents WAF administrators should be managing most incidents, but DBAs are often involved for investigation and remediation of problems beyond rule failures

Document

Variable Notes
Time to document WAF rules

Other Posts in Project Quant for Database Security

  1. An Open Metrics Model for Database Security: Project Quant for Databases
  2. Database Security: Process Framework
  3. Database Security: Planning
  4. Database Security: Planning, Part 2
  5. Database Security: Discover and Assess Databases, Apps, Data
  6. Database Security: Patch
  7. Database Security: Configure
  8. Database Security: Restrict Access
  9. Database Security: Shield
  10. Database Security: Database Activity Monitoring
  11. Database Security: Audit
  12. Database Security: Database Activity Blocking
  13. Database Security: Encryption
  14. Database Security: Data Masking
  15. Database Security: Web App Firewalls
  16. Database Security: Configuration Management
  17. Database Security: Patch Management
  18. Database Security: Change Management
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2
  21. DB Quant: Planning Metrics, Part 3
  22. DB Quant: Planning Metrics, Part 4
  23. DB Quant: Discovery Metrics, Part 1, Enumerate Databases
  24. DB Quant: Discovery Metrics, Part 2, Identify Apps
  25. DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment
  26. DB Quant: Discovery Metrics, Part 4, Access and Authorization
  27. DB Quant: Secure Metrics, Part 1, Patch
  28. DB Quant: Secure Metrics, Part 2, Configure
  29. DB Quant: Secure Metrics, Part 3, Restrict Access
  30. DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring
  31. DB Quant: Monitoring Metrics, Part 2, Audit
  32. DB Quant: Protect Metrics, Part 1, DAM Blocking
  33. DB Quant: Protect Metrics, Part 2, Encryption
  34. DB Quant: Protect Metrics, Part 3, Masking

—Adrian Lane