Login  |  Register  |  Contact
Monday, September 20, 2010

Monitoring up the Stack: Threats

By Adrian Lane

In our introductory post we discussed how customers are looking to derive additional value form their SIEM and log management investments by looking at additional data types to climb the stack. Part of the dissatisfaction we hear from customers is the challenge of turning collected data into actionable information for operational efficiency and compliance requirements. This challenge is compounded by the clear focus on application-oriented attacks. For the most part, our detection only pays attention to the network and servers, while the attackers are flying above that. It’s kind of like repeatedly missing the bad guys because they are flying at 45,000 feet, but you cannot get above 20,000 feet. You aren’t looking where the attacks are actually happening, which obviously presents problems. At its core SIEM can fly at 45,000’ and monitor application components looking for attacks, but it will take work to get there. Though given the evolution of the attack space, we don’t believe keeping monitoring focused on infrastructure is an option, even over the middle term.

What kind of application threats are we talking about? It’s not brain surgery and you’ve seen all of these examples before, but they warrant another mention because we continue to miss opportunities to focus on detecting these attacks. For example:

  • Email: You click a link in a ‘joke-of-the-day’ email your spouse forwarded, which installs malware on your system, and then tries to infect every machine on your corporate network. A number of devices get compromised and become latent zombies waiting to blast your network and others.
  • Databases: Your database vendor offers a new data replication feature to address failover requirements for your financial applications, but it’s installed with public credentials. Any hacker can now replicate your database, without logging in, just by issuing a database command. Total awesomeness!
  • Web Browsers: Your marketing team launches a new campaign, but the third party content provider site was hacked. As your customers visit your site, they are unknowingly attacked using cross-site request forgery and then download malware. The customer’s credentials and browsing history leak to Eastern Europe, and fraudulent transactions get submitted from customer machines without their knowledge. Yes, that’s a happy day for your customers and also for you, since you cannot just blame the third party content provider. It’s your problem.
  • Web Applications: Your web application development team, in a hurry to launch a new feature on time, fails to validate some incoming parameters. Hackers exploit the database through a common SQL injection vulnerability to add new administrative users, copy sensitive data, and alter database configuration – all through normal SQL queries. By the way, as simple as this attack is, a typical SIEM won’t catch it because all the requests look normal and are authorized. It’s an application failure that causes security failure.
  • Ad-hoc applications: The video game your kid installed on your laptop has a keystroke logger that records your activity and periodically sends an encrypted copy to the hackers who bought the exploit. They replay your last session, logging into your corporate VPN remotely to extract files and data under your credentials. So it’s fun when the corporate investigators show up in your office to ask why you sent the formula for your company’s most important product to China.

The power of distributed multi-app systems to deliver services quickly and inexpensively cannot be denied, which means we security folks will not be able to stop the trend – no matter what the risk. But we do have both a capability and responsibility to ensure these services are delivered as securely as possible, and we watch for bad behavior. Many of the events we discussed are not logged by traditional network security tools, and to casual inspection the transactions look legitimate. Logic flaws, architectural flaws, and misused privileges look like normal operation to a router or an IPS. Browser exploits and SQL injection are difficult to detect without understanding the application functionality. More problematic is that damage from these exploits occurs quickly, requiring a shift from after-the-fact forensic analysis to real-time monitoring to give you a chance to interrupt the attack. Yes, we’re really reiterating that application threats are likely to get “under the radar” and past network-level tools.

Customers complain the SIEM techniques they have are too slow to keep up with remote multi-stage attacks, code substitution, etc.; ill-suited to stopping SQL injection, rogue applications, data leakage, etc.; or simply effective against cross-site scripting, hijacked privileges, etc. – we keep hearing that current tools to have no chance against these new attacks. We believe the answer involves broader monitoring capabilities at the application layer, and related technologies. But reality dictates the tools and techniques used for application monitoring do not always fit SIEM architectures. Unfortunately this means some of the existing technologies you may have, and more importantly the way you’ve deployed them – may not fit into this new reality. We believe all organizations need to continue broadening how they monitor their IT resources and incorporate technologies that are designed to look at the application layer, providing detection of application attacks in near real time. But to be clear, adoption is still very early and the tools are largely immature. The following is an an overview of the technologies designed to monitor at the application layer, and these are what we will focus on in this series:

  • File Integrity Monitoring: This is real-time verification of applications, libraries, and patches on a given platform. It’s designed to detect replacement of files and executables, code injection, and the introduction of new and unapproved applications.
  • Identity Monitoring: Designed to identify users and user activity across multiple applications, or when using generic group or service accounts. Employs a combination of location, credential, activity, and data comparisons to ‘de-anonymize’ user identity.
  • Database Monitoring: Designed to detect abnormal operation, statements, or user behavior; including both end users and database administrators. Monitoring systems review database activity for SQL injection, code injection, escalation of privilege, data theft, account hijacking, and misuse.
  • Application Monitoring: Protects applications, web applications, and web-based clients from man-in-the-middle attacks, cross site scripting (XSS), cross site request forgery (CSRF), SQL injection, browser hacking, and data leakage. Commonly deployed as an appliance that monitors inbound application traffic.
  • User Activity Monitoring: Examination of inbound and outbound user activity, application usage, and data. Commonly applied to email, web browsing, and other user initiated activity; as well as malware detection, botnets, and other types of ad hoc applications operating unbeknownst to the user.

We’ll follow that up with a discussion of the technology considerations for these enhanced monitoring systems, and talk about how to prioritize the collection and analysis of these additional data types, depending upon common use cases/attack scenarios. Each type of monitoring offers specific advantages, and many overlap with each other, so you’ll have lots of options for how to phase in these application monitoring capabilities.

