[SecurityRatty] tag: assign

Taking a second look at Rohati

Thu, 19 Jun 2008 20:33:04 +0000

Last week in response to Richard Stiennon's glowing write up, I questioned what it is exactly that Rohati does. Well someone from Rohati must have seen it and I was contacted by the Rohati team and offered a peek and a deep explanation of exactly what Rohati does. So today I had a chance to speak with Shane Buckley, CEO, Prashant Ghandi VP of product management and strategy and Steven Wastie, VP of marketing. I was impressed that such a triumvirate of power players from the Rohati team took the time to speak to me. But I guess after I wrote what I did, it was followed up by JJ writing her article on it and than Rothman piling on with his own two cents.

Give the Rohati team credit for recognizing the power of blogs to influence the influencer and reaching out to stem the tide. It just goes to show you how far blogging has come. But enough about the power of blogs, lets talk about Rohati.

The best way for me to describe Rohati is that it is layer 7 ACLs to control access to applications. Where we already have security at the perimeter and at the edge, Rohati is about controlling access at the server/application. The diagram on the left (click on it to get a bigger version), is a good illustration of how Rohati works. By integrating with LDAPs Rohati can assign you an access policy to any application. Based upon that Rohati gives a very fine grain level of access control at the application layer. It acts as a proxy to the app server for both regular and encrypted traffic. Because the ACLs are on the Rohati box itself, there really is not any integration with switches per say and so no integration worries.

The only problem is that the Rohati box has to be able to handle the traffic flow. Hence the box is a big honker. The cheap one is about 20k list I believe and the industrial size version is 80k. This product is aimed squarely at the data center space and is sold through channels.

Will Rohati succeed. Yes, I think it will. I think they have taken a unique approach to a security issue that will continue to grow in years to come. Application access is an area that I think is still up and coming. In a period of nothing is ever new in security, the Rohati team seems to have found something that has not been done before in a packaged dedicated way like this. If nothing else, with all of the ex-Cisco folks there, Cisco will eat its young and buy the technology back in.

We will watch Rohati's progress in the months to come. At the very least, it seems they are blog savvy enough to navigate the waters of social media. Maybe they will start their own blog soon.

Taking a second look at Rohati

Thu, 19 Jun 2008 19:33:04 +0000

Will Rohati succeed. Yes, I think it will. I think they have taken a unique approach to a security issue that will continue to grow in years to come. Application access is an area that I think is still up and coming. In a period of nothing is ever new in security, the Rohati team seems to have found something that has not been done before in a packaged dedicated way like this. If nothing else, with all of the ex-Cisco folks there, if nothing else Cisco will eat its young and buy the technology back in.

We will watch Rohati's progress in the months to come. At the very least, it seems they are blog savvy enough to navigate the waters of social media. Maybe they will start their own blog soon.

Top 5: Why Customers Consider NAC

Sat, 31 May 2008 18:10:33 +0000

On a daily (and nightly) basis I have the wonderful experience of talking to, chatting about, presenting on or asking questions of customers about NAC.

At each of these opportunities, I like to ask ‘Why are you considering NAC?”

Here’s my Top 5 of Why Customers Consider NAC (or think they want NAC). This is not based on any other organization’s research or polls, nor is it based on analyst analysis. It’s not based on forethought or musings of an ‘expert’. It’s just my personal experience from my daily interactions.

#1: Endpoint Compliance
I put this one first, because I think it’s the most-hyped and possibly least significant. I know, that’s harsh, especially when endpoint compliance seems to be the big bat NAC carries around. Truth be told, it’s more of an ‘icing on the cake’ for the people I talk to. Until the auto-remediation features are a little more mature, the idea of checking for much beyond presence of anti-virus and possibly patches is unattractive. Frankly, endpoint compliance for LAN-based devices can be a Charlie Foxtrot except under the most ideal circumstances. There are many large organizations and DoD groups that need endpoint compliance, and that’s a primary driver for them. For the rest, one of the other reasons below is a primary compelling feature and endpoint checking is just another knob they can play with.

