June 25, 2009
Looks like Jakob Nielsen is at it again. The man certainly knows his usability stuff, and although he’s often controversial, and seldom “wrong”, he does put out some “doosies” every once in a while. His latest column on web usability calls for people to stop using password masking – effectively not using the “type=password” attribute on input fields.
Now, he puts out a good argument – there’s certainly times when it’s much easier to enter a password (especially on a mobile device) when you can see the characters you are entering. Also, knowing you are entering in the right characters probably will mean less errors and people using stronger, more complex, passwords. There’s also times when you know you want to protect from shoulder-surfing, and a simple checkbox could re-enable password masking on the few occasions it’s really required. All very valid points.
My worry is though that without the “type=password” attribute, browsers won’t know that it’s a password field and won’t protect it accordingly. All browsers cache data, depending on settings, to “help” users when they have to re-enter information, but certain data should always be discouraged from being cached – it’s just too easy to dig it back out of the browser [PDF link].
Liberal use of the “autocomplete=off” attribute on these forms (or, non-standard[ly], on the fields themselves) does discourage browsers from caching that data, but in my trawls around the web both as a user and a security tester I see it used very infrequently.
Having the “type=password” is a way of “default denying” as all web developers know to use this field for passwords and the browser just takes care of the rest by not caching these types of fields, and even providing a warning if you are going to send them in clear text over HTTP. Developers don’t even have to think about it – they know it’s a password, so a password field they use, and leave the browser to provide sensible default protection.
Unless we are going to change the way that browsers render “type=password” fields, and leave the web developers to use them as intended, but with subtly different UI (opt-in of course), I have to say this is a non-starter for me. I certainly don’t want to see developers “faking it” with JS/AJAX and modifying input box types on-the-fly because once again that can introduce insecure behavior if you’re not really careful. We have a default “fail closed” state in password fields and modifying it, calling for it to be changed, or just plain removing it I feel will introduce issues because there’s already a built-up expectation of the working-model – developers don’t change their working model or practices all that easily.
Oh, and the other point Jakob makes about reset buttons – I fully agree – kill the buggers buttons. Thing is though that I rarely see them any more so I guess we are getting a little better (in UI at least).
UPDATE: Looks like this has hit Schneier’s site, and as he gets obviosuly gets more viewers that I do, it’s good to look at the comments. Most people seem to agree in leaving the password field alone.
Posted in Musings, Security 
3 Comments »
June 22, 2009
After some delay, WebSec101 is live! What is it you ask?
The WebSec101 series introduces the basics of web and application security in easy to digest 20-30 minute webcasts. It aims to give brief introductions to each of the major topics in testing, developing and securing web applications, and points the viewer to more detailed material if interested.
I don’t think this is anything “new” – a lot of this information is already out there – but I’ve found talking to clients and others in the industry that there’s not a lot of easily digestible material out there on this subject in a format that is easy to learn from. OWASP and the Web Application Security Consortium (amongst others) are a great source of info, but there’s a considerable amount of material to get though and what I’m hearing is that people would like a gentle start to ease them into the subject area and “wet their appetite”.
As the above text says, these are “101 level” (or basic/introduction to those of you outside the US education system) webcasts of about 30 minutes in length and intended to at least give the viewer a start in web application security – something you can sit with a cup of coffee and watch/listen to quickly. They are not Foundstone’s Ultimate Web Hacking class, but a subset of that material (and no hands-on, instructor-led labs unfortunately), but are free (and released under a Creative Commons license).
I’ve been working on these webcasts for some while now but finally pulled the trigger thanks to the help of some of my colleagues. I wanted them to be really good, and to release them within a reasonable schedule. Several things including work getting really busy at the start of the year conspired against me, but it’s best to get them out there, get feedback, and try to keep up. I have a small buffer of episodes “in the can”, but the plan is to release every 2 weeks on the Foundstone website.
The rest is all in the introduction webcast (HD, LD, Podcast and/or slides). I’m hoping that through these I will be able to share the knowledge that I have, that of my colleagues in Foundstone, and the security industry at large to a more “general” audience – the “practitioners” one may say. A lot of the clients that I deal with are not necessarily first-timers to the needs of application security (or they wouldn’t be calling Foundstone), but some guidance along the first steps certainly help and I’ve noticed the clients I work with repeatedly get better and better though education and knowledge (and tools, but that’s a future episode 
). This is a long journey and we’re starting slow with these webcasts, but hopefully we’ll keep these going, at least to cover the major issues and topics I see out there all the time, and who knows – with feedback, ideas, and requests this may go on and on.
I hope you enjoy.
Posted in Security 2 Comments »
June 21, 2009
Talking to a lot of people in security and consultancy in general, it’s pretty clear that a) we do a lot of travel as part of our job and b) pretty much have travel down in things that work for us, what we pack, etc. In some ways I have to be thankful in that I haven’t had to do a lot of travel recently – switching roles from customer facing consultant to an internal research/development/architect role means I get to stay at home more and work from my home office instead. I’m probably still on the road about 1 week of every month, month and a half, which compared to some of my other colleagues is very leisurely, but generally I don’t mind traveling – it’s nice to go to new places and explore, especially when it’s on someone else’s dime!
Main bag
I’ve spend ages (and lots of $$$) getting the “right” bag and I think this is the one for me. I’ve had Oakley bags, Crumpler bags, Timbuk2 bags, but the Swiss Gear Synergy backpack is what I’ve used for well over a year now. Some people have shoe fetishes; mine’s bags. I keep getting/changing bags so often but the fact I’ve had and used this one for so long must mean something!
Comms
Currently I have have an ATT Tilt phone which does me very well. Because of work I don’t have an iPhone (incompatible email – Blackberry or GoodLink – don’t even ask) which I guess I would consider, but I have to have email on my phone and I’m not carrying two devices. When it’s available on a GSM provider (ATT or T-Mobile in the US) I’m really going to look at getting the Touch Pro 2. In addition to the phone itself I always carry a spare battery just in case (after a long day of consulting, and especially IR work, batteries drain quickly – more reason not to go with an iPhone 
) and a spare charger so I don’t have to remember to pick up the one at home each time. For a headset, which I honestly don’t use all that much, the Jawbone 2 has been excellent.
Peripherals
I use a Kensington power supply with multiple tips for other devices I carry so I don’t have to pack multiple chargers. Yeah, I know the cell phone charger is a separate one, but I’ve found I have to carry at least these two or I forget to charge my phone each night! Looking to pickup a Belkin power splitter so I can use/charge multiple things when there’s limited power outlets like in airports and some hotels.
I also carry a Kensington laptop lock which I always use because it’s just too easy to walk away with a laptop and have seen it many times. I wouldn’t be all that worried about the data as I use SafeBoot and PGP VirtualDisks for client information, but being without a laptop would be a major PITA.
In the case is a headset/mic and a webcam. I use the two for staying in touch with home when I’m traveling and conferences calls via Skype. The choice for the Logitech headset was as much for the case as the headset itself – although the headset is good, having a solid place to put it and some other things at a squeeze, sold it for me as I’ve busted many others by not having having a place to protect them
Rounding out I have a general power converter (only needed when traveling international), a short USB cable (never know when you need one), and a Microsoft ARC mouse – a tad expensive for what it is, but has been the best travel mouse I’ve had in a while and folds up into nothing.
Entertainment
Sitting on a plane or in a hotel room can be boring. I have a 32GB iPod touch with lots of music, a few audio books and no video (see later). I’ll always have a separate media device as the last thing I want is to get off a flight only to find I’ve used up all the juice of my phone – if the iPod runs out, then I’m not stuck. Pairing with the iPod I have a set of Sure SE210 in-ear buds. I’ve tried the noise cancelling headsets and they make me feel like my head is underwater. These are really light, great sound, and I’ve used Sure stuff for years so I know are good quality.
I always have some book on the go (no Kindle for me for lots of reasons, but primarily when I’m done I like to pass my books on) and stuff some magazines into the bag as well (yes, that is Geek magazine – you got a problem with that?). Not pictured is that I have a Tivo (a real one – not a crappy DVR) at home and a SlingBox so I can catch up with TV. I also have a homeserver that I can grab videos off if I’m really bored, although that seldom happens; mostly the homeserver is for backups and offline storage and has meant that I can now ditch a USB hard disk I used to travel with.
GPS
Very recently I got a cheep TomTom. This is pretty new to my travel collection as I got fed up with paying (extortionately) for one at the car rental when going to a new place. I used to either use the GPS on my phone, or print out maps, but it’s good to have when you have to find a client’s office and also somewhere to have dinner in a place you’ve never been before. I make use of a few Eagle Creek cubes to separate things out (I can grab what I need easier when I go, and though TSA if necessary) and to make my bag a bit easier to manage
Misc
In the “i don’t know what to class this under”, there’s a few other things I have in my bag. A blow-up travel cushion helps me get some sleep on planes (I prefer to have a window seat where possible so I can prop myself up), as well as some ear-plugs if I’m not listening to my iPod.
I try to be conscious that talking lots makes your breath smell, so I have some TicTacks or breath strips/mints. An Oakley lanyard is useful sometimes for security badges and to hold keys so I don’t lose/forget them. The Oakey vault case (did I say how much I love Oakley products) holds my sunglasses while in the bag so they don’t get crushed.
Business cards are a necessity, as is my Moleskin notebook and Fisher space pen – my handwriting isn’t great so I don’t make that many handwritten notes, mostly I use my laptop, but in meetings I’m not a huge fan of peering over laptop screens and it’s easy to get distracted into the laptop rather than what is going on in the meeting. There’s a multi-function screwdriver/light/etc that was a Foundstone freebie a while back that I’ve just never removed from my bag, and some Crystal Light (always Orange for me) that gives water a little bit more taste (I always grab a bottle of water before getting on a flight – you have no idea how often the trolley service is going to be).
Laptop
I don’t get much choice with the laptop other than going out an buying one myself. As I can get though about one a year (which goes back to our fantastic Tim that swaps them for us and revives them back to life, good as new), I’m reluctant to get my own although I’d like a tablet like a Dell XT2 or HP TX2Z, depending on how well they fit with my home setup – has to support a external multi-monitor setup. So, after all that explanation I have a Dell D630 which does me fine.
Case
The final thing is the main case that I use. I hate checking luggage not only because of the probability of it getting lost, but the time waiting to pick it up at baggage claim, so I have a carry on. I’ve had Samsonite cases for years – my old Oyster case has literally been round the world a few times and survived 4 years of constant touring and being thrown in the back of trucks. I much prefer hard-side cases because they can take more abuse than soft sides and their zippers. I can’t even remember the name of this case I have because I’ve had it for over 5 years (with one trip back to a Samsonite repair shop for minor fixes) – this thing is an absolute tank! Generally I can easily pack for 1-1.5 weeks (or longer with a laundry stop) in here. I won’t go into packing this case because it changes depending on where I’m going, the client, climate, etc, etc, but I’m sure you get the idea.
There’s a lot of plusses and minuses in consulting as Curphey pointed out in an old blog post. Travel for some can be a no-go, but I’m pretty used to it from my previous career. If anything, the thing that get me riled the most about having to travel as part of work is the notice part – for an IR gig I expect to be on a plane within a few hours, but other work I at least expect a couple of weeks. Duration is a big thing as well with a lot of people, and I don’t think I could handle any more than 50% for a long duration.
However, travel can be fun, especially if you do it right. Lifehacker has had a series on people’s “go bags”, but I guess this is slightly different – this is my travel setup, and although I guess in some way it is my “day-to-day”, I know that in a different job without travel my bag would be very different. These are the tips and technology that I travel with, and I would bet that many others have their own. If you do and want to share, I’d love to hear about it either in the comments, or better your own blog post. .
Posted in Misc, Personal No Comments »
June 19, 2009
Thanks to Jeremiah Grossman (via twitter), I found this post on the Mozilla blog.
Shutting Down XSS with Content Security Policy
A Jeremiah says, this is a game changer in the realm of XSS. By making some small modifications to how you use JavaScript in your site (putting it all in an external file served by an approved host), the Firefox browser should be able to know what scripts it “trusts” (because it came from somewhere it knows and should be part of the page) from “malicious” (ones that are not part of the legitimate site because they have been injected somehow).
What’s going to interest me is how this is enabled. The browser has to understand to apply this policy and there’s going to have to be some “opt-in” from the site that’s in the HTML received from the browser, some header, or some file that’s loaded in. Unless we’re all going to use HTTPS (which we know has it’s own issues of adoption), then what is stopping someone from MITM’ing and forcing an “opt-out” so the browser does not apply the protection leaving the site vulnerable. It’s a small vulnerability that’s immediately obvious before there’s any sites to start looking at – I’m sure there’s going to be other ways of either removing the header or making the policy not load (and/or enforce) correctly once we start looking at this technology in earnest.
As they say though, the devil is in the details, so the implementation of this is what is going to be important. The cross-domain policy and protections in current browsers are a similar strategy, but we still see flaws and attacks against that. I guess we’ll be seeing new research breaking the XSS content security policy as it gets out there, but props to Mozilla though as it’s certainly going to raise the bar. If we can raise the bar height enough that only Olympic-standard athletes can make it over, leaving all the script-kiddies behind, then that can only be a good thing.
I’m not too worried about any of the initial issues (and there’s sure to be some) as over time I would hope to see this technology get better and more widely adopted which very may well spell the end of a very large part of the XSS problems out there.
Posted in Security No Comments »
June 16, 2009
In an open letter to Google, some familiar names in security call for Google, and other web-based application providers by proxy, to strengthen security by doing one simple thing – enable HTTPS by default.
If you haven’t read the letter, go back an do so [PDF link]. Please. I’ll wait. Lots of people don’t get the importance of a complete HTTPS session (not just when logging in) and hopefully this will help. Cliff Notes version:
- Once you have logged in, your session (often via a cookie but not always) is your “token” to that account. Steal it, or inadvertently disclose it (via HTTP), and the person who has that token can effectively become logged in without knowing the credentials or having to going through the authentication process(1). If you don’t know what that means, look here for an example.
- On a mixed HTTP/HTTPS session, an attacker can do some funky things that can break the cross-domain protections and then once again it’s game over – you can’t trust the screen you are seeing and the attacker has control over the browser (session token stealing again, malicious code injection, DOM manipulation, browser flaws, etc, etc).
- You would assume that in most cases even without account takeover or other injection issues that the information going over the wire you don’t want to broadcast to anyone that’s listening. Many people’s personal lives are run via web-based email setups and it’s been said many times – gaining someone’s webmail account effectively mean you can gain access to lots of other accounts belonging to that person via password reset functionality. Webmail is the de-facto master password of the net.
So, there’s very good reason to go HTTPS only. However, there’s downsides to this. First one is pretty obvious, second one no so much.
- Performance. Many companies assume that having everything go over HTTPS will have a huge performance impact. There’s no doubt that there’s some performance impact, but the major cost is the HTTPS handshake in the browser and server agreeing on a cipher. Once that is done, modern browsers can cache that agreement and not have to go through it again. In some cases it makes sense to keep the connection open. I should really do my own experiments, but it seems the even an old comparison showed very little degradation of performance on old(er) servers/browsers and without SSL concentrators. A newer paper [PDF link] with lot more detail certainly shows degradation, but only at high throughputs – something certainly Google or a large/popular service would be concerned about.
- Injections. Not the kind of injections we don’t want (2), but injecting ads into HTTPS pages is a lot harder. If it’s being done cross-site you get those horrible popup “mixed content” warning messages, and if it’s “force injected” (which no-one seems to be doing now, but ISP’s had some fun trying it. With Google’s main revenue being ads, I can see how that might be an issue.
So, first props for Google mentioning it and of all the main providers of web-based apps out there are doing the right thing, even if not by default. Second, I’m sure that it would have been done already if there wasn’t concerns, and I’m certain that Google (being Google) are crunching the number to see what impact it will have. I’m not going to hold my breath, but at least it’s “out there” and I hope more people enable SSL by default.
My belief is that we’re relying on the web so much now that we’re going to have to consider encrypted communication to be the default. Whether that’s VPNs, SSL concentrators, HTTPS-by-default, I’m not sure – it would be really interesting to see some recent stats of a) the amount of HTTP vs HTTPS traffic out there and b) the impact of HTTPS on a well-designed infrastructure setup to handle it. If anyone has that info please get in touch while I go about looking for it myself and update here if I find anything interesting. HTTPS/SSL isn’t the great panacea/silver bullet, but as the story goes, it does provide something and from there we can worry about all the other issues in webapps.
(1) There are ways of further protecting the session token if it is disclosed through tying it to an IP address, browser version, etc, etc, but it’s not foolproof.
(2) I still would rather not have ads injected into any of my pages, but understand the model. I don’t mind paying for services that I use, but it seems I’m in the minority.
Posted in Uncategorized 2 Comments »
June 10, 2009
Thanks to Alex (who BTW is leaving Foundstone to go back to university – the very best of luck mate 
), I heard of this collection of plugins that Adam Muntner has put together.
https://addons.mozilla.org/en-US/firefox/collection/webappsec
Certainly a great collection – I have some of those installed myself, but certainly not all as I’m much more of a Paros proxy guy! There’s probably way too many toolbars if you install everything and I don’t really want my browser looking like this.
Anything that makes it easier though I’m all for, so have a look at this collection and have a play. My core is Add N Edit Cookies, Web Developer toolbar, and ProxyButton (not in the collection, but with the other tools perhaps not needed) – pretty much everything else I do in Paros – but you very well may find some of them useful, especially while starting out.
Posted in Security 5 Comments »
June 4, 2009
I’m really sorry – I stole the title to this post from Rich at Securosis. It was just so perfect I couldn’t resist. On a side note before I say my piece, will you guys (Secrosis) calm it down for a bit? I can only read so many good posts a day (I have to share my time with other feeds don’t you know), but most certainly stop mentioning stuff that I want to write about myself as that just takes even more time. Cut it out damn it – don’t you have some sort of company to run
Anyway, normal service resuming.
When I saw the challenge – break into some companies web-based email system – I pretty much knew it would all end in tears. The idea behind this company and their “security” (the challenge was to break into the CEO’s email account, and they provided the username and password “to make things easier”) is that it uses “two-factor” authentication by calling your registered phone number(s) after you authenticate to confirm a code that was sent to you. It’s closer to side-channel authentication than two-factor, but I’m really splitting hairs here.
Anyway, the thing that we’ve known for a long time is that even with two-factor authentication, there’s still some really effective attacks, one of which looking at an article reporting the end of the contest and some of the hack technique was clearly used – the good old Trojan attack (via XSS it seems – I would class XSS as a Trojan rather than MITM, but that’s me).
When two-factor authentication is in use, why bother trying to break/crack/defeat the authentication – it’s much easier to wait for the user to authenticate (do all the hard work) and then take over from there. And that’s probably the attack pattern used (and what I would try myself). If, as the article suggests, StrongWebmail was susceptible to XSS, then all you have to do is get some javascript (or other script/applet/etc) up onto their server, entice the user to that page (or email message), and let the script pull cookies/authentication tokens. Once you have them, replay them to the app (substituting them for your original ones), and you’re in and able to masquerade as the target user.
There’s a few things that are a little concerning here though.
First, that a “secure” webmail provider is susceptible to XSS is unforgivable – it’s just such an obvious attack mechanism and should be easily mitigated (well, not easily – there’s lots of places to “hide” script in HTML, but there’s certainly ways to protect against it). Not everyone has NoScript (although they should), but even if they did I very much doubt it would have helped. See, if the user had NoScript, they would have likely had the site trusted (they would have been there before, and as it’s not an “unknown” so would have allowed scripts to run as to probably make the site function correctly). When the XSS code tries to grab the session cookie, NoScript could have got in the way and stopped it from being POST’ed off site, but it could quite as easily been a GET or even better just CSRF’ed an email back to yourself and voila! no “cross-site” and practically all detection techniques would have missed this.
Secondly, if this was the case (and I’m by no means sure about this, but looking at the site in Paros it seems to correct), having session cookies set to HTTPOnly may not have been a complete mitigation, but may have saved them.
In conclusion, what was clearly a marketing stunt backfired badly. They deserve to get their ass handed to them because a) having the community do your pentest work for you is kinda shady, especially for marketing purposes and b) this is such and obvious attack it should have come up in a threat model and have been very strongly validated that it had been mitigated against.
From the CEO of StrongWebMail:
I think if anything this contest will bring attention [that] the major mail providers … really need to take additional steps to secure their email." We all have sensitive info in our inboxes– how secure are you?
Answer: Not very.
EDIT: In the comments of the PCWorld article, it looks like someone else was onto a different strategy by discovering the “two-factor” phone number (via brute force) and spoofing it – a technique that was also likely to work.
Posted in Uncategorized 1 Comment »
June 4, 2009
Well, certainly looks like the Information Security Tools Team have been busy A post by Mark Curphey lists out all the things they have been working on and planning to release later in the year.
Risk Tracker, CAT.NET, Anti-XSS, Threat Modeling Tool, which are all public (and even open source!), and some projects that are internal to MSFT that should make life easier for them.
I certainly look forward to seeing Risk Tracker as I have some ideas in that space myself, as well as CAT.NET (needs improvement in scalability) and Anti-XSS (needs to be less aggressive in some contexts, although also like that SQLi vuln discovery is going to be added).
Nice to see that team has some good work coming out. I met with Mark a week or so when he came up to Seattle looking for a place to settle and it’s clear that he’s really enjoying this role and the creative outlet. Here’s to more of the above I say
Posted in Misc, Security No Comments »
June 3, 2009
I don’t think all that many people consider this when working as an external security auditor/tester/consultant, but something that worries me and sometimes keeps me up at night is knowing that you’ve “done enough” and “looked at and tested the right things, fully” on a particular engagement – especially when they are time-boxed (like most engagements are).
If you are working for a product company and testing your own software and “miss” something, then that’s ok – it’s your own (well, your companys) ass, and hopefully there’s enough controls on the process that someone, somewhere, will catch the most glaringly obvious issues. You fix it, absorb the loss (if any), and make sure you don’t do it again. When you are being paid to provide that service externally and also companies are relying on you to ensure security (another issue all-together – simply passing on that responsibility is madness IMO) you have to get it right.
I’m surprised it’s taken this long, but a security (PCI) auditor is being sued for giving the thumbs-up to a company that turned out to be (very) vulnerable.
Now, there’s a lot of squirming PR from the PCI council that every company that was breached and just so happened to have compliance were in-face not in compliance at the time of the breach. However, what, if to really make it simple, I tested a site and later it was hacked through some SQLi and the client said that they hadn’t update the code or anything so I should have found that vuln. Obviously, all services consultancies have some legalize in their statements of work that cover them for this (if not, there’s a huge hole waiting for you to fall into), as it’s impossible to “prove” anything is “secure”, but what protects that from happening.
At the moment, I think the only things we have are methodologies/checklists (so we know what was looked at and have a “minimum level of inspection”), some “best practices” (that most of the industry seems to agree on, so we should be looking/testing/advising on them), the professionalism of the people doing the work (goes without question), and reputation (which you don’t want to lose – either individually or as a company as your ability to get future employment/work/contract will certainly suffer).
Are there things that we can do to assure that the assurers (auditors, security consultancies) are doing their job right? Do we have the same worries with accountants, CPA’s, and people that help you with your taxes?
Rich at Securosis (when those guys post, it’s so insightful it often triggers my own thoughts and a post – it’s been quiet for me from them for a while, but they are back on all cylinders now ) has posted some of his thoughts up on how to make the PCI audit process better, but I think looking at the accounting professionals might be a way to go. After all, aren’t they doing a similar job as we are doing (approving the state of a company and that there’s no “lying” going on), and they have just as much “wiggle-room/fuzziness” (although numbers are numbers, and much easier to quantify and prove than software and computer systems).
I think we’re going to have to go that way at some point, and perhaps more and more security auditors will get sued in the process. Privately I’ve said quite a few times that the only two things that might shake the security industry on it’s head both being with ‘L’ – Legislation or Litigation – and now we are seeing both.
Posted in Uncategorized No Comments »
June 2, 2009
Great post by Rich as Securosis of where he sees the state of web application and data security at the moment (based on customer contacts).
The first thing I really like about this post is the introduction where Rich outlines the inherent biases he faces as an analyst, and we all face in one way or the other in our industry. We have our own “thoughts” on what is going on our there, and what should be going on, but it’s really difficult to get over our own biases and see what is really happening and the thoughts of the people that matter (our clients). Even talking directly to customers you get skewed in a particular direction, so it’s important to take a wide view, aggregate a lot of data, and try an find the big picture no matter how ugly it might look (and be against your own thoughts/biases).
The main content of the post is going though the how/when/why of clients using web application and data security. I don’t disagree with much of what Rich has written – why should I as it’s come from clients/customers/people in the field – but I certainly have my own insights that I would like to share.
When it comes to web application and data security, if there isn’t a compliance requirement, there isn’t budget
Foundstone certainly has clients that are like that, but looking out our project sheet, I think it’s probably less than 50% of our work that’s obviously tied to compliance. That’s not to say that perhaps the client has their own motivation/reason for getting us to review a webapp, do a pen test, etc, but there’s a lot of projects on our books that aren’t simply PCI/HIPPA related.
I would suggest the reason for this is that we’re (Foundstone) aren’t known for simply PCI but more of the “higher-end” work. There’s a lot of “compliance” in our work in that company X tells company Y that they have to have Foundstone look at their stuff before there’s a deal, but for PCI (and the limited scope it has) there’s cheaper options out there.
PCI is the single biggest compliance driver for web application and data security
In the wider world, I have to agree. I certainly don’t like it, as most companies exposure to security via PCI simply means network vulnerability scanning and unauthenticated SQL/XSS testing – we all know that’s not even scratching the surface. I guess the sliver lining, if you really squint, is that at least there’s something making companies look at network/app security, and any long journey starts with the first step. I believe though that companies are “self-leveling” in that they will always do what in their best interests in keeping going as a company and protecting their business – if security was a big deal (their customers demanded it) and there’s a compelling business reason behind it (not just mandated compliance), every company would be doing it, or at least what works for them. Darwinian survival really – let the customers and companies choose what’s important for them, but that presupposes that they know what they want/need (MAC vs PC adverts for example).
The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client
and…
WAFs are a quicker hit for PCI compliance
and…
Most WAF deployments are out of band, and false positives are a major problem for default deployments
All add up to a really depressing view for me. First, the pros and cons of WAFs have been trashed out loads of times, so I’m not going to go into that again. However, we know that they are not going to find/stop everything (or even a reasonable %age it sounds like from the current state-of-the-art), and the fact that they on an equal footing with security code tools (which being closer to the logic have a much better chance of finding/fixing many more issues than a black-box system) is just wrong IMO.
No surprise that they are being used in PCI compliance though – they are specifically called out as a mitigating control, so an easy choice to make, and are cheep enough to get in lieu of a “real” review, either by a pen-test, code review, or automated scan for that matter. Also they are a box and something “physical” that people see they are buying for their money. I’m no accountant, but CAPEX purchases are probably from a different budget and easier to justify (we’ve got something for our money rather than just someone’s time and a pretty report).
The last part though is the most depressing. Even though WAFs are being used for compliance – more WAFs out there, and a preference to WAFs over security in the code – they are being used out-of-band and suffering from high false-positive rates. Being out-of-band pretty much means that if they did spot something (forgetting the false-positives at the moment), they can’t do anything about it (directly at least). If this isn’t shutting the stable door after the horse has already bolted, I’m not sure what is.
Finally, Andre has an interesting point in the comments (although I can’t track it back on one of the main points, so I’m not certain what he was addressing)
The theory that the fault is on the vendors’ ability to set expectations is interesting. However, I think the problem is not that the tools aren’t available and easy to configure, it’s that there are no (ZERO!) people available to run the tools, or that know how to install (let alone run) the tools
My belief is that we’re suffering at the moment that most of the security tools out there are “engineers tools” and not for “general use”. If you look at most code review or automated scanner tools, to get the most out of them they need quite in-depth configuration and when you get the results often a domain-level expert to interpret them and weed out the false positives and “non issues”. This makes the experts more efficient, but doesn’t bring the expert-knowledge to the masses (which is what these tools are supposed to do).
The web came to the masses because tools made it easier to create pages (how many people now write HTML directly – I know some of you, myself included, will say “I do!”, but it’s a small population and you really should be spending time on more productive things) and easy to create webapps (PHP and ASP.NET especially really make it simple, not to mention the number of free apps/code there is available ready to download and just use without question). Until security tools catch up and become that simple, allowing the people writing/developing/deploying these apps to assess the security without having to be an expert with two hats, there’s always going to be a deficiency.
And I guess that’s our problem – we’re running with scissors too fast for our own good. We’ve not fallen over yet (as an industry – we know companies/people who have but it’s not going to happen to us), and perhaps never will (and if we do, the scissors may miss us or only cause a small cut), but there’s certainly that danger and we should be doing something about it rather than just standing by with the band-aids.
Mom, I’ve just hurt myself!
Posted in Industry, Security 4 Comments »