—Adrian Lane

NSO Quant: Manage Metrics—Document Policies & Rules

By Mike Rothman

Now that we’ve reviewed our policies and also defined and/or updated our policies and rules, we need to be sure to properly document these activities. Yes, part of this is an operational requirement (in case you get hit by a bus), but this typo of documentation is also critical for compliance purposes. The auditor needs to know what’s in the policies & rules – and more importantly a) what’s changed and b) that the changes have been properly authorized. So it’s key to have processes for documenting each step of the process.

To recall, we previously listed the process definitions for Document Policies and Rules separately for firewall and IDS/IPS. The subprocess steps are consistent:

  1. Approve Policy/Rule
  2. Document Policy/Update
  3. Document Rule/Update
  4. Prepare Change Request

Here are the applicable operational metrics:

Approve Policy/Rule

Variable Notes
Time to evaluate policy and/or rule change Based on policy review documentation, risk of attack vectors and existing process documents.
Time to get approval from authorized parties Involves discussions with key influencers (business and technical). There are multiple levels of approval, not all applicable to your environment. But it’s important to make sure everyone is on board with the policies and rules.

Document Policy/Change

Variable Notes
Time to document policy change(s) Amount of time varies based on number of policies/updates to document, time per policy to document, existence/completeness of current documentation, and degree of automation.

Document Rule/Change

Variable Notes
Time to document rule change(s) Amount of time varies based on number of rules/updates to document, time per rule to document, existence/completeness of current documentation, and degree of automation.

Prepare Change Request

Variable Notes
Time to package requested changes into proper format Based on the granularity of change authorization process.

In the next set of posts we’ll dig into the IDS/IPS specific task of managing the attack signatures that make up a substantial portion of the rule base.

—Mike Rothman

NSO Quant: Manage Metrics—Define/Update Policies and Rules

By Mike Rothman

How do all those policies and rules (yes, we know there are the thousands of them) get updated – or defined in the first place? We have gone through the processes, but let’s look at the actual time expenditures for each step. We previously listed the process definitions for Define/Update Policies and Rules separately for firewall and IDS/IPS. The subprocess steps are consistent:

  1. Identify Critical Applications/Users/Data
  2. Define/Update Policies
  3. Model Threats
  4. Define/Update Rules
  5. Test Rule Set
  6. Retest (if necessary)

Here are the applicable operational metrics:

Identify Critical Applications/Users/Data

Variable Notes
Time to identify critical applications/users/data in use Involves discussions with key influencers (business and technical), as well as technical discovery to ensure nothing is missed.

Define/Update Policies

Variable Notes
Time to find relevant policy examples There is no need to reinvent the wheel. Lots of examples (books, websites, peers) can provide a head start on defining policies.
Time to customize the policies for your organization
Time to gain consensus on policies It’s important to ensure all interested parties weigh in on the policies, because implementing will be difficult without broad support.

Model Threats

Variable Notes
Time to identify attack vectors/patterns for each policy
Time to gather baselines from current environment Baselines help to identify normal behavior and to make sure there aren’t any holes in the policies based on what really happens on your network.
Time to build applicable threat model Based on baselines and other potential threat vectors. You can’t model every possible threat, so focus on those that present the greatest risk to critical data.

Define/Update Rules

Variable Notes
Time to find relevant rule examples There are numerous examples of publicly available firewall and IDS/IPS rule bases to start with.
Time to customize specific rules to run on firewall and/or IDS/IPS Make sure all the threats identified in the model are protected against.
Time to determine actions to take, based on rules firing Do you want to block, alert, log, or take some other action when a specific rule is violated?
Time to gain consensus on rules and actions It’s important to ensure all interested parties weigh in on the rules and especially the actions, because these decisions impact business operations.

Test Rule Set

Variable Notes
Time to design testing scenario
Time to set up test bed for system test Many organizations build a simple firewall lab to test rule changes.
Time to simulate attack It’s probably not a good idea to take down a production network, but you need the tests to approximate reality as closely as possible.
Time to analyze test data to ensure proper detection and/or blocking of attacks
If any of the tests fail, time to update rules to address the issues and to retest In the event of a minor issue, a quick change and retest may suffice. For a significant issue you likely need to go back to the define/update policy step and restart.

In the next post we’ll dig into documenting the policies and rules, and then we’ll have enough of this planning stuff sorted to start working with devices.

—Mike Rothman

FireStarter: It’s Time to Talk about APT

By Rich

There’s a lot of hype in the press (and vendor pitches) about APT – the Advanced Persistent Threat. Very little of it is informed, and many parties within the security industry are quickly trying to co-opt the term in order to advance various personal and corporate agendas. In the process they’ve bent, manipulated and largely tarnished what had been a specific description of a class of attacker. I’ve generally tried to limit how much I talk about it – mostly restricting myself to the occasional Summary/Incite comment, or this post when APT first hit the hype stage, and a short post with some high level controls.

I self-censor because I recognize that the information I have on APT all comes either second-hand, or from sources who are severely restricted in what they can share with me.

Why? Because I don’t have a security clearance.

There are groups, primarily within the government and its contractors, with extensive knowledge of APT methods and activities. A lot of it is within the DoD, but also with some law enforcement agencies. These guys seem to know exactly what’s going on, including many of the businesses within private industry being attacked, the technical exploit details, what information is being stolen, and how it’s exfiltrated from organizations.

All of which seems to be classified.