The lack of fervent interest in endpoint checking is why I had to disagree so strongly with Stiennon’s when he advises in his NWW article “Don’t even bother investing in NAC”. The entire premise of his issues with NAC center around various endpoing checking. (You can check out Shimel’s response too Stiennon’s blog here.)

#2: Guest Access
Believe it or not, the most frequent response I get for “why are you considering NAC” is “guest access”. Guest access seems to be a thorn in every organization’s side. It’s a simple problem with impossibly complex solutions… or so they think. For years, we’ve been provisioning safe and secure guest access for customers with the use of clean and simple protocol-less VLANs and so, I know that about 82% of the time, there are much simpler ways to offer guest access than by rolling out a full NAC implementation. If guest access is your primary and only goal with a NAC solution, there’s probably a better, faster and less expensive solution. If money and time are no object, then NAC can be a good way to get from point A to B and give you a few fun technical trinkets to play with.

#3: Edge Port Security
After guest access, the next thing I hear most is interest in adding edge port security with a 802.1X NAC solution. (We call this Layer 2 NAC.) I tend to think for the time being, this is NAC’s sweet spot. Note I said ‘for the time being’, I think this may change in the next 18-24 months. But for now, the ability to lock down edge ports and secure switch-to-switch links is an extremely attractive feature. Outside of the 802.1X protocol, there aren’t really any other ways to skin this cat. I know what you’re thinking… you don’t have to do NAC to use 802.1X… and that’s certainly true, but for a network of any size, NAC makes an 802.1X implementation easier to manage and monitor centrally and gives you more of that NAC icing we all love.

When the 802.1X-REV comes out (probably early 2009) I think you’ll see organizations that have previously blown off 1X seriously considering it for all the added security and multi-user support it will bring to the table.

#4: User & Resource Accounting
Unless you have a 3rd party solution or want to dig through mounds of RADIUS syslogs, you probably don’t have a good way to account for user authentication and accountability of resource access throughout the network. Most vendors’ NAC solutions already have pretty good logging and reporting features built in today. Depending on the solution and integration of other devices, you may even get detailed accounts of which user viewed exactly what, when and from where. This is a great selling point to organizations that are trying to follow strict regulations for accountability of financial or extremely sensitive resources. The standards bodies (IEEE, TNC framework and IETF) are coming out with more and more ways to leverage 3rd party security devices within NAC. The IF-MAP is a great example and we’ll be seeing more I’m sure.

#5: Dynamic VLAN Assignment
Lastly, but not least, I hear a lot of customers that are looking for a good way to dynamically provision attributes, such as VLAN assignment and QoS to users or devices. It makes switch configuration and management much simpler, and eliminates the need to assign port-based VLANs. The ability to leverage your existing user directory and define both broad and very granular attributes is certainly a draw, and NAC is a great way to offer that.

That wraps up my Top 5. Of course, there are plenty more drivers, both business-based or technology-based, but these are the 5 I hear most.

# # #

Sophos feeds Tim Greene a line of bull on virtual NAC

Thu, 22 May 2008 09:14:15 +0000

I saw Tim Greene's column this morning entitled "Sophos NAC client adapts to virtual environments" and was curious to see if Sophos had taken a similar tact to what we did here at StillSecure in securing multiple virtual machines on the same physical machine. After reading the article though I have to say that Richard Jacobs, CTO of Sophos fed Tim Greene a line of bull.

First of all lets start with the obvious. Sophos whole solution around virtual environments and NAC is nothing more than vaporware! Here is how the article leaves off in discussing this "solution" that Jacobs talks about, "Jacobs says the company doesn’t have a name yet for this enforcement agent, nor does it have a date when it will become available as a product. Stay tuned." So what exactly are we talking about?

Beyond that though, a closer examination of what Jacobs says is the obstacle in providing NAC to virtual environments is bull. Jacobs says the problem is "that in virtual environments, a physical machine that hosts virtual machines already has access to the network". Therefore according to Jacobs, "The switch port that the host machine connects to cannot be used as a NAC policy enforcement point because the host machine’s status would determine the NAC policy for itself and for all the virtual machines running on it." He continues with, "That single policy would then have to apply to all the virtual machines running on the host, regardless of the status of the individual virtual machines, he says. A non-compliant virtual machine that tries to come onto the network could change the NAC status of the host, and enforcing that new status would block all the other virtual machines, even if they are compliant."

