I ran across this article by Net Applications that shows their recent browser tracking data. According to their stats, Microsoft Internet Explorer (MSIE) browser has finally dropped below 70% of the overall browser market share, and Firefox has risen above 20%.
Overall, this is nice for Firefox and alternative browsers, but it does have both positive and negative security implications. For a period of time, it felt like the world wide web was a homogenous environment of MSIE browsers everywhere (and before that, it was Netscape browsers). Now we're finally at a point where the numbers may start supporting the notion that we have a true heterogeneous environment blossoming. Heterogeneous environments, whether it be a computer network or a biological system, are often much more robust and stable than a homogeneous environment simply because a homogeneous environment is susceptible to a single incident (such as an eruption of a pathogen, or a browser exploit in our case) wiping out the entire environment in one fell swoop. So the growth of browser alternatives is actually good for web browser security overall, because it means not all systems will be p0wn3d by the next devastating MSIE vulnerability.
There is also a downside of this too. With the rise of active use of alternative browsers, there is now enough incentive for attackers to take the time to attack/exploit the alternatives. We kind of already knew this, and it was largely already happening in the real world, but the numbers help to support the idea. Simply put: if no one is using a browser, there isn’t much blackhat value in finding a vulnerability in it to exploit...you’d essentially have a specialized weapon with a lack of targets to use it upon. But once there is a moderate/sizable population of those targets, the effectiveness of that specialized weapon (i.e. exploit) increases. We’ve seen this before with the Apple Mac platform: many people claimed it was more secure than Windows because it had fewer publicized security vulnerabilities. There's even the claim that Macs don't need anti-virus software because there are no viruses for Macs. Of course, Mac popularity grew, the number of deployed systems rose, and that caused the attackers to take notice. Now we have active research and exploitation of OSX and its components, and a host of malware specific to the Mac platform (for the skeptical: OSX.Leap.A, OSX.Exploit.Launchd, OSX.Macarena, OSX.Inqtana.A, etc.)
Overall this is the right direction for things to be heading. However, those trying to fly under the blackhats' web exploitation radars by using an alternative/obscure browser may find their days of obfuscated safety are numbered. As soon as the obscure browser you are using jumps into the limelight, attackers are sure to pounce on it eventually as well.
Side note: I've encountered many individuals that have employed this 'security through obscure browser' tactic. The issue is that they were using browsers like Maxthon, NeoPlanet, Avant, etc. What they didn't realize is that all of these browsers were just different UI shells on top of the MSIE web layout engine (called 'Trident'). In other words, they often just as vulnerable as if they were directly running MSIE—there was no security advantage gained. Overall there currently four major web browser 'engines': Trident (MSIE), Gecko (Firefox), WebKit (Safari), and Presto (Opera). Most browsers on the market today use one of those engines (or a derivative), and that means any vulnerability that affects the engine will affect any browser built upon it. So you might hear of a vulnerability in Firefox, but the bug could truly be in the Gecko engine and thus other browsers like Flock, Camino, Epiphany, Galeon, SeaMonkey, and Songbird (all Gecko-based) could be vulnerable as well. Therefore if you are looking to differentiate yourself by using an obscure browser for security purposes, you should do some research to ensure the browser you are running is not running the same (vulnerable) web engine as the more popular browsers.
Until next time,
- Jeff
Friday, January 2, 2009
Friday, December 26, 2008
You Gotta Stop Them Somewhere
Let's say you've established some security objectives, including "Keep an attacker who controls Internet web sites my employees visit from denying my employees access to my corporate information." How can you tell whether the product you're considering will help you meet your goal?
In theory, it's pretty simple: for a set of controls to give you the security benefit you are looking for, there needs to be at least one control blocking every possible path from what the attacker can do before he attacks (control Internet web sites your employees visit) to the thing you really don't want him to do (stop your employees from accessing your corporate information). If there is a path on which nothing stops the attacker, you have a security vulnerability, which means you need to change either your goals (maybe they're too aggressive for current technology to support), the system architecture, or the set of controls you're using. If there are paths on which multiple controls stop the attacker, you have defense in depth; how much depth is good depends on your level of paranoia and the performance, administrative and financial costs you are willing to put up with.
In practice, when you're trying to use security controls to meet a minimum bar, the hard part is knowing what paths are available for an attacker to take. Each path is made up of individual steps, each of which has starting and ending privileges. There are 3 kinds of steps to consider:
I find it quickest and most enlightening to start at both ends (the attacker's starting privileges and your anti-goals for the attacker), and enumerate the endpoints of steps in each category.
Let's start at your anti-destination for the attacker, denying employees access to corporate information. You may think that because this is a denial of service threat, you didn't design your system to enable it at all, but chances are good you can get a pretty good list from your departing employee process.
Because these things have to work for your sysadmin when an employee leaves, they would also work for an attacker, if an attacker could do them.
To get a list of design side-effects an attacker could use to prevent an employee from accessing corporate information, try inverting the table of contents of your disaster recovery plan (or, if you don't have one, the categories in your IT help desk ticketing system). You know if any of these conditions are true, your IT crew is going to scramble because employees won't be able to get the information they need. This is true whether it happened by accident or an attacker did it to you on purpose.
This leaves us with implementation flaws. You can't really list these unless you are running known-vulnerable software. Presumably if you knew you were running vulnerable software, you would patch it, so let's not try to create this list directly. Instead, list the components which have the permissions to do things in the first 2 lists. If these components were vulnerable (in the right ways), an attacker who got far enough to reach the vulnerable interface could exploit them and presumably accomplish the original threat.
Now, start from the other side. If an attacker can control an Internet site your employees visit, what can he do by design?
What can he do as a design side-effect?
What could he do as a result of implementation flaws?
In the middle, for any given potential connection you can have one of three things: a working path for the attacker, a control that blocks the attacker's path to your anti-goal for the attacker, or something more fuzzy (usually including the word "may"). If there are any working paths for the attacker that traverse only steps that are by design, you have a requirements conflict and it will not be possible for technological controls to meet the security objective you have in mind unless you change your requirements. For any other working path, you need to find a control that will break a link. Or, going the other way, to be complete, the set of controls you are considering must break at least one link in each otherwise-working path. Probably to get this effect, you will need to combine controls from multiple sources. If a set of controls doesn't break any links in any attack paths you care about, don't buy it.
From the above partial lists, there is a pretty clear connection between an attacker being able to take advantage of security flaws in the employee's web browser and the consequences of a vulnerability in the user's desktop: the web browser runs on the user's desktop, so a security flaw in the browser would mean the attacker with control of a web site visited by the employee can deny the employee access to corporate information, violating this security objective. There is an equally clear connection between social engineering the employee into opening malware and violating this security objective. The latter connection, because it doesn't involve any implementation flaws, is more serious, and it would be prudent to mitigate it. You could, say, compare the effectiveness of user-education programs, desktop anti-virus, and an HTTP malware scanner (my money, hopefully obviously, is on combining the desktop AV and the HTTP scanner, because people will click on anything).
Because the fuzzy paths say "may", you get some leeway in deciding whether you think there is a working path for the attacker to follow from his starting privileges to the things you don't want him to do. If you have no known working attack paths, you might consider reducing risk in these areas (e.g. by instituting an aggressive monitoring & patching policy, or buying a product which attempts to defend against relevant 0-day attacks) before adding depth to your defenses in other areas.
--Brenda
In theory, it's pretty simple: for a set of controls to give you the security benefit you are looking for, there needs to be at least one control blocking every possible path from what the attacker can do before he attacks (control Internet web sites your employees visit) to the thing you really don't want him to do (stop your employees from accessing your corporate information). If there is a path on which nothing stops the attacker, you have a security vulnerability, which means you need to change either your goals (maybe they're too aggressive for current technology to support), the system architecture, or the set of controls you're using. If there are paths on which multiple controls stop the attacker, you have defense in depth; how much depth is good depends on your level of paranoia and the performance, administrative and financial costs you are willing to put up with.
In practice, when you're trying to use security controls to meet a minimum bar, the hard part is knowing what paths are available for an attacker to take. Each path is made up of individual steps, each of which has starting and ending privileges. There are 3 kinds of steps to consider:
- By Design: the system is designed to provide someone with privileges S with privileges E.
- Design Side-Effects: it didn't necessarily need to be this way, but the system is designed such that someone with privileges S can automatically get privileges E.
- Implementation Flaws: someone with privileges S can get privileges E even though the design of the system does not allow this step
I find it quickest and most enlightening to start at both ends (the attacker's starting privileges and your anti-goals for the attacker), and enumerate the endpoints of steps in each category.
Let's start at your anti-destination for the attacker, denying employees access to corporate information. You may think that because this is a denial of service threat, you didn't design your system to enable it at all, but chances are good you can get a pretty good list from your departing employee process.
My system is designed to prevent [ex-]employees access to corporate information when:
The user's account is deleted from LDAP.
The user's account is deleted from the 'employee' group.
The user's password is changed.
Ownership of a file formerly owned by the user is changed.
Files owned by the user are deleted.
...
Because these things have to work for your sysadmin when an employee leaves, they would also work for an attacker, if an attacker could do them.
To get a list of design side-effects an attacker could use to prevent an employee from accessing corporate information, try inverting the table of contents of your disaster recovery plan (or, if you don't have one, the categories in your IT help desk ticketing system). You know if any of these conditions are true, your IT crew is going to scramble because employees won't be able to get the information they need. This is true whether it happened by accident or an attacker did it to you on purpose.
This leaves us with implementation flaws. You can't really list these unless you are running known-vulnerable software. Presumably if you knew you were running vulnerable software, you would patch it, so let's not try to create this list directly. Instead, list the components which have the permissions to do things in the first 2 lists. If these components were vulnerable (in the right ways), an attacker who got far enough to reach the vulnerable interface could exploit them and presumably accomplish the original threat.
An attacker may be able to prevent access to corporate information when:
A vulnerability in the LDAP server allows an attacker to delete user accounts, change group membership, ...
A vulnerability in the file server allows an attacker to delete files, change file permissions, overwrite files, ...
A vulnerability in the user's desktop allows an attacker to prevent the machine from booting, delete applications, delete files, change file permissions, overwrite files, change the user's password, ...
...
Now, start from the other side. If an attacker can control an Internet site your employees visit, what can he do by design?
A web site my employee visits can:
Set or delete cookies for that site on my employee's desktop.
Redirect the employee's browser to another Web site.
Run javascript in the user's web browser in the context of that site.
Run java applications, signed ActiveX controls, …
...
What can he do as a design side-effect?
A web site my employee visits can also:
Respond to a single request with more than one response.
Persuade my employee to run damaging commands or executables.
…
What could he do as a result of implementation flaws?
A web site my employee visits can:
Take advantage of any security flaw in the employee's web browser or plugins.
In the middle, for any given potential connection you can have one of three things: a working path for the attacker, a control that blocks the attacker's path to your anti-goal for the attacker, or something more fuzzy (usually including the word "may"). If there are any working paths for the attacker that traverse only steps that are by design, you have a requirements conflict and it will not be possible for technological controls to meet the security objective you have in mind unless you change your requirements. For any other working path, you need to find a control that will break a link. Or, going the other way, to be complete, the set of controls you are considering must break at least one link in each otherwise-working path. Probably to get this effect, you will need to combine controls from multiple sources. If a set of controls doesn't break any links in any attack paths you care about, don't buy it.
From the above partial lists, there is a pretty clear connection between an attacker being able to take advantage of security flaws in the employee's web browser and the consequences of a vulnerability in the user's desktop: the web browser runs on the user's desktop, so a security flaw in the browser would mean the attacker with control of a web site visited by the employee can deny the employee access to corporate information, violating this security objective. There is an equally clear connection between social engineering the employee into opening malware and violating this security objective. The latter connection, because it doesn't involve any implementation flaws, is more serious, and it would be prudent to mitigate it. You could, say, compare the effectiveness of user-education programs, desktop anti-virus, and an HTTP malware scanner (my money, hopefully obviously, is on combining the desktop AV and the HTTP scanner, because people will click on anything).
Because the fuzzy paths say "may", you get some leeway in deciding whether you think there is a working path for the attacker to follow from his starting privileges to the things you don't want him to do. If you have no known working attack paths, you might consider reducing risk in these areas (e.g. by instituting an aggressive monitoring & patching policy, or buying a product which attempts to defend against relevant 0-day attacks) before adding depth to your defenses in other areas.
--Brenda
Monday, December 22, 2008
Final encounters with a web comment spammer
In the last part of my series on web comment spamming applications, I want to pass along a few things I noticed that were effective at separating the spam apps from the humans. Many of these have been publicly discussed already, but they still are worth repeating. Also, note that none of these techniques provide a permanent, fool-proof way to stop spam apps. These suggestions will curb the tide of comment spam that is being spewed by today’s spam apps--but tomorrow's spam apps, if adapted, would be able to circumvent these mechanisms. Anyways, onto the mechanisms.
Use Javascript
All of the spam apps I've encountered to date do not run Javascript. So you should utilize some Javascript mechanism to manipulate the form before it is submitted. You can dynamically change the form action URL upon loading or submission, update the value of a hidden field to indicate Javascript is present and functioning, etc. Any submission to the wrong form action URL or without the proper hidden field value should be discarded.
The downside of this approach is that it requires the user to have Javascript enabled in their browser. While Javascript is mostly ubiquitous in the Web 2.0 world we live in, browser plugins like NoScript are still highly popular. So you have to make the executive decision on whether you want to require your users to enable Javascript to use your form...which might not be a problem if you already require it for other things (i.e. Web 2.0 elements in use on your site).
Monitor the time it takes to fill out the form
My simple experiment kept track of the time between when a spam app requested the form to when the form was submitted. What I saw was that the form submission was done immediately. There is no way a human would be able to reasonably fill out the fields of the form in under, say, two seconds. This provides a simple way to discard spam simply by keeping track of when the form was requested (via a time value stored in server-side session storage or within a hidden form field) and when the form was received by submission (compare current time with previously stored time).
Now sure, spam apps can get around this by slowing down a bit during the form submission process. But since these apps are trying to spew out tens/hundreds of thousands of spammy form submissions, requiring each submission to slow down causes significant time overhead for the user of the spam app. Are they willing to be patient and wait 10 times longer for their spams to be submitted?
Use CSS to hide some form fields
The spam apps liked to populate every text input field in the form with some kind of value. You can wrap a field in a HTML DIV with a CSS style set to 'display:none', which essentially makes the field invisible. Normal CSS-capable web browsers will not display the field, so the user will never get a chance to enter input data into it. But the spam applications do not account for the hidden DIV, and thus will treat it like any other field on the form (and input a value). Thus all you need to do is see if that invisible form field contains a value upon submission, and if so, discard the submission. For safety, put a nice warning (also in the DIV) to users that they should not fill out the field if they see it; that way, if for some reason a user has a browser which is not CSS-compliant, they are still prompted to leave the field blank.
Textarea input field in HTML comments
I noticed one of the spam apps that hit my form just couldn't resist the temptation of populating data into a textarea input field that was within HTML comments. Normal browsers will ignore everything in comments, including the erroneous textarea field; so any submissions that include that field should be discarded as spam.
Don't use obvious form field names
Avoid using the field name 'email' for a user's email address, etc. In fact, you can turn this to your advantage: have the email field be named 'foo' or something else innocuous, and then check upon submission that the 'foo' field data format matches the format of an email address (which is typically done for validation purposes anyways). Since the spam apps often shove random garbage into fields they do not understand, you can discard any submission that does not contain what looks like an email address in the 'foo' field. Alternatives include checking numeric format in postal code or phone number fields, etc.
Overall, these few simple tricks can help you alleviate the flood of web comment spam that your site might be experiencing. They may not be perfect, but they are simpler to implement than a CAPTCHA and do provide some value from the current crop of web comment spam apps that are roaming the Internet. Every little bit helps.
Until next time,
- Jeff
Use Javascript
All of the spam apps I've encountered to date do not run Javascript. So you should utilize some Javascript mechanism to manipulate the form before it is submitted. You can dynamically change the form action URL upon loading or submission, update the value of a hidden field to indicate Javascript is present and functioning, etc. Any submission to the wrong form action URL or without the proper hidden field value should be discarded.
The downside of this approach is that it requires the user to have Javascript enabled in their browser. While Javascript is mostly ubiquitous in the Web 2.0 world we live in, browser plugins like NoScript are still highly popular. So you have to make the executive decision on whether you want to require your users to enable Javascript to use your form...which might not be a problem if you already require it for other things (i.e. Web 2.0 elements in use on your site).
Monitor the time it takes to fill out the form
My simple experiment kept track of the time between when a spam app requested the form to when the form was submitted. What I saw was that the form submission was done immediately. There is no way a human would be able to reasonably fill out the fields of the form in under, say, two seconds. This provides a simple way to discard spam simply by keeping track of when the form was requested (via a time value stored in server-side session storage or within a hidden form field) and when the form was received by submission (compare current time with previously stored time).
Now sure, spam apps can get around this by slowing down a bit during the form submission process. But since these apps are trying to spew out tens/hundreds of thousands of spammy form submissions, requiring each submission to slow down causes significant time overhead for the user of the spam app. Are they willing to be patient and wait 10 times longer for their spams to be submitted?
Use CSS to hide some form fields
The spam apps liked to populate every text input field in the form with some kind of value. You can wrap a field in a HTML DIV with a CSS style set to 'display:none', which essentially makes the field invisible. Normal CSS-capable web browsers will not display the field, so the user will never get a chance to enter input data into it. But the spam applications do not account for the hidden DIV, and thus will treat it like any other field on the form (and input a value). Thus all you need to do is see if that invisible form field contains a value upon submission, and if so, discard the submission. For safety, put a nice warning (also in the DIV) to users that they should not fill out the field if they see it; that way, if for some reason a user has a browser which is not CSS-compliant, they are still prompted to leave the field blank.
Textarea input field in HTML comments
I noticed one of the spam apps that hit my form just couldn't resist the temptation of populating data into a textarea input field that was within HTML comments. Normal browsers will ignore everything in comments, including the erroneous textarea field; so any submissions that include that field should be discarded as spam.
Don't use obvious form field names
Avoid using the field name 'email' for a user's email address, etc. In fact, you can turn this to your advantage: have the email field be named 'foo' or something else innocuous, and then check upon submission that the 'foo' field data format matches the format of an email address (which is typically done for validation purposes anyways). Since the spam apps often shove random garbage into fields they do not understand, you can discard any submission that does not contain what looks like an email address in the 'foo' field. Alternatives include checking numeric format in postal code or phone number fields, etc.
Overall, these few simple tricks can help you alleviate the flood of web comment spam that your site might be experiencing. They may not be perfect, but they are simpler to implement than a CAPTCHA and do provide some value from the current crop of web comment spam apps that are roaming the Internet. Every little bit helps.
Until next time,
- Jeff
Saturday, December 20, 2008
Ask Why Until They Slap You
As I mentioned last week, real benefit is subjective. I would derive no benefit whatsoever from tickets to a football game. Curling, on the other hand, is intriguing; attending a curling match would benefit me a great deal. In this case, based on the relative sizes of the curling and football industries in the United States, I am almost certainly in the minority. What meets one person's needs perfectly may not do a thing for someone else.
Furthermore, attending a curling match would benefit me because I like observing human, real-time approaches to infinitely variable analog control problems, whereas someone else might benefit by the opportunity to cheer for her son, who is playing on one of the teams. Which is to say, a single solution can have very different benefits for different people.
So how does one tell if, say, a security SaaS provides real benefit? If you're considering a security product, the steps go:
Those are both pretty big topics, so this week, let's delve into deciding what you actually need. Erik Simmons, Intel's requirements guru, has a surprisingly effective suggestion for eliciting the real requirements: Ask why until they slap you.
Requirements Guy: Why do you want to buy a product that filters bad HTTP stuff out?
Customer: Because I don't want my employees running malicious Javascript, installing Trojan horses, catching viruses, ...
Vendors in conversation with potential customers would probably stop here if they do everything mentioned (which of course we do), since being slapped by your customer is not what most people set out to do in the morning. But you, evaluating us, should not stop.
Requirements Guy: Why not?
Customer (giving Requirements Guy a funny look): Because that would be BAD! Everyone knows that!
Requirements Guy: Why would it be bad?
Customer (enunciating very clearly & speaking louder and louder): My employees would be unable to get any work done. My IT department would need more people to clean up the mess. My super-secret company data would go flying off to the four winds and all the regulatory agencies that apply in my line of work would shout at me. My name would be on the front page of the Wall Street Journal!
Requirements Guy is getting warm. He has unearthed several underlying concerns that are candidates for what Customer actually needs. But right now, only one of these concerns (people outside the company getting a copy of confidential corporate data) refers to an asset that can be directly manipulated by a computer. He needs to keep going to nail down the other concerns in a way that is useful for considering security benefit. Let's do one more.
Requirements Guy: Why wouldn't your employees be able to do their work?
Customer: Their computers wouldn't work!
Requirements Guy: Why would that stop the employees from getting their work done?
Customer: Their computers are the only way to get at all the corporate information they have to look at and create.
This time, Requirements Guy should really stop: one more why, and he's done for. He has an underlying asset (corporate information) and concern (availability), so let's say that the second concern this customer cares about is availability of information. You would need to follow up those other leads until you feel you've covered the important things you need.
Security can't ever give you the whole benefit you're looking for, only stop attackers from taking the benefit away. Therefore, to finish defining the security benefit you're looking for, you need one more thing: an attacker. For this purpose, the important part about an attacker is: before they start attacking, where are they in relation to your system and what can they already do? In this case, let's say you are expecting an attacker on the Internet (a good idea), and you assume he can control content on Web sites your employees visit. You would need to keep following leads to come up with a complete list of attackers you care about. For now, the benefit you are looking for becomes "Keep an attacker who controls Internet web sites my employees visit from denying my employees access to my corporate information." This is not going to be the only security benefit you want, but I'll use it as an example next week when I talk about figuring out whether controls a vendor offers make the benefit you want possible.
Now let's suppose I'm Zscaler. As a security SaaS, how do I ensure that I'm providing real benefit? The steps go:
--Brenda
Furthermore, attending a curling match would benefit me because I like observing human, real-time approaches to infinitely variable analog control problems, whereas someone else might benefit by the opportunity to cheer for her son, who is playing on one of the teams. Which is to say, a single solution can have very different benefits for different people.
So how does one tell if, say, a security SaaS provides real benefit? If you're considering a security product, the steps go:
- Decide what you actually need.
- Determine whether the technological controls provided by the solution you are considering will get you that.
Those are both pretty big topics, so this week, let's delve into deciding what you actually need. Erik Simmons, Intel's requirements guru, has a surprisingly effective suggestion for eliciting the real requirements: Ask why until they slap you.
Requirements Guy: Why do you want to buy a product that filters bad HTTP stuff out?
Customer: Because I don't want my employees running malicious Javascript, installing Trojan horses, catching viruses, ...
Vendors in conversation with potential customers would probably stop here if they do everything mentioned (which of course we do), since being slapped by your customer is not what most people set out to do in the morning. But you, evaluating us, should not stop.
Requirements Guy: Why not?
Customer (giving Requirements Guy a funny look): Because that would be BAD! Everyone knows that!
Requirements Guy: Why would it be bad?
Customer (enunciating very clearly & speaking louder and louder): My employees would be unable to get any work done. My IT department would need more people to clean up the mess. My super-secret company data would go flying off to the four winds and all the regulatory agencies that apply in my line of work would shout at me. My name would be on the front page of the Wall Street Journal!
Requirements Guy is getting warm. He has unearthed several underlying concerns that are candidates for what Customer actually needs. But right now, only one of these concerns (people outside the company getting a copy of confidential corporate data) refers to an asset that can be directly manipulated by a computer. He needs to keep going to nail down the other concerns in a way that is useful for considering security benefit. Let's do one more.
Requirements Guy: Why wouldn't your employees be able to do their work?
Customer: Their computers wouldn't work!
Requirements Guy: Why would that stop the employees from getting their work done?
Customer: Their computers are the only way to get at all the corporate information they have to look at and create.
This time, Requirements Guy should really stop: one more why, and he's done for. He has an underlying asset (corporate information) and concern (availability), so let's say that the second concern this customer cares about is availability of information. You would need to follow up those other leads until you feel you've covered the important things you need.
Security can't ever give you the whole benefit you're looking for, only stop attackers from taking the benefit away. Therefore, to finish defining the security benefit you're looking for, you need one more thing: an attacker. For this purpose, the important part about an attacker is: before they start attacking, where are they in relation to your system and what can they already do? In this case, let's say you are expecting an attacker on the Internet (a good idea), and you assume he can control content on Web sites your employees visit. You would need to keep following leads to come up with a complete list of attackers you care about. For now, the benefit you are looking for becomes "Keep an attacker who controls Internet web sites my employees visit from denying my employees access to my corporate information." This is not going to be the only security benefit you want, but I'll use it as an example next week when I talk about figuring out whether controls a vendor offers make the benefit you want possible.
Now let's suppose I'm Zscaler. As a security SaaS, how do I ensure that I'm providing real benefit? The steps go:
- Derive the underlying concerns of a substantial set of my customers or prospective customers.
- Ensure the technological controls I provide can be configured to meet those underlying concerns in the space I've set out to protect.
--Brenda
Thursday, December 18, 2008
Turning a Blind Eye
All too often, evil is lurking right under our noses, yet we choose to turn a blind eye. Sometimes we do this out of fear. After all, if we get involved, we too could get hurt. Other times however, we are just as much to blame as the guilty parties perpetrating the crime. We choose not to get involved because we too profit from the crime, although we do so passively and leverage that as our defense.
A couple of years ago, I drew attention to the fact that free website providers were profiting from allowing phishers to set up shop and doing nothing to stop them. They were profiting as they make money from ad-supported pages. The more traffic they generate, the more money they make and how that traffic is generated doesn’t seem to be of concern. I ruffled a few feathers by speaking my mind and generated a much-needed debate on the issue. The argument from the hosting providers was that they try very hard but some pages slip through the cracks. Although I don’t buy the excuse, to be fair, automating the detection of phishing pages isn’t without challenges. What about malware then? Do these same sites foot the bill for hosting/delivering malicious binaries? Sadly, the answer is yes.
Being an ‘in-the cloud’ security solution, our Zscaler infrastructure permits powerful data-mining capabilities from a research perspective. The very nature of a cloud architecture means that logs can be centralized, providing a powerful view into global attacks. Leveraging this capability, I sought to identify malware being hosted on free web sites. It didn’t turn out to be much of a challenge as evidence was everywhere. A sample of what was discovered can be seen below:
Caution: At the time of this blog post, these URLs were live and hosting malware – proceed at your own risk.
Geocities (Owned by Yahoo!)
http://www.geocities.com/sltap/main.html
http://india_resource.tripod.com/indianhistory.html
http://www.angelfire.com/tx5/jr2k/Stor/2.html
So why then wouldn’t they make an effort to eradicate viruses from their servers? The answer is simple. The cost to do so outweighs the benefits derived. In other words, removing content from their sites reduces the number of eyeballs they receive and in turn decreases ad revenue. They are turning a blind eye to the fact that their users are getting infected with malware.
Gross negligence can be defined as “failure to use even the slightest amount of care in a way that shows recklessness or willful disregard for the safety of others”...sounds like an open and shut case to me.
- michael
A couple of years ago, I drew attention to the fact that free website providers were profiting from allowing phishers to set up shop and doing nothing to stop them. They were profiting as they make money from ad-supported pages. The more traffic they generate, the more money they make and how that traffic is generated doesn’t seem to be of concern. I ruffled a few feathers by speaking my mind and generated a much-needed debate on the issue. The argument from the hosting providers was that they try very hard but some pages slip through the cracks. Although I don’t buy the excuse, to be fair, automating the detection of phishing pages isn’t without challenges. What about malware then? Do these same sites foot the bill for hosting/delivering malicious binaries? Sadly, the answer is yes.
Being an ‘in-the cloud’ security solution, our Zscaler infrastructure permits powerful data-mining capabilities from a research perspective. The very nature of a cloud architecture means that logs can be centralized, providing a powerful view into global attacks. Leveraging this capability, I sought to identify malware being hosted on free web sites. It didn’t turn out to be much of a challenge as evidence was everywhere. A sample of what was discovered can be seen below:
Caution: At the time of this blog post, these URLs were live and hosting malware – proceed at your own risk.
Geocities (Owned by Yahoo!)
http://www.geocities.com/sltap/main.html
- Malware found - Virus.VBS.Redlof.a
- VirusTotal Results - 32/37
- Malware found - Virus.VBS.Redlof.n
- VirusTotal Results - 26/37
- Maware found - Net-Worm.Win32.Nimda
- VirusTotal Results - 30/37
- Malware found - Virus.VBS.Confi
- VirusTotal Results - 32/37
- Malware found - Virus.VBS.Redlof.a
- VirusTotal Results - 23/38
- Malware found - Virus.VBS.Redlof.a
- VirusTotal Results - 33/38
http://india_resource.tripod.com/indianhistory.html
- Malware found - Virus.VBS.Redlof.a
- VirusTotal Results - 34/38
- Malware found - Virus.VBS.Redlof.a
- VirusTotal Results - 34/38
http://www.angelfire.com/tx5/jr2k/Stor/2.html
- Malware found - Virus.VBS.Redlof.k
- VirusTotal Results - 27/38
So why then wouldn’t they make an effort to eradicate viruses from their servers? The answer is simple. The cost to do so outweighs the benefits derived. In other words, removing content from their sites reduces the number of eyeballs they receive and in turn decreases ad revenue. They are turning a blind eye to the fact that their users are getting infected with malware.
Gross negligence can be defined as “failure to use even the slightest amount of care in a way that shows recklessness or willful disregard for the safety of others”...sounds like an open and shut case to me.
- michael
Saturday, December 13, 2008
Avoiding Snake Oil: SaaS Challenges
It can be awkward to talk to other security geeks between when you accept a job at a startup and when you have worked there long enough to figure out what is actually going on:
Other Geek: What do they do?
Me: Client security using a SaaS model.
Other Geek: How does that work?
Me: They filter the traffic between the client and whatever it's talking to on the Net. It's cool because the customer configures stuff once for all their sites (clicky, clicky) instead of having to install & configure a bunch of boxes at each site. Plus it can protect people working from coffee shops.
Repeat Indefinitely:
Other Geek: Completely reasonable questions about successively more detailed engineering and business concerns, all of which boil down to "How could that possibly work?"
Me: Increasingly vague hand waving, as the questions proceed further and further away from my limited knowledge of what my soon-to-be employer actually does.
The only plus side of conversations during this period is, you know you aren't revealing anything secret, because you don't know anything yet.
As I finish my first week of work at Zscaler, I have a lot more idea of what is going on, and I have acquired my first self-assigned mission: making sure that what we are selling is not, and never becomes, snake oil, whether or not all other available solutions are unctuous or reptilian. Because of our line of work I'd say we have some risk in this area (as many of my friends and acquaintances were keen to point out), and I'm not too worried about ensuring we are the best available solution, since plenty of my coworkers are focused on that.
I see 3 keys to avoiding snake oil, from a vendor's perspective:
Accurate customer expectations
The customer must understand what to expect, and their understanding must match what is actually going to happen. Since the vendor knows what is actually going to happen, the vendor has to make sure the customer has the right impression. This is tricky for any security product. As security people know but other people would usually rather not hear, 100% protection is not possible. To make things worse, 90% protection doesn't mean anything, since even within the security industry there is no simple, well-understood metric for describing how much protection a particular product provides. Security people would normally describe specific kinds of protection provided and the strategy for implementing each, but non-security people don't have the background to understand what this implies for them. And because each situation is different, the security people need more information about each customer to be able to explain the implications.
Real benefit
The product must actually do something to protect the customer in ways that matter. Since real benefit can be in the eye of the beholder, security vendors need to consider benefit from the viewpoint of a hypothetical security-knowledgeable customer; a representative such person may or may not exist. Some things are clear: it is valuable to protect against attacks that are actually occurring and would have worked if the product hadn't stopped them. It is less clear whether protecting against attacks that are still theoretical is worthwhile. It is also apparent that the scope of protection must cover gaps in other protections the customer is planning to use. This is a challenge for security as a service today, because a SaaS model implies a new way to partition the problem, so existing products may not mesh well. On the deeply unclear side: for non-security people, it isn't about viruses, botnets or cross-site scripting, it's about somebody erasing important data, clogging the network, stealing intellectual property, and so on. But protection tends to be organized by security geeks, i.e. by class of attack it defends against. Whether protecting against viruses, but not botnets, is enough to be valuable depends on customer expectations and scope considerations. Finally, the lack of metrics applies here, too: currently it is very difficult to quantify how much protection is enough.
Verifiable benefit
The customer must be able to verify that they are actually being protected in the way they expect to be protected. This can be tricky for the same reasons setting accurate customer expectations is tricky, but for an in-the-cloud security service, it is even harder. After all, in the ideal world, a customer is protected but not inconvenienced, i.e. the customer never notices the service. In most cases, all a customer has to go on is the vendor's word that protection has taken place. Certainly security in the cloud is blacker than black box: a would-be tester doesn't even have a box to play with directly, and the box is intended to change regularly without warning or customer intervention. Few companies are paranoid and wealthy enough to employ skilled security folks to set up an ongoing independent monitoring system. In this situation, it will be tricky but even more important for vendors to supply an answer beyond the infamous "trust us, we know what we're doing".
Until now, I've always been on the other side of the fence, poking at products and determining whether they live up to my exacting standards. The view is a little different from over here, but I feel confident. Keep watching and we'll all find out how Zscaler meets these challenges.
-- Brenda
Other Geek: What do they do?
Me: Client security using a SaaS model.
Other Geek: How does that work?
Me: They filter the traffic between the client and whatever it's talking to on the Net. It's cool because the customer configures stuff once for all their sites (clicky, clicky) instead of having to install & configure a bunch of boxes at each site. Plus it can protect people working from coffee shops.
Repeat Indefinitely:
Other Geek: Completely reasonable questions about successively more detailed engineering and business concerns, all of which boil down to "How could that possibly work?"
Me: Increasingly vague hand waving, as the questions proceed further and further away from my limited knowledge of what my soon-to-be employer actually does.
The only plus side of conversations during this period is, you know you aren't revealing anything secret, because you don't know anything yet.
As I finish my first week of work at Zscaler, I have a lot more idea of what is going on, and I have acquired my first self-assigned mission: making sure that what we are selling is not, and never becomes, snake oil, whether or not all other available solutions are unctuous or reptilian. Because of our line of work I'd say we have some risk in this area (as many of my friends and acquaintances were keen to point out), and I'm not too worried about ensuring we are the best available solution, since plenty of my coworkers are focused on that.
I see 3 keys to avoiding snake oil, from a vendor's perspective:
Accurate customer expectations
The customer must understand what to expect, and their understanding must match what is actually going to happen. Since the vendor knows what is actually going to happen, the vendor has to make sure the customer has the right impression. This is tricky for any security product. As security people know but other people would usually rather not hear, 100% protection is not possible. To make things worse, 90% protection doesn't mean anything, since even within the security industry there is no simple, well-understood metric for describing how much protection a particular product provides. Security people would normally describe specific kinds of protection provided and the strategy for implementing each, but non-security people don't have the background to understand what this implies for them. And because each situation is different, the security people need more information about each customer to be able to explain the implications.
Real benefit
The product must actually do something to protect the customer in ways that matter. Since real benefit can be in the eye of the beholder, security vendors need to consider benefit from the viewpoint of a hypothetical security-knowledgeable customer; a representative such person may or may not exist. Some things are clear: it is valuable to protect against attacks that are actually occurring and would have worked if the product hadn't stopped them. It is less clear whether protecting against attacks that are still theoretical is worthwhile. It is also apparent that the scope of protection must cover gaps in other protections the customer is planning to use. This is a challenge for security as a service today, because a SaaS model implies a new way to partition the problem, so existing products may not mesh well. On the deeply unclear side: for non-security people, it isn't about viruses, botnets or cross-site scripting, it's about somebody erasing important data, clogging the network, stealing intellectual property, and so on. But protection tends to be organized by security geeks, i.e. by class of attack it defends against. Whether protecting against viruses, but not botnets, is enough to be valuable depends on customer expectations and scope considerations. Finally, the lack of metrics applies here, too: currently it is very difficult to quantify how much protection is enough.
Verifiable benefit
The customer must be able to verify that they are actually being protected in the way they expect to be protected. This can be tricky for the same reasons setting accurate customer expectations is tricky, but for an in-the-cloud security service, it is even harder. After all, in the ideal world, a customer is protected but not inconvenienced, i.e. the customer never notices the service. In most cases, all a customer has to go on is the vendor's word that protection has taken place. Certainly security in the cloud is blacker than black box: a would-be tester doesn't even have a box to play with directly, and the box is intended to change regularly without warning or customer intervention. Few companies are paranoid and wealthy enough to employ skilled security folks to set up an ongoing independent monitoring system. In this situation, it will be tricky but even more important for vendors to supply an answer beyond the infamous "trust us, we know what we're doing".
Until now, I've always been on the other side of the fence, poking at products and determining whether they live up to my exacting standards. The view is a little different from over here, but I feel confident. Keep watching and we'll all find out how Zscaler meets these challenges.
-- Brenda
Friday, December 12, 2008
Overweight Thin Clients
I remember the dawn of the new millennium well. The Internet boom was in full swing and we were predicting the death of the PC. Fat-client machines would no longer be needed in an Internet driven world as people would require only an Internet capable device to access everything they had ever dreamed of. Companies like Netpliance quickly jumped on the bandwagon, offering cheap Internet appliances such as the i-Opener. The game plan was to take a loss on hardware and recoup the cost by selling Internet services. Many agreed that this was the future, but after only a couple of years in business and a measly $230,000 in sales, the writing was on the wall - we weren't ready to give up our beloved PC. Netpliance became TippingPoint and the days of the 'Internet toaster' were...well...toast.
Cloud computing has once again promised a world in which thin clients will rein supreme - all data and processing will occur in the cloud so you'll only need a basic device with minimal processing power. This time around, everyone is jumping on the netbook bandwagon - cheap, mini-laptops with minimal processing power. Is it a fad this time as well, or are we finally ready to turn in our PCs?
Interestingly, browsers are moving in the opposite direction. They've been suffering from feature bloat for a while now (email clients, RSS readers, etc.), but now we're actually changing the architecture of web applications to push data and processing to the client. Adobe Flash has been around forever but the Rich Internet Application room is now getting pretty crowded with the likes of Google Gears, Microsoft Silverlight, JavaFX, etc. Google has also recently released Native Client, an effort to run x86 native code in web applications. All of these projects are blurring the line between desktop and web applications.
Is this a good thing? Time will tell. Does it present new security challenges? Certainly. Applications are becoming increasingly complex and distributed. This always raises the bar and makes makes security a greater challenge. We're no longer dealing with simple static HTML. Now we may have interpreted scripts alongside compiled binaries, all of which are sitting on different machines and may well include untrusted code written by a third party. Webapp security has gone from being a profession for those who didn't have the time/skill/interest in learning reverse engineering skills to the cutting edge of security and suddenly, those RE skills are starting to look pretty valuable once again. Another security issue involves pushing data to the client for storage and processing. It's relatively easy to secure data on a server (we finally seem to be getting a handle to the SQLi thing...after a decade of preaching), but it's a different story when data sits on every client. Developers must take great care in deciding what is pushed to clients as the gloves come off any time you no longer have control of the device where sensitive data resides. Will developers understand the security challenges of this new architecture? History suggests that it will simply open another chapter in the many challenges which we face in enterprise security.
So what will it be - streamlined thin clients or powerful workhorses? What does the future have in store for us? As a guy that just can't help but buy the most powerful device available, I expect that client side storage/processing has just started to evolve - netbooks on the other hand may well go the way of the Internet toaster.
- michael
Cloud computing has once again promised a world in which thin clients will rein supreme - all data and processing will occur in the cloud so you'll only need a basic device with minimal processing power. This time around, everyone is jumping on the netbook bandwagon - cheap, mini-laptops with minimal processing power. Is it a fad this time as well, or are we finally ready to turn in our PCs?
Interestingly, browsers are moving in the opposite direction. They've been suffering from feature bloat for a while now (email clients, RSS readers, etc.), but now we're actually changing the architecture of web applications to push data and processing to the client. Adobe Flash has been around forever but the Rich Internet Application room is now getting pretty crowded with the likes of Google Gears, Microsoft Silverlight, JavaFX, etc. Google has also recently released Native Client, an effort to run x86 native code in web applications. All of these projects are blurring the line between desktop and web applications.
Is this a good thing? Time will tell. Does it present new security challenges? Certainly. Applications are becoming increasingly complex and distributed. This always raises the bar and makes makes security a greater challenge. We're no longer dealing with simple static HTML. Now we may have interpreted scripts alongside compiled binaries, all of which are sitting on different machines and may well include untrusted code written by a third party. Webapp security has gone from being a profession for those who didn't have the time/skill/interest in learning reverse engineering skills to the cutting edge of security and suddenly, those RE skills are starting to look pretty valuable once again. Another security issue involves pushing data to the client for storage and processing. It's relatively easy to secure data on a server (we finally seem to be getting a handle to the SQLi thing...after a decade of preaching), but it's a different story when data sits on every client. Developers must take great care in deciding what is pushed to clients as the gloves come off any time you no longer have control of the device where sensitive data resides. Will developers understand the security challenges of this new architecture? History suggests that it will simply open another chapter in the many challenges which we face in enterprise security.
So what will it be - streamlined thin clients or powerful workhorses? What does the future have in store for us? As a guy that just can't help but buy the most powerful device available, I expect that client side storage/processing has just started to evolve - netbooks on the other hand may well go the way of the Internet toaster.
- michael
Subscribe to:
Posts (Atom)
Posts