I’ve had two calls over the last couple weeks that illustrate this. In the first, a large organization was asking me for advice on some data protection technologies. Within about 2 minutes I said, “if you are responding to APT we need to move the conversation in X direction”. Which is exactly where we went, and without going into details they were essentially told they’d been compromised and received a list, from “law enforcement”, of what they needed to protect.

The second conversation was with someone involved in APT analysis informing me of a new technique that technically wasn’t classified… yet. Needless to say the information wasn’t being shared outside of the classified community (e.g., not even with the product vendors involved) and even the bit shared with me was extremely generic.

So we have a situation where many of the targets of these attacks (private enterprises) are not provided detailed information by those with the most knowledge of the attack actors, techniques, and incidents. This is an untenable situation – further, the fundamental failure to share information increases the risk to every organization without sufficient clearances to work directly with classified material. I’ve been told that in some cases some larger organizations do get a little information pertinent to them, but the majority of activity is still classified and therefore not accessible to the organizations that need it.

While it’s reasonable to keep details of specific attacks against targets quiet, we need much more public discussion of the attack techniques and possible defenses. Where’s all the “public/private” partnership goodwill we always hear about in political speeches and watered-down policy and strategy documents? From what I can tell there are only two well-informed sources saying anything about APT – Mandiant (who investiages and responds to many incidents, and I believe still has clearances), and Richard Bejtlich (who, you will notice, tends to mostly restrict himself to comments on others’ posts, probably due to his own corporate/government restrictions).

This secrecy isn’t good for the industry, and, in the end, it isn’t good for the government. It doesn’t allow the targets (many of you) to make informed risk decisions because you don’t have the full picture of what’s really happening.

I have some ideas on how those in the know can better share information with those who need to know, but for this FireStarter I’d like to get your opinions. Keep in mind that we should try and focus on practical suggestions that account for the nuances of the defense/intelligence culture being realistic about their restrictions. As much as I’d like the feds to go all New School and make breach details and APT techniques public, I suspect something more moderate – perhaps about generic attack methods and potential defenses – is more viable.

But make no mistake – as much hype as there is around APT, there are real attacks occurring daily, against targets I’ve been told “would surprise you”.

And as much as I wish I knew more, the truth is that those of you working for potential targets need the information, not just some blowhard analysts.

UPDATE Richard Bejtlich also highly recommends Mike Cloppert as a good source on this topic.


NSO Quant: Manage Metrics—Policy Review

By Mike Rothman

As we descend into the depths of the Manage (firewall and IDS/IPS) process metrics, it’s again important to keep in mind that much of the expense of managing network security devices is in time. There are some tools that can automate certain aspects of the device management drudgery, but ultimately a lot of the effort is making sure you understand what policies and rules apply and at what priority, which you cannot readily automate.

We previously defined the process definitions for Policy Review separately for firewall and IDS/IPS. But the subprocess steps are consistent across device types:

  1. Review Policies
  2. Propose Policy Changes
  3. Determine Relevance/Priority
  4. Determine Dependencies
  5. Evaluate Workarounds/Alternatives

Here are the applicable operational metrics:

Review Policies

Variable Notes
Time to isolate relevant policies Based on the catalyst for policy review (attack, signature change, false positives, etc.).
Time to review policy and list workarounds/alternatives Focus on what changes you could/should make, without judging them (yet). That comes later.

Propose Policy Changes

Variable Notes
Time to gain consensus on policy changes Some type of workflow/authorization process needs to be defined well ahead of the time to actually review/define policies.

Determine relevance/priority

Variable Notes
Time to prioritize policy/rule changes Based on the risk of attack and the value of the data protected by the device.

Determine Dependencies

Variable Notes
Time to determine whether additional changes are required to implement policy update Do other policies/rules need to change to enable this update? What impact will this update have on existing policies/rules?

Evaluate Workarounds/Alternatives

Variable Notes
Time to evaluate the list of alternatives/workarounds for feasibility Sometimes a different control will make more sense than a policy/rule change.

In the next post we’ll dig into actually defining and updating the policies and rules.

—Mike Rothman

Security Briefing: September 20th

By Liquidmatrix


Good Morning all. It appears to have been an interesting weekend for hacking. A big hello to all of the folks at SOURCE Barcelona (wish I was there). I hope you all had a great weekend and now, lets get this week underway.


Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

  1. Police lay charges of libel, obstruction against Calgary website operator | Calgary Herald
  2. Visa website vulnerable to XSS | Security-Shell
  3. Former NSA Chief Hayden: Cybersecurity Policy Still ‘Vacant’ | National Defense Magazine
  4. Maine wants to track students with Social Security numbers | Sae Coast Online
  5. Patient Records Sold to Recycler | Health Data Management
  6. Hacker disrupts Parliament-funded website | Radio New Zealand
  7. Hackers find new ways to steal your identity | Atlanta Journal Constitution
  8. Hacker attack wreaks havoc on Sweden Democrat website | The Local
  9. On the Web, Children Face Intensive Tracking | Wall Street Journal


Understanding and Selecting an Enterprise Firewall: Selection Process

By Mike Rothman

Now that we’ve been through the drivers for evolved, application-aware firewalls, and a lot of the technology enabling them, how does the selection process need to evolve to keep pace? As with most of our research at Securosis, we favor mapping out a very detailed process, and leaving you to decide which steps make sense in your situation. So we don’t expect every organization to go through every step in this process. Figure out which are appropriate for your organization and use those.

To be clear, buying an enterprise firewall usually involves calling up your reseller and getting the paperwork for the renewal. But given that these firewalls imply new application policies and perhaps a different deployment architecture, some work must be done during selection process to get things right.