Maybe what Jacobs should have said was that if your NAC is so limited that it will only work by allowing one device on per port with no ability to distinguish devices, OSs, etc beyond that rudimentary one-to-one equation, you are stuck waiting for Sophos to develop something that may work, who knows when. But there is a better way!

What about if you have the ability to distinguish access to the network based upon MAC address? My understanding is that each virtual OS in a virtual environment will have its own unique MAC address. So if you are going to assign policy, test and quarantine based upon multiple factors such as IP, domain, MAC address, netbios, etc, you do have the capability to test and allow one OS, while denying another OS, all while they are running on the same physical machine. In fact that is just what we do with Safe Access!

I have seen it in action here at our offices in Colorado myself. If you log on with a Macintosh you get checked as a Mac and are allowed on or not depending if you passed the assigned policy test. When you fire up Windows on that Mac, you are tested again and can be denied access, while your Mac is allowed on. Vice versa, you can get on the network with your Window virtual OS, even though your Mac OS was denied, all mind you while you are running on a Macintosh physical box.

The moral of the story is don't underestimate that someone else has a better mousetrap than you do. Also, if you are going to go spout off thinking everyone is as limited as you are, at least have the goods and don't be pushing vaporware!

Communicating about risk - part 2

Tue, 20 May 2008 12:22:24 +0000

The trouble with likelihood

It’s common to see charts similar to the one below used to communicate risk. On one axis we have Impact, and on the other we have Likelihood. We’ll save a discussion regarding Impact for another post, but in this post I’d like to point out a couple of subtle but important limitations with the term “likelihood”.

Likelihood connotes the probability of an event occurring. In fact, you may see explicit probability ranges assigned to each qualitative label (e.g., “Very High = 90% to 100% probable”). And, while this seems to be on the right track, there are two problems with it:

It often doesn’t include a timeframe reference. In other words, does the likelihood statement refer to the probability of the event occurring this week, this year, in this lifetime?
It doesn’t provide the means to differentiate between something that may happen once vs. something that may happen multiple times. For example, a statement; “The likelihood of a virus infection is Very High” doesn’t differentiate whether the event is likely to happen once or many times.

These two limitations become critical when we’re trying to quantify and/or compare risk issues.

Using frequency, we can account for events that occur many times within the defined timeframe as well as those that occur fewer than once in the timeframe (e.g., .01 times per year, or once in one hundred years). Of course, this raises the question of how we determine frequency, particularly for infrequent events. In the interest of keeping this post to a reasonable length, I’ll cover that another time (soon).

Drawing lines

You may have seen charts like the ones below, with lines drawn to differentiate High from Medium, etc.

(NOTE: Magnitude scales will vary based on the risk capacity/tolerance of the organization)

These can be useful, but a few challenges I’ve encountered with this approach include:

If the risk point falls barely on one side of the line or the other, do the lines really serve a useful purpose, at least from the perspective of being able to assign a qualitative value?
Who drew the lines? At one place I’ve worked, I couldn’t get management to provide guidance on where to draw the lines so I took a stab at drawing them based on what I thought management’s risk tolerance was given their earlier decisions. This seemed to work okay, as I didn’t experience much push-back from management, but you need to constantly look for evidence that the lines need to be changed.
Particularly in larger companies with multiple affiliates or subsidiaries, line placement will vary because each part of the enterprise will have its own risk tolerance. A “critical” loss at the subsidiary level might not equate to a rounding error at the enterprise level. I’ve dealt with this by plotting results on two charts; one scaled to the enterprise risk tolerance, and another drawn to the subsidiary’s tolerance.

Of course, the fact that the point isn’t really a point at all, but the intersection of two ranges or distributions further affects the utility of lines.

I’ve found two ways of charting risk that seem to be well received by management (below).

(NOTE: These charts were created using Monte Carlo analyses within FAIR-based applications)

My preference is the scatter plot, which does a nice job of visualizing the uncertainty that is a part of any risk analysis. A couple of things to note:

No lines have been drawn to label the result “High”, “Medium”, etc.
I haven’t used a green-to-red background on the charts.

I will use those illustrative tools if requested by management, but I tend not to use them otherwise. Besides the challenges I noted above regarding lines, my rationale is that lines and colors tend to bias interpretation of the results. In other words, if someone sees a risk point plotted in a red background or in the “High” section of the chart, they equate those results as “unacceptable”. The fact is, the acceptability of a risk condition is often dependent on the value proposition of the situation, the cost to mitigate risk, etc. I’ve found management is intelligent enough to know that the upper-right part of the chart means more risk than the lower-left.

Building a Security Architecture Blueprint

Fri, 16 May 2008 05:26:55 +0000

This week I spoke at the Secure 360 conference on Building A Security Architecture Blueprint (slides). My thesis is that information is a strategic enterprise asset (in many cases it *is* the business), yet the typical enterprise approach to securing the information or even risk management, is rarely strategic. Last year, I wrote a Security Architecture Blueprint paper to describe one framework for putting a strategic context around information security program. The main idea is that instead of starting with security goals (cue the ritual CIA invocation), we start with considering security in the context of the stakeholders - business, development, operations, customers, and so on.

You can then use the framework to assign priorities and phasing for Information Security actions. So instead of letting the random auditor and their everpresent checklist that the final four assigns you drive your program, use a framework that incorporates the business and its goals. A number of people commented on my post on GRC -

Rich Mogull

Much of what we call GRC should really be features of your ERP and accounting software. ... It’s an additional, very highly priced, reporting layer. ...A GRC tool provides almost no value at the business unit level, since it doesn’t help them get their day to day jobs done.

Mike Rothman succinctly gets to the point with a one liner I am sure will become part of my repertoire:

It's about serving the business, NOT THE AUDITORS. If you protect information effectively (which is a key imperative for the business), then the auditors should be kept reasonably happy. And if not, screw them and fight them. Yes, the auditor can make your life a bit harder, but you don't work for them. Keep that in mind.

So my GRC post seemed to tap into a fair amount of GRC blogohostility , fair enough, but the main point is not slamming GRC, just the overfocus on GRC and substituting misdirected marketecture for real world architecture Hoff got to the heart of the point of what i was saying - its about assets

As I think about it, I'm not sure GRC would be something a typical InfoSec function would purchase or use unless forced which is part of the problem. I see internal audit driving the adoption which given today's pressures (especially in public companies) would first start in establishing gaps against regulatory compliance.
If the InfoSec function is considering an approach that drives protecting the things that matter most and managing risk to an acceptable level and one that is not compliance-driven but rather built upon a business and asset-driven approach

So I submit that you should not start with a compliance checklist, but instead build a security architecture blueprint that captures your stakeholders goals. Assess this against your policy and standards, and your security architecture capabilities. Out of this comes risk management decisions. And off we go into actually building and operating something - hopefully making some profits along the way.

So build blueprints, minimize time spent doing checkbox Olympics. The blueprint I worked on is just generic framework, you may have a different one. I know that the one that I designed is in use in many organizations and in each case I know of it has been tailored to local purposes. So its a beginning not an end, but those two things are more related than you think as someone from the financial services industry once said

In my beginning is my end ... in my end is my beginning

Where you start your security architecture and design matters, and directly effects where you end up.

Anyway, the conference was a lot of fun, I rarely get to do conferences in MN. I got meet Anton Chuvakin for the first time, and went to the presentation on the local OWASP Minnesota chapter - Robert Sullivan, Joe Teff and Kuai Hinojosa did a great job doing an overview of what OWASP is all about, demoing WebGoat and so on.

Xecrets: Access your passwords anytime, anywhere

Tue, 13 May 2008 03:44:42 +0000

Like many of you, I assign a unique password to each application, site, or device. Without a password vault to safely manage the growing number of logins, I'd have to regularly click the 'Forgot your password?' link. However, there are still times when I forget to drop my flash drive in my bag. In those cases, I either have to change many of my passwords or wait until I again have access to the Password Manager file. Now there might be a solution for my forgetfulness.

The Oracle speaks

Wed, 07 May 2008 15:55:42 +0000