Define Needs

The key here is to understand which applications you want to control, and how much you want to consider collapsing functionality (IDS/IPS, web filtering, UTM) into the enterprise firewall. A few steps to consider here are:

  • Create an oversight committee: We hate the term ‘committee’ to, but the reality is that an application aware firewall will impact activities across several groups. Clearly this is not just all about the security team, but also the network team and the application teams as well – at minimum, you will need to profile their applications. So it’s best to get someone from each of these teams (to whatever degree they exist in your organization) on the committee. Ensure they understand your objectives for the new enterprise firewall, and make sure it’s clear how their operations will change.
  • Define the applications to control: Which applications do you need to control? You may not actually know this until you install one of these devices and see what visibility they provide into applications traversing the firewall. We’ll discuss phasing in your deployment, but you need to understand what degree of granularity you need from a blocking standpoint, as that will drive some aspects of selection.
  • Determine management requirements: The deployment scenario will drive these. Do you need the console to manage the policies? To generate reports? For dashboards? The degree to which you need management help (if you have a third party tool, the answer should be: not much) will define a set of management requirements.
  • Product versus managed service: Do you plan to use a managed service for either managing or monitoring the enterprise firewall? Have you selected a provider? The provider might define your short list before you even start.

By the end of this phase you should have identified key stakeholders, convened a selection team, prioritized the applications to control, and determined management requirements.

Formalize Requirements

This phase can be performed by a smaller team working under the mandate of the selection committee. Here the generic needs determined in phase 1 are translated into specific technical features, and any additional requirements are considered. You can always refine these requirements as you proceed through the selection process and get a better feel for how the products work (and how effective and flexible they are at blocking applications).

At the conclusion of this stage you will develop a formal RFI (Request For Information) to release to vendors, and a rough RFP (Request For Proposals) that you’ll clean up and formally issue in the evaluation phase.

Evaluate Products

Increasingly we see firewall vendors starting to talk about application awareness, new architectures, and very similar feature sets. The following steps should minimize your risk and help you feel confident in your final decision:

  • Issue the RFI: Larger organizations should issue an RFI though established channels and contact a few leading enterprise firewall vendors directly. Though in reality virtually all the firewall players sell through the security channel, so it’s likely you will end up going through a VAR.
  • Define the short list: Before bringing anyone in, match any materials from the vendor or other sources to your RFI and draft RFP. Your goal is to build a short list of 3 products which can satisfy most of your needs. You should also use outside research sources and product comparisons. Understand that you’ll likely need to compromise at some point in the process, as it’s unlikely any vendor can meet every requirement.
  • Dog and Pony Show: Instead of generic presentations and demonstrations, ask the vendors to walk you through how they protect the specific applications you are worried about. This is critical, because the vendors are very good at showing cool eye candy and presenting a long list of generic supported applications. Don’t expect a full response to your draft RFP – these meetings are to help you better understand how each vendor can solve your specific use cases and to finalize your requirements.
  • Finalize and issue your RFP: At this point you should completely understand your specific requirements, and issue a final formal RFP.
  • Assess RFP responses and start proof of concept (PoC): Review the RFP results and drop anyone who doesn’t meet your hard requirements. Then bring in any remaining products for in-house testing. Given that it’s not advisable to pop holes in your perimeter when learning how to manage these devices, we suggest a layered approach.
    • Test Ingress: First test your ingress connection by installing the new firewall in front of the existing perimeter gateway. Migrate your policies over, let the box run for a little while, and see what it’s blocking and what it’s not.
    • Test Egress: Then move the firewall to the other side of the perimeter gateway, so it’s in position to do egress filtering on all your traffic. We suggest you monitor the traffic for a while to understand what is happening, and then define egress filtering policies.

Understand that you need to devote resources to each PoC, and testing ingress separately from egress adds time to the process. But it’s not feasible to leave the perimeter unprotected while you figure out what works, so this approach gives you that protection and the ability to run the devices in pseudo-production mode.

Selection and Deployment

  • Select, negotiate, and buy: Finish testing, take the results to the full selection committee, and begin negotiating with your top two choices, assuming more than one meets your needs. Yes; this takes more time; but you want to be able to walk away from one of the vendors if they won’t play on with pricing, terms, or conditions.
  • Implementation planning: Congratulations, you’ve selected a product, navigated the procurement process, and made a sales rep happy. But now the next stage of work begins – the last phase of selection is planning the deployment. That means making sure of little details, lining up resources, locking in an install schedule, and even figuring out the logistics of getting devices to (and installed at) the right locations.

I can hear your groans from small to medium sized business who look at this process and think this is a ridiculous amount of detail. Once again, we want to stress that we deliberately created a granular selection process, but you can pare this down to meet your organization’s requirements. We wanted to ensure we captured all the gory details some organizations need to go through for a successful procurement. The full process outlined is appropriate for a large enterprise, but a little pruning can make it manageable for small groups. That’s the great thing about process: you can change it any way you see fit at no expense.

With that, we end our series on Understanding and Selecting an Enterprise Firewall. Hopefully it will be useful as you proceed through your own selection process. As always, we appreciate all your comments on our research. We’ll be packaging up the entire series as a white paper over the next few weeks, so stay tuned for that.

Other Posts in Understanding and Selecting an Enterprise Firewall

  1. Introduction
  2. Application Awareness, Part 1
  3. Application Awareness, Part 2
  4. Technical Architecture, Part 1
  5. Technical Architecture, Part 2
  6. Deployment Considerations
  7. Management
  8. Advanced Features, Part 1
  9. Advanced Features, Part 2
  10. To UTM or not to UTM

—Mike Rothman

Friday, September 17, 2010

Upcoming Webinar: Selecting SIEM

By Adrian Lane

Tuesday, September 21st, at 11am PST / 2pm EST, I will be presenting a webinar: “Keys to Selecting SIEM and Log Management”, hosted by NitroSecurity. I’ll cover the basics of SIEM, including data collection and deployment, then dig into use cases, enrichment, data management, forensics, and advanced features.

You can sign up for the webinar here. SIEM and Log Management platforms have been around for a while, so I am not going to spend much time on background, but instead steer more towards current trends and issues. If I gloss over any areas you are especially interested in, we will have 15 minutes for Q&A. You can send questions in ahead of time to info ‘at’ securosis dot com, and I will try to address them within the slides. Or you can submit a question in the WebEx chat facility during the presentation, and the host will help discuss.

—Adrian Lane

Friday Summary: September 17, 2010

By Rich

Reality has a funny way of intruding into the best laid plans.

Some of you might have noticed I haven’t been writing that much for the past couple weeks and have been pretty much ignoring Twitter and the rest of the social media world. It seems my wife had a baby, and since this isn’t my personal blog anymore I was able to take some time off and focus on the family. Needless to say, my “paternity leave” didn’t last nearly as long as I planned, thanks to the work piling up.

And it explains why this may be showing up in your inbox on Saturday, for those of you getting the email version.

Which brings me to my next point, one we could use a little feedback on. If you look at the blog this week we hit about 20 posts… many of them in-depth research to support our various projects. I’m starting to wonder if we are overwhelming people a little? As the blogging community has declined we spend less time with informal commentary and inter-blog discussions, and more time just banging out research.

As a ‘research’ company, it isn’t like we won’t publish the harder stuff, but I want to make sure we aren’t losing people in the process like that boring professor everyone really respects, but who has to slam a book on the desk at the end of class to let everyone know they can go.

Finally, this week it was cool to ship out the iPad for the winning participant in the 2010 Data Security Survey. When I contacted him he asked, “Is this some phishing trick?”, but I managed to still get his mailing address and phone number after a few emails.

Which is cool, because now I have a new bank account with better credit, and it looks like his is good enough for the mortgage application.

(But seriously, he wanted one & didn’t have one, and it was really nice to send it to someone who appreciated it).

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. This week’s best comment goes to Troy, in response to Tokenization Will Become the Dominant Payment Transaction Architecture.

Interesting discussion. As I read the article I was also interested in the ways in which a token could be used as a ‘proxy’ for the PAN in such a system – the necessity of having the actual card number for the initial purchase seems to assuage most of that concern.

Another aspect of this method that I have not seen mentioned here: if the Tokens in fact conform to the format of true PANs, won’t a DLP scan for content recognition typically ‘discover’ the Tokens as potential PANs? How would the implementing organization reliably prove the distinction, or would they simply rest on the assumption that as a matter of design any data lying around that looks like a credit card number must be a Token? I’m not sure that would cut the mustard with a PCI auditor. Seems like this could be a bit of a sticky wicket still?

Troy – in this case you would use database fingerprinting/exact data matching to only look for credit card numbers in your database, or to exclude the tokens. Great question!


Understanding and Selecting an Enterprise Firewall: to UTM or Not to UTM?

By Mike Rothman

Given how much time we’ve spent discusing application awareness and how these new capabilities pretty much stomp all over existing security products like IDS/IPS and web filters, does that mean standalone network security devices go away? Should you just quietly accept that unified threat management (UTM) is the way to go because the enterprise firewall provides multiple functions? Not exactly.

First let’s talk about the rise of UTM, even in the enterprise. The drive towards UTM started with smaller businesses, where using a single device for firewall, IDS/IPS, anti-spam, web filtering, gateway AV, and other functions reduced complexity and cost – and thus made a lot of sense. But over time as device performance increased, it became feasible even for enterprises to consolidate functions into a single device. This doesn’t mean many enterprises tried this, but they had the option.

So why hasn’t the large enterprise embraced UTM? It comes down to predictable factors we see impacting enterprise technology adoption in general:

  • Branding: UTM was perceived as a SMB technology, so many enterprise snobs didn’t want anything to do with it. Why pay $2,500 for a box when you can pay $50,000 to make a statement about being one of the big boys? Of course, notwithstanding the category name, every vendor brought a multi-function security gateway to market. They realize ‘UTM’ could be a liability so they use different names for people who don’t want to use the same gear as the great unwashed.
  • Performance Perception: Again, given the SMB heritage of UTM, enterprise network security players could easily paint UTM as low-performance, and customers believed them. To be clear, the UTM-centric vendors didn’t help here pushing their boxes into use cases where they couldn’t be successful, demonstrating they weren’t always suitable. If you try to do high-speed firewall, IDS/IPS, and anti-spam with thousands of rules, all in the same box, it’s not going to work well. Hell, even standalone devices use load balancing techniques to manage high volumes, but the perception of enterprise customers was that UTM couldn’t scale. And we all know that perception is reality.
  • Single Point of Failure: If the box goes down you are owned, right? Well, yes – or completely dead in the water – you might get to choose which. Many enterprises remain unwilling to put all their eggs in one basket, even with high availability configurations and the like. As fans of layered security we don’t blame folks for thinking this way, but understand that you can deploy a set of multi-function gateways to address the issue. But when you are looking for excuses not to do something, you can always find at least one.
  • Specialization: The complexity of large enterprise environments demands lots of resources, and they resources tend to be specialized in the operations of one specific device. So you’ll have a firewall jockey, an IDS/IPS guru, and an anti-spam queen. If you have all those capabilities in a single box, what does that do for the job security of all three? To be clear every UTM device supports role-based management so administrators can have control only over the functions in their area, but it’s easier for security folks to justify their existence if they have a dedicated box/function to manage. Yes, this boils down to politics, but we all know political machinations have killed more than a handful of emerging technologies.
  • Pricing: There is no reason you can’t get a multi-function security device and use it as a standalone device. You can get a UTM and run it like a firewall. Really. But to date, the enterprise pricing of these UTM devices made that unattractive for most organizations. Again, a clear case of vendors not helping themselves. So we’d like to see more of a smorgasbord pricing model, where you buy the modules you need. Yes, some of the vendors (especially ones selling software on commodity hardware) are there. But their inclination is to nickel and dime the customer, charging too much for each module, so enterprises start to lose the idea that multi-function devices will actually save money.