No not Larry Ellison. StillSecure's oracle of NAC, Dave Greenstein, Chief Security Architect at StillSecure. I write and speak a lot about NAC, but Dave actually lives NAC. He led our development team that developed Safe Access. Now he is way out in front researching and designing the next generations of Safe Access and our other products. Dave doesn't comment on my posts a lot. I am always bugging him to start his own blog. The best I get is occasionally he will write an article or white paper. So when he commented on Joel Snyder's article on NAC and my comments, I figured it would make sense to give it some main column play. Here is what Dave had to say:

In order to use NAP you only need server 2008 for the NPS... Your domain and AD can still be 2003 so I think adoption of NAP will be faster for that reason. Also, XP SP3, which has NAP capabilities, adoption should be pretty fast compared to Vista.
On ACLs, I agree with Joel that ACLs are a great way to do things... But not with routers and DHCP enforcement. If you have HP switches or Extreme Switches then you can do dynamic ACLs per port. Similar to how you assign a VLAN via RADIUS attributes, you can assign ACLs for that port in addition to assigning a VLAN. This is great if you have the right switches. It helps protect the other endpoints within a quarantine VLAN and adds an extra layer of security. Cisco switches do not have this capability unless you’re running Cisco NAC and a Cisco ACS server (ugh). So, buy HP and Extreme switches!
What’s more likely to slow NAP adoption down is it’s total lack of endpoint administration... How do you keep track of what endpoints have which problems? How do you get an endpoint on the network in an emergency even if it has an issue? How do you update the SHAs on your thousands of endpoints? There are a whole host of issues not solved by NAP that make it unusable. That’s where products like StillSecure Safe Access come in.

BTW, if you think Dave makes some sense here and would like to hear more from him, let me know and I will coax him into writing some more! I should also add that I twisted his arm to give Safe Access a plug at the end there. Thanks Dave!

Best Practices For DLP Content Discovery: Part 3

Thu, 17 Apr 2008 18:44:34 +0000

Okay, I’m a day late with this one, but that’s pretty good for me these days.

In our last post we talked about the base technical architecture. Today we’ll fill in with enforcement, management, workflow, and reporting.

Enforcement actions

Once the DLP discovery tool determines something is out of place, it can (depending on the tool) take enforcement actions that range from alerts to full on protection, including combinations. In cases where files are restricted, moved, or encrypted an unprotected plain text file can be dropped into the same location to notify users who to contact with questions now that they can’t access the file.

Alert: an alert is recorded as a DLP incident. This is the base action, triggered no matter what else occurs.
Notify: email is sent to either the content owner (based on access controls and directory integration), policy owner (based on the DLP policy), or pretty much anyone else (such as the content owner’s manager).
Restrict access controls: access controls are modified to restrict access. E.g. block anyone except a security administrator from accessing the file so it’s protected until the violation is manually reviewed.
Move/quarantine: the file is moved to a secure repository.
Encrypt: the file is encrypted. It could be protected with something as generic as a corporate key, or something more specific like a group, security, or administrative key.

Management

Ideally your content discovery capabilities will be managed using the same server as the rest of your DLP deployment. This will maintain consistent policies, workflow, and incident handling. Here are a few discovery-specific capabilities to look for:

Policy creation: data at rest policies should be completely integrated with your other DLP policies. Thus you only have to define a type of content once (e.g. credit card number or engineering plan) then apply appropriate alerting and protection rules for at rest, in use, and in motion as part of a single policy. Policies should allow for granular actions based on user groups through directory integration.
Directory integration: all DLP solutions can identify IP and email addresses, but for discovery you also need to understand network users and groups to tie into access controls.
Repository management: this is the part of the system where you identify and group storage repositories such as servers, shares, and document management systems. For crawling it’s where you store access credentials, and for agents it includes agent management. Ideally you can tag groups of repositories to make policy building easier (e.g. “accounting” or “engineering”). Here is where you also define scanning frequency, bandwidth/performance throttling, and other basic functional preferences.

Workflow and Reporting