Ultimately these factors will not stop the multi-function security device juggernaut from continuing to collapse more functions into the perimeter gateway. Vendors changed the branding to avoid calling it UTM – even though it is. The devices have increased performance with new chips and updated architectures. And even the political stuff works out over time due to economic pressure to increase operational efficiency.

So the conclusion we draw is that consolidation of network security functions is inevitable, even in the large enterprise. But we aren’t religious about UTM vs. standalone devices. All we care about is seeing the right set of security controls are implemented in the most effective means to protect critical information. We don’t expect standalone IDS/IPS devices to go away any time soon. And much of the content filtering (email and web) is moving to cloud-based services. We believe this is a very positive trend. These new abilities of the enterprise firewall give us more flexibility.

That’s right, we still believe (strongly) in defense in depth. So having an IDS/IPS sitting behind an application aware firewall isn’t a bad thing. Attacks change every day and sometimes it’s best to look for a specific issue. Let’s use a battle analogy – if we have a sniper (in the form of IDS/IPS) sitting behind the moat (firewall) looking for a certain individual (the new attack), there is nothing wrong with that. If we want to provision some perimeter security in the cloud, and have a cleaner stream of traffic hitting your network, that’s all good. If you want to maintain separate devices at HQ and larger regional locations, while integrating functions in small offices and branches, or maybe even running network security in a virtual machine, you can.

And that’s really the point. For a long time, we security folks have been building security architectures based on what the devices could do, not what’s appropriate (or necessary) to protect information assets. Having the ability to provision the security you need where you need it is exactly what we’ve been looking for? All these technologies remain relevant. Even if enterprises fully embrace application awareness on the enterprise firewall – and they will – there will still be plenty of boxes at your perimeter. So don’t go redecorating your 19” racks quite yet. They’ll still be full for a while…

Next we’ll finish up the series by talking specifically about the selection process.

—Mike Rothman

Thursday, September 16, 2010

DLP Selection: Infrastructure Integration Requirements

By Rich

In our last post we detailed content protection requirements, so now it’s time to close out our discussion of technical requirements with infrastructure integration.

To work properly, all DLP tools need some degree of integration with your existing infrastructure. The most common integration points are:

  • Directory servers to determine users and build user, role, and business unit policies. At minimum, you need to know who to investigate when you receive an alert.
  • DHCP servers so you can correlate IP addresses with users. You don’t need this if all you are looking at is email or endpoints, but for any other network monitoring it’s critical.
  • SMTP gateway this can be as simple as adding your DLP tool as another hop in the MTA chain, but could also be more involved.
  • Perimeter router/firewall for passive network monitoring you need someplace to position the DLP sensor – typically a SPAN or mirror port, as we discussed earlier.
  • Web gateway will probably integrate with your DLP system if you want to on filtering web traffic with DLP policies. If you want to monitor SSL traffic (you do!), you’ll need to integrate with something capable of serving as a reverse proxy (man in the middle).
  • Storage platforms to install client software to integrate with your storage repositories, rather than relying purely on remote network/file share scanning.
  • Endpoint platforms must be compatible to accept the endpoint DLP agent. You may also want to use an existing software distribution tool to deploy the it.

I don’t mean to make this sound overly complex – many DLP deployments only integrate with a few of these infrastructure components, or the functionality is included within the DLP product. Integration might be as simple as dropping a DLP server on a SPAN port, pointing it at your directory server, and adding it into the email MTA chain. But for developing requirements, it’s better to over-plan than miss a crucial piece that blocks expansion later.

Finally, if you plan on deploying any database or document based policies, fill out the storage section of the table. Even if you don’t plan to scan your storage repositories, you’ll be using them to build partial document matching and database fingerprinting policies.


NSO Quant: Monitor Metrics—Validate and Escalate

By Mike Rothman

As we wrap up the Monitoring process, we need to figure out what to do once we receive an alert. Is it a real issue? If so, whose job is it to handle it? These steps are about answering those questions.


We previously defined the Validate subprocess as:

  1. Alert Reduction
  2. Identify Root Cause
  3. Determine Extent of Compromise
  4. Document

Here are the operational metrics:

Alert Reduction

Variable Notes
Time to determine which alerts reflect the same incident Don’t waste time on overlapping investigations of a single issue.
Time to merge alerts in the system
Time to verify the alert data & eliminate false positives At the end of this step, you need to know whether the alert is legitimate.

Identify Root Cause

Variable Notes
Time to find device under attack
Time for forensic analysis to understand attack specifics What does the attack do? What’s the impact to the monitored devices?
Time to establish root cause and specific attack vector Once you understand what the attack does, then pinpoint how it happened.
Time to identify possible remediation(s), workarounds, and/or escalation plan Understanding how it happened allows you to put controls in place to ensure it doesn’t happen again.

Determine Extent of Compromise

Variable Notes
Time to define scan parameters to identify other devices vulnerable to attack The goal is to quickly determine how many other devices have been similarly compromised.
Time to run scan


Variable Notes
Time to close alert, if false positive
Time to document findings with sufficient detail for remediation The ops team will need to know exactly how to fix the issue. More detail provides less opportunity for mistakes.
Time to log in ticketing system


We previously defined the Escalate subprocess as:

  1. Open Trouble Ticket
  2. Route Appropriately
  3. Close Alert

Here are the operational metrics:

Open Trouble Ticket

Variable Notes
Time to integrate/access trouble ticket system Ops team may use a different system than security. Stranger things have happened.
Time to open trouble ticket Be sure to include enough information to assist in troubleshooting.

Route Appropriately

Variable Notes
Time to find/confirm responsible party Should be specified in policy definition but things change, so confirmation is a good idea.
Time to send alert
Time to follow up and answer questions Depending on how segmented the operational responsibilities are from monitoring, you may not be able to close the ticket until all the questions from ops are answered and they accept the ticket.

Close Alert

Variable Notes
Time to follow up and ensure resolution Depending on lines of responsibility, this may not be necessary. Once the ticket is routed, that may be the end of the security team involvement.
Time to close alert

And that’s it for the metrics driving Monitoring. Next week we’ll tear through the Manage Firewall and IDS/IPS process steps. We’re sure you can’t wait…

—Mike Rothman

Understanding and Selecting an Enterprise Firewall: Advanced Features, Part 2

By Mike Rothman

After digging into application awareness features in Part 1, let’s talk about non-application capabilities. These new functions are really about dealing with today’s attacks. Historically, managing ports and protocols has sufficed to keep the bad guys outside the perimeter; but with today’s bumper crop of zombies & bots, the old ways don’t cut it any more.

Bot Detection

As law enforcement got much better at tracking attackers, the bad guys adapted by hiding behind armies of compromised machines. Better known as zombies or bots, these devices (nominally controlled by consumers) send spam, do reconnaissance, and launch other attacks. Due to their sophisticated command and control structures, it’s very difficult to map out these bot networks, and attacks can be launched from anywhere at any time.

So how do we deal with this new kind of attacker on the enterprise firewall?

  • Reputation: Reputation analysis was originally created to help fight spam, and is rapidly being adopted in the broader network security context. We know some proportion of the devices out there are doing bad things, and we know many of those IP addresses. Yes, they are likely compromised devices (as opposed to owned by bad folks specifically for nefarious purposes) but regardless, they are doing bad things. You can check a reputation service in real time and either block or take other actions on traffic originating from recognized bad actors. This is primarily a black list, though some companies track ‘good’ IPs as well, which allows them to take a cautious stance on devices not known to be either good or bad.
  • Traffic Analysis: Another technique we are seeing on firewall is the addition of traffic analysis. Network behavioral analysis didn’t really make it as a standalone capability, but tracking network flows across the firewall (with origin, destination, and protocol information) allows you to build a baseline of acceptable traffic patterns and highlight abnormal activity. You can also set alerts on specific traffic patterns associated with command and control (bot) communications, and so use such a firewall as an IDS/IPS.

Are these two capabilities critical right now? Given the prevalence of other mechanisms to detect these attacks – such as flow analysis through SIEM and pattern matching via network IDS – this is a nice-to-have capability. But we expect a lot of these capabilities to centralize on application aware firewalls, positioning these devices as the perimeter security gateway. As such, we expect these capabilities to become more prevalent over the next 2 years, and in the process make the bot detection specialists acquisition targets.

Content Inspection

It’s funny, but lots of vendors are using the term ‘DLP’ to describe how they analyze content within the firewall. I know Rich loves that, and to be clear, firewall vendors are not* performing Data Leak Prevention. Not the way we define it, anyway. At best, it’s content analysis a bit more sophisticated than regular expression scanning. There are no capabilities to protect data at rest or in use, and their algorithms for deep content analysis are immature when they exist at all.

So we are pretty skeptical on the level of real content inspection you can get from a firewall. If you are just looking to make sure social security numbers or account IDs don’t leave the perimeter through email or web traffic, a sophisticated firewall can do that. But don’t expect to protect your intellectual property with sophisticated analysis algorithms. When firewall vendors start saying bragging on ‘DLP’, you have our permission to beat them like dogs.

That said, clearly there are opportunities for better integration between real DLP solutions and the enterprise firewall, which can provide an additional layer of enforcement. We also expect to see maturation of inspection algorithms available on firewalls, which could supplant the current DLP network gateways – particularly in smaller locations where multiple devices can be problematic.

Vulnerability Integration

One of the more interesting integrations we see is the ability for a web application scanner or service to find an issue and set a blocking rule directly on the web application firewall. This is not a long-term fix but does buy time to investigating a potential application flaw, and provides breathing room to choose the most appropriate remediation approach. Some vendors refer to this as virtual patching. Whatever it’s called, we think it’s interesting. So we expect the same kind of capability to show up on general purpose enterprise firewalls.

You’d expect the vulnerability scanning vendors to lead the way on this integration, but regardless, it will make for an interesting capability of the application aware firewall. Especially if you broaden your thinking beyond general network/system scanners. A database scan would likely yield some interesting holes which could be addressed with an application blocking rule at the firewall, no? There are numerous intriguing possibilities, and of course there is always a risk of over-automating (SkyNet, anyone?), but the additional capabilities are likely worth the complexity risk.