Workflow should be completely integrated into your standard DLP incident handling queue. Discovery related incidents should appear right with in motion or in use incidents, although you may assign a different incident handler for at rest policies depending on organizational needs. For example, you may decide to assign a specific incident handler to review all storage related PCI violations, while keeping network violations in the general queue. If you encrypt, quarantine, or otherwise protect files the DLP solutions needs to include management of those controls so you can release/restore when needed.

Reporting, on the other hand, should include discovery-specific reports, especially audit reports to help with compliance efforts. While a report on all transmissions of credit card numbers over email might not be the kind of thing you want to send to an auditor, a report showing that you don’t have any unprotected numbers in any known storage location might be more interesting. Also look for the ability to generate reports for business unit managers, storage administrators, audit/legal/compliance, and other non-technical personnel. Because scans are run periodically, the solution should allow you to automatically schedule and distribute reports, rather than requiring them to be run manually every time.

Again, this section is just meant to highlight a few discovery-specific capabilities to look for and is not a substitute for a full description of all standard DLP features.

Banning function calls, assurance, and retrofitting

Tue, 18 Mar 2008 16:48:00 +0000

I've been working on some C/C++ secure coding standards lately, and trying to mesh those up with the results from the static analyzer I'm using. As it turns out there is a fine line to be drawn between what you consider best practices, what a static analyzer can find, how much context the static analyzer has, and how much manual review you really want to put up with.

Let me give a specific example.

Coverity's Prevent analyzer has a number of built-in "unsafe" functions defined. The list includes the standard cast such as scanf, strcpy, strcat, etc. On top of that though they add some things that didn't make Microsoft's list; for example, rand().

I don't technically have a problem with including rand() in the list of things to be extremely careful about, but whereas it is nearly impossible to guarantee that someone has used strcpy() right, rand() actually has some pretty legitimate uses.

Consider the case where we want to do a randomized delay in processing something, or where we wish to randomly assign work to different people when it comes in, or randomly pull an item off a work queue for a customer service agent. None of these cases requires a cryptographically sound random number generator. For the most part, using rand() is a perfectly reasonable choice in this sort of situation.

When you decide that you want to ban certain function calls, or call them out in findings in a static analyzer, you're treading a fine line with your developers and the people you're going to ask to go and clean up the old code you have around. You can choose to go several routes.

File defects against the old code for any use of a banned function, without investigating the specific use
File defects against old code only after verifying that in the context you have a potential vulnerability
Get a dedicated team together to just go and clean up old code

Each of these approaches has its plusses and minuses.

If you choose to file defects against your developers for code that is years old and wasn't necessarily written by them without verifying the vulnerabilities, you run the risk of them not taking the secure coding rules seriously. Many of the items they find are going to be false positives from a currently-exploitable perspective, and they are going to be cranky with you.

If you choose to go through the validate each and every defect and the types of defect are pervasive, you're going to spend almost as much verifying the defect as fixing it. Especially if you're going through and simply replacing strcpy() with strlcpy() for example. For both this and the case above though, developers are going to be going through the code, and with the proper training/awareness, they might actually learn more about some of the old code, or at least start to have a better sense of some real security issues in the code.

If you choose to get a dedicated team together to fix the old code, you're likely to save money in the short run. A dedicated team is going to get used to fixing the coding defects of this type, and you're going to make a lot shorter job of it. The downside being that the regular developers aren't getting some of the code review experience you'd really like.

To top things off, if you go route #2, wherein you only fix things that are currently exploitable, you run the risk of the code being used in a different way elsewhere and causing problems down the road.

Back to my rand() example. In every case where I've found rand() used it hasn't been in a security critical context. Do I want to leave these instances of rand() in my code as examples that others might follow, next time in a security sensitive context? Or, do I want to take a relatively dogmatic approach to this and all other banned/"unsafe" functions and eliminate them entirely from my codebase?

I'm leaning towards some sort of middle ground. If I can find the time for a dedicated team to go through the code to clean up old issues, then I'm likely to remove all instances of things that could be unsafe, just so we don't leave things around that could be copied into an truly unsafe context.

Its a tricky balancing act to determine how dogmatic you want to be about fixing up the use of certain "unsafe" functions. Getting it wrong either way can have long term consequences for your secure development program. As always, the right answer depends on a lot of factors.