Next we’ll address the question we’ve been dancing around throughout the series. Is there a difference between an application aware firewall and a UTM (unified threat management) device? Stay tuned…

—Mike Rothman

Wednesday, September 15, 2010

DLP Selection Process: Protection Requirements

By Rich

Now that you’ve figured out what information you want to protect, it’s time to figure out how to protect it. In this step we’ll figure out your high-level monitoring and enforcement requirements.

Determine Monitoring/Alerting Requirements

Start by figuring out where you want to monitor your information: which network channels, storage platforms, and endpoint functions. Your high-level options are:

  • Network
    • Email
    • Webmail
    • HTTP/FTP
    • HTTPS
    • IM/Messaging
    • Generic TCP/IP
  • Storage
    • File Shares
    • Document Management Systems
    • Databases
  • Endpoint
    • Local Storage
    • Portable Storage
    • Network Communications
    • Cut/Paste
    • Print/Fax
    • Screenshots
    • Application Control

You might have some additional requirements, but these are the most common ones we encounter.

Determine Enforcement Requirements

As we’ve discussed in other posts, most DLP tools include various enforcement actions, which tend to vary by channel/platform. The most basic enforcement option is “Block” – the activity is stopped when a policy violation is detected. For example, an email will be filtered, a file not transferred to a USB drive, or an HTTP URL will fail. But most products also include other options, such as:

  • Encrypt: Encrypt the file or email before allowing it to be sent/stored.
  • Quarantine: Move the email or file into a quarantine queue for approval.
  • Shadow: Allow a file to be moved to USB storage, but send a protected copy to the DLP server for later analysis.
  • Justify: Warn the user that this action may violate policy, and require them to enter a business justification to store with the incident alert on the DLP server.
  • Change rights: Add or change Digital Rights Management on the file.
  • Change permissions: Alter the file permissions.

Map Content Analysis Techniques to Monitoring/Protection Requirements

DLP products vary in which policies they can enforce on which locations, channels, and platforms. Most often we see limitations on the types or size of policies that can be enforced on an endpoint, which change based as the endpoint moves off or onto the corporate network, because some require communication with the central DLP server.

For the final step in this part of the process, list your content analysis requirements for each monitoring/protection requirement you just defined. These tables directly translate to the RFP requirements that are at the core of most DLP projects: what you want to protect, where you need to protect it, and how.


Monitoring up the Stack: Introduction

By Adrian Lane

The question that came up over and over again during our SIEM research project: “How do I derive more value from my SIEM installation?” As we discussed throughout that report, plenty of data gets collected, but extracting actionable information remains a challenge. In part this is due to the “drinking from the fire-hose” effect, where the speed and volume of incoming data make it difficult to process effectively. Additionally, data needs to be pieced together with sufficient reference points from multiple event sources before analysis. But we found a major limiting factor was also the network-centric perspective on data collection and analysis. We were looking at traffic, rather than transactions. We were looking at packet density, not services. We were looking at IP addresses instead of user identity. We didn’t have context to draw conclusions.

We continue pushing our research agenda forward in the areas of application and user monitoring, as this has practical value in performing more advanced analysis. So we will dig into these topics and trends in our new series “Monitoring up the Stack: Reacting Faster to Emerging Attacks”.

Compliance and operations management are important drivers for investment in SIEM, Log Management, and other complimentary monitoring investments. SIEM has the capacity to provide continuous monitoring, but most are just not set up to provide timely threat response to application attacks. To support more advanced policies and controls, we need to peel back the veil of network-oriented analysis to look at applications and business transactions. In some cases, this just means a new way of looking at existing data. But that would be too easy, wouldn’t it? To monitor up the stack effectively we need to look at changes in architecture, policy management, data collection, and analysis.

Business process analytics and fraud detection require different policies, some additional data, and additional analysis techniques beyond what is commonly found in SIEM. If we want to make sense of business use of IT systems, we need to move up the stack, into the application layer. What’s different about monitoring at the application layer? Application awareness and context.

To highlight the differences in why network and security event monitoring are inherently limiting for some use cases, consider that devices and operating systems are outside business processes. In some cases they lack the information needed to perform analysis, but more commonly the policies and analysis engines are just not set up to detect fraud, spoofing, repudiation, and injection attacks. From the application perspective, network identity and user identity are extremely different. Analysis, performed in context of the application, provides contextual data unavailable from just network and device data. It also provides an understanding of transactions, which is much more useful and informative than pure events. Finally, the challenges of deploying a solution for real-time analysis of events are almost the opposite of those needed for efficient management and correlation. Evolving threats target data and application functions, and we need that perspective to understand and keep up with threats.

Ultimately we want to provide business analysis and operations management support when parsing event streams, which are the areas SIEM platforms struggle with. And for compliance we want to implement controls and verify both effectiveness and appropriateness. To accomplish these we must employ additional tactics for baselining behavior, advanced forms of data analysis, policy management and – perhaps most importantly – having a better understanding of user identity and authorization. Sure, for security and network forensics, SIEM does a good job of piecing together related events across a network. Both methods detect attacks, and both help with forensic analysis. But monitoring up the stack is far better for detecting misuse and more subtle forms of data theft. And depending upon how it’s deployed in your environment, it can block activity as well as report problems.

In our next post we’ll dig into the threats that drive monitoring, and how application monitoring is geared for certain attack vectors.

—Adrian Lane