Stuart King's Security and Risk Management Blog

I took a call from a vendor inviting me to test the latest version of some web product vulnerability testing software. I've recently been quite outspoken in my dislike for automated testing tools (see here and here) however, I'm prepared to keep an open mind and it would certainly make me happy to be able to report back that things have improved. I'll let you know the outcomes.

I want to take the opportunity to pay tribute to the work of the Open Web Application Security Project - OWASP. This project has now grown into an incredible wealth of online resources with a single minded focus on improving web product security. The OWASP Guide to Building Secure Web Applications should be considered essential reading for developers and if you are not familiar with this document to become so. One of the key messages that should be apparent from reading this guide is that secure products result from having security focused processes in place throughout the development lifecycle. It's beginning to sound like a cliche but it's a message that I can't repeat enough.

More evidence presented itself today in support of my message that there is a demonstrable correlation between the security status of web products where development follows a formal process and those where development is ad hoc and "messy". Last week I read a report from Gartner entitled "Application Developers Should Assume Responsibility for Application Security" (by Joseph Feiman, 16 November 2006) that suggests that application developers themselves should shoulder the blame for poor security. Now, while I agree in principle that skilled developers should take the blame if the quality of their work is shoddy, the fact remains that if the same developers are trying to produce a product where the design has been mapped out on the equivalent of the back of a napkin then any expectation that security requirements are going to be met are ill conceived.

Passwords are on my mind today. First, I'm putting together some product security requirements so passwords are a consideration. Second, I was reading this article on BBC news regarding a report published by the United Nations stating that we are heading for a "password explosion." Third, I received an email from RSA that exclaims "Nothing beats the security provided by a complex password."

What is a sensible password policy for a web product? The correct answer, in my opinion, is a policy that provides sufficient protection of the assets that the password provides access to. Sometimes a password alone is not enough and we might want to consider some form of two-factor authentication (2FA). The problems are many: 2FA is often cumbersome to use and expensive to adminster - requiring customers to learn how to manage their tokens or certificates or whatever other incovenience you plan to post to them, and the business end to staff a full-time helpdesk to assist said customers when their token breaks, or gets lost, or doesn't arrive in the post. Conversely passwords alone, regardless of strength, can be guessed - and face it, I reckon most consumers do not use strong passwords anyway - or worse stolen using keyloggers, spyware, or the various other nasty things that end up on Aunt Mabel's home computer. So RSA's assertion that "nothing beats a complex password" is false - many things beat it including, as those good folk at InfoSec discovered, the offer of a bar of chocolate..

One of the many items I need to deal with is security relating to products being developed off-shore. The expectations of the businesses concerned is that the quality of the work being delivered will be as good as, or better, than work produced in-house.

Sometimes however, the delivered product might be functionally correct but the security leaves a lot to be desired. If it's a key product in your portfolio then that might mean one whole lot of risk that you could do without.

David Lacy mentions in his latest blog that our ability to safeguard data depends upon "sensible application of well-established security technologies." I am in complete agreement and this remark also relates to our efforts to maintain regulatory compliance: as I discussed in my blog yesterday.

At the present time I'm working on a method of categorising web products according to their risk profile: the profile is based upon strategic importance, revenue and, of course, the regulatory aspects. By doing this work, we can ensure that a security policy is applied that relates to the risk posed by the product. Of course, just having a policy doesn't provide assurance. That assurance comes through having good development processes throughout the life-cycle, and having thorough risk assessment, review, and risk mitigation processes. It's all part of having a sound Risk Management Plan (RMP). The RMP is the foundation of my work and over the next year I'll be providing some insight into how successful or otherwise this is.

A new VISA incentive program for payment providers (i.e. "acquiring financial institutions") caught my interest. You can read an article about it here. The essential detail is that for every merchant out of compliance with the PCI DSS a fine of between US$5000 and US$25000 will be levied onto the acquirer. Conversely, incentives will be paid out for validation of PCI compliance.

I'm all for PCI compliance - it's really a good set of common sense basic security measures that we should all be implementing in the best interests of protecting customer critical data. And while I'm critical of the way that some of the guidance and standards are put together, the threat of financial penalties can sometimes be a good kick up the rear-end in motivation to put new programs in place.

However, I'm not enthusiastic about an incentive payment scheme - I believe that such schemes have the potential to undermine the standard by turning it into an exercise in achieving the pass mark rather than a serious effort to protect data. For instance, item 1.1.8 of the standard is for a "quarterly review of firewall and router rulesets." The associated audit procedures directs auditors to "verify that the rule sets are reviewed each quarter." Such a review of rulesets is certainly an important process to have in place and some might argue that quarterly is not often enough however, how should an auditor verify this? A signature in a log book would probably suffice as evidence but it does not prove that a process is being followed. There are other areas too that concern me, particularly in section 6 on software development and the means of verifying that systems are not vulnerable to various mentioned vulnerabilities such as cross-site scripting and unvalidated input. Now, I have personally seen examples of systems that have been tested by authorised PCI auditors using application scanning tools and been given a clean bill of health only for it later to be found that they contained discoverable flaws that could have resulted in exactly the sort of incident the PCI standard is supposed to be preventing. And even if an auditor does successfully and accurately give an application a clean bill of health then the very next change request could undermine all the efforts.

Security should be adding value for customers - they come back because they know that their data and payment information is secure with you. VISA have their hearts in the right place so instead of incentives on the acquirers, how about a "VISA certified payment provider" stamp on products and some truely verifiable audit procedures? Just a thought!

The issue with the Hamley's website mis-pricing goods (see Computer Weekly 19 Dec) is the sort of embarrassing, costly, and totally avoidable sort of glitch that can be easily prevented through basic common sense processes. Now, we can only guess the underlying cause of the problem and without more information from Hamley's it's open to speculation. But I'll guess that it was process behind one or other of the following:

- a change was implemented without being properly tested
- some new code was written that contained an error (malicious or accidental)

The result has been: public loss of face, financial loss, and operational costs to fix the underlying problem. Not a nice Christmas present for them, and a reminder to the rest of us that stories such as this continue to make the news and cost money (and it also says a lot about those people who took advantage of the error).

What should Hamley's do next? There are many common sense measures that help mitigate the risk of this sort of event occurring. Some or all of the following areas are probably applicable:

- documentation of security requirements and development standards
- security between development and production domains (i.e. we don't want development code ending up on the production servers and we don't want development occuring against the live product)
- security of back-end databases
- test plans and testing
- vulnerability testing
- change control
- use of encryption
- management of outsourced development

In the past when I've encountered similar problems - fortunately before they were discovered by the public - the underlying cause could always be mitigated through a combination of controls in the list above.

It would be interesting for some-one from the Hamley's team to comment so that we can all learn from the experience. Now, what are the chances of that?

I hope everyone had/is having a good holiday. My only mishap has been to unwittingly deliver alcohol laced chocolates to my teetotal future inlaws. Fortunately it was taken in good humour and while I'm not sure if my "wash them down with a good Shiraz" jibe was particularly well received I think that the general good mood of the season saw me through!

Getting back on track and onto a subject I find myself thinking of frequently: that being of what motivates an attack on a particular web site? Here are my answers to that question:

1. It's blindingly easy to attack. I encountered a couple of successful product defacements this past year that were the result of the vulnerability being found using one of the many Google-hack attack searches. If you are making it that easy then it's a fair bet you'll receive some unwelcome attention at some point in time, and find your product the subject of one of the many hackers bulleting boards where the exploit will be published for the rest of the world to see.

2. It's worth it for the attacker. If the potential Return on Attack (RoA) for the hacker makes for a worthwhile investment of time and energy then you will be attacked. RoA equates to the gain for a successful attack against the security measures in place. This interesting paper presented at the forth workshop of information security economics (WEIS05) contains detail on the subject: http://infosecon.net/workshop/pdf/23.pdf.

Are we actually getting any better at preventing either of the above? My opinion is that we are. I encounter far more awareness of source-code related issues that would lead to exploitable web products amongst development teams than I did a couple of years ago. That does not mean that web sites are necessarily fully secure (in the same way that a locked door can often still be picked open by an expert), but it does mean that vulnerabilities become harder to find and in consequence take more time and effort for a hacker. And as we also know, trying to hack a website causes a good deal of detectable noise as the hacker needs to use a wider variety of tools to look for the way in. In consequence, as hackers detest being caught, they are likely to move onto an easier target and leave yours alone. Well, that's the theory!

Something else to always keep in mind as well is that a specific customer account might be attacked as a result of the customer's own computer being compromised and his credentials captured. Does this count as a hack? What about if admin-level credentials are captured and used and thus potentially giving access to many accounts? It's certainly an attack but it's not hacking - it may even be more opprtune than planned so far as the perpetrator is concerned. I suppose that Phishing also falls into this category. Depending on the type of web product in question you might need to rely upon fraudulent use controls and/or raising awareness of such issues with customers, and perhaps even some other authentication form-factor.

The point I'm trying to make is that I believe if we make it difficult for an attacker then the web site is less likely to be subjected to attack. That is very easy to say and not always so easy to achieve but there are many simple ways to reduce the attack surface. Over the course of January I'm going to talk about the various controls that I implement to mitigate risk. I've also got another risk workshop to run later on in the month - this time over in America, so I'll be able to comment on the different perspectives of UK and USA based audiences.

This is my last entry of 2006. I hope you are finding this blog information and useful. I deal with information risk issues on a daily basis so if you have a particular aspect you're interested in or questions you'd like answered then just ask away.

Stuart

The first question I ask of a web product risk assessment is whether security requirements have been documented. I think it's an important question - there is a definate correlation between the diligence put into security documentation and the resulting risk status of a product - but what always surprises me are the reasons given why they are not, and more worryingly that few people seem to understand what "security requirement" means in this context.

Some excellently reported statistics here relating to web application vulnerability testing performed by Imperva: http://www.imperva.com/application_defense_center/papers/how_safe_is_it.html.

One of the most interesting (and worrying) quotes in the report is:

In contrast, the portion of tests yielding critical vulnerabilities constantly grows over the years to an overwhelming 89% in Year 4

I've been meaning to talk about unit testing software for a while. This is software that can analyse source code on the developers desktop and identify errors and security vulnerabilities before they hit production.

I prefer unit testing to black-box testing and think that it's far better value for money. For a start it encourages software quality because developers get to see the errors while they work, it raises awareness, supports training initiatives, and consequently fewer errors are put into production (where we all know they become more expensive and difficult to fix). It also fits right into the SDLC regardless of methodology, including Agile, and adds value to the compliance due diligence process.

Using unit testing tools throughout the lifecycle does in my opinion mitigate a good deal of product related risk. Couple that with grey box testing and you have a powerful armoury against code related vulnerabilities.

One particular vendor I've spent some time talking to is Fortify Software. I've been very impressed by a number of things: the ease with which their solution fits into just about any development environment, ease of use, and quality of reporting are all excellent. There are other tools as well such as JTest which I've heard good things about from development groups who use it, and FXCop which is an open source analysis tool for .NET developers.

Fortify Software maintain a blog at http://extra.fortifysoftware.com/blog/. It makes for a very interesting read.

What's your websites password policy? 5 characters? 6 characters including upper/lower case and numbers? How did you choose the policy? Did the IT department think it would be a good idea? Is it based on requirements set by Information Security?

This single subject alone fills up more of my inbox than any other. Here's the situation. We have a policy that is based on the risk profile of a web product (because as an organisation we have hundreds of web products varying from sites such as LexisNexis to Variety and TotalJobs. No single black and white policy alone can cater for the huge variation in risk that we have between different web products, and even where we can categorise products under same profile there can still be difficulty in implementing a policy. For instance: what should you do if the people making use of the product are children?

The issue has come up again because we've reviewed one particular product and noted that the implementation of passwords is less than what I would deem sufficient. Here is a snippet from my response:

...shouldn’t focus on credential strength but instead on the data that is being accessed. So, for instance, if weak credentials are being used as a matter of customer requirements then the accounts in question MUST not – business requirements or not – have access to confidential data.

Of course, this conversation can easily lead onto other subjects such as making use of other form factors for authentication and I wish that this was something we had a definitive, cheap, easy to use, easy to manage, secure, standard for. As we all know too well, in the world of security trade offs you can have cheap and secure but it will be difficult to use or you can have easy to use and secure but it will be too complex!

What's your feedback and thoughts on this subject?

What exactly does "compliance" mean? If I'm reviewing a product and conclude that it is compliant against some particular policy or regulation then what that really means is that it is compliant at that particular moment in time. This is a point well made on the PCI blog and it's something that businesses should reflect on regardless of whether they are aiming for compliance with regulation or simply wanting to comply with an internal policy. The reason, obviously I hope, is that web products in particular present a moving target. A component deemed secure today might be completely insecure tomorrow when the next change is implemented .

It's therefore important that change control includes processes for ensuring continual compliance. Changes should be reviewed for security impact, and their risk assessed. It sounds easy doesn't it? But that's assuming that there are suitably security-aware people available and also that the potential impact of a change can really be known. For instance, a change request to open a new port on a firewall can be easily assessed, however, a request to deploy a new customer-facing enhancement to a web product needs a diffierent approach. Having security baked into the SDLC is an obvious good place to begin however, playing devil's advocat here, let's say it's a change that needs to be implemented fast to resolve an earlier customer-facing (non-security) issue. There is going to be a good deal of pressure to deploy: the business needs to maximise revenue and get the product working fast, the development group is going to be under maximum pressure to deliver fast and the developer will be focusing on the functionaility rather than the security. Can a compliant product still be delivered under those circumstances?

The answer, in my opinion, is probably no. The most likely result will be after-the-event bug fixing and a period of non-compliance. It's an expensive way to do things and while we all know it's cheaper to address problems prior to deployment the real-world is often not as we would really like it to be.

So, faced with a need to be compliant on the one hand but a star product requiring a quick but complex change on the other what can we do to ensure we don't attract the ire of the auditors? PCI clause 6.6 might provide some of the solution. Namely "installing an application layer firewall in front of application." Yes, I know that I've previously stomped on this clause and bemoaned the fact that it's not problem solving from a development perspective but from a business perspective it's a different matter because while the bugs still sit on the server, at least the device is protecting against them being exploited.

It's not a perfect solution and I'd prefer to see more review and testing during the life-cycle but as I stated earlier, the reality is frequently less than perfect and our role at the end of the day is to adequately mitigate risk. In my mind that means ensuring that the business can still function, protects assets, and meets it's security and compliance obligations in the easiest, most cost-effective manner.

So, going back to change control, which is where we came in for this blog, we need to work on improving processes to ensure that security impacts are reviewed but we also need to be aware that this cannot always be assured. When that is the case there are alternative solutions that help us maintain compliance. Make sense?

One last word, and sticking on a PCI theme I wonder if TJ Maxx - the latest company to suffer a breach of credit card data were PCI compliant. There's a clause on the TJ Maxx web site privacy policy which states: "Unfortunately, no collection or transmission of information over the Internet can be guaranteed to be 100% secure, and therefore, we cannot ensure or warrant the security of any such information." That, in my opinion, is a crass clause that has no regard for their customers. Instead of making such blunt and utterly pointless statements surely it would be better to state that they are doing all they can to mitigate risk. However, current events show that they obviously were not and I wonder how their own change control measures up. Anyway, another example of a business making the headlines for the wrong reasons and it should serve as a reminder that compromises are still very much a danger if we leave the door open. Amen!

Few will argue that vulnerability testing is not an important part of the online product lifecycle but I was caught slightly unawares by this question in a recent meeting: if we test a product, and identify vulnerabilities how do we get the resources and budget to resolve the issues within an already tight project schedule where customer focused features are a priority and margins are tight?

Fixing security is unlikely to take priority over new features unless a very strong case can be made for doing so. So, it begs the question, when is the best time to perform testing and what should you do with the results?

If the development cycle is complete and the product is due to go into production then there can be little expectation that security issues are going to be quickly resolved on the back of a vulnerability test unless they are show-stoppers (i.e. high risk of compromised regulatory data). It's clearly a bad time to be doing this type of testing. Conversely testing further back in the lifecycle is not necessarily going to paint an accurate picture of how the product will look once it's in production - at those stages of the process then unit testing tools are a good solution as discussed in one of my previous postings. Testing the product in it's production environment will provide the best report from a pure black-box perspective but that still leaves the question of how best to address the report and deal with issues.

Now, the whole arguement might sound rather academic - in other words, you're thinking: problems have been found and they need to be resolved. But consider that up against tight schedules and tight budgets. If you can have either 10 days worth of development to resolve security issues against 10 days of development to implement new revenue generating features then which one would you choose? So once again the discussion comes down to assessing, communication of and acceptance of risk. Resolution might need to wait but in the meanwhile the least that can be done is ensuring that potential bad-outcomes are known and that risks are "owned". It's not a problem I've yet had to deal with here, however it's certainly worthy of discussion the next time you begin a round of vulnerability tests.

OWASP, for those of you who don't know, stands for Open Web Application Security Project. It's a long established open source resource committed to improving web product security. I've long been enthusiastic about the project and some of the excellently produced tools and documentation that have come out of it. I recommend that anyone involved in any aspect of web product development takes a look.It's right here at www.owasp.org.

The project has just release a new version of it's guide to the top ten web application vulnerabilities. It's a very informative, useful, and above all, relevant document. I can guarantee that every vulnerability test that you perform will report back one or more of the issues highlighted in this work. You can download the document from the OWASP site.

Mark Curphey, one of the originators of OWASP has his own blog at securitybuddha.com. I also recommend this as a good stop-off when you have a few minutes to spare - obviously after reading this blog first.

Has PayPal's introduction of a security token improved security (read the news item) and is this a lead to be following?

Personally I believe that it is a positive move in the right direction. There's no doubt that two-factor authentication mitigates some risk of an account compromise. There are those who will highlight the deficiencies of this approach - for instance Bruce Schneier is rather scathing of 2FA in a blog entry he made a while ago where he makes the comment that "two-factor authentication doesn't solve anything".

It depends what problem you are trying to solve. If the problem is a perception that the business is not doing enough to prevent accounts being compromised then from a consumer perspective issuing tokens is a solution. And as mentioned on the Washington Post SecurityFix blog "other companies that have widely deployed similar security keys have dramatically cut down on fraud" and that one business has "never had an account takeover connected to a customer using one of its security keys."

The main disadvantages of 2FA are firstly the administrative overhead of managing the tokens which are easy to lose and sometimes break (as I recently discovered), and secondly if I were a PayPal customer, traded stock using eTrade and banked with Citibank then I would currently have four different tokens in my pocket (including the one I use for my corporate network). That is ridiculous and not only because of the effect it will have on my trouser pockets. I don't want to carry all those tokens and the one I need will always be the one that I've left in my other suit that is at the cleaners.

A much better solution, in my opinion, is described here on the Digital Identity Forum. In this blog entry, Dave Birch states

I would much prefer the "white token" solution, as we used to discuss in the early days of multi-application smart cards, where the customer takes responsibility for stronger authentication and goes and buys (let says) an OATH-compliant USB key which they then register with their bank, their retailers, their MMORGS, their social networks and so forth.

2FA is a first step, but it is not the foundation of sustainable digital identity in this form. We have to move to end-to-end security. PKI in smart cards, for example

I recommend that all of you involved in product development take note that OWASP have released v2 of the application testing guide. It's an excellent, detailed, easy to follow reference.

David Lacey draws attention to the Cyber Security KTN Secure Software Special Interest Group on his blog. I'm totally behind any initiative that sets out to improve software security and I hope that this new group will also make reference to existing established and reputable resources such as the OWASP.

The only point I want to make is that the first deliverable of this new group is going to be a white paper. Now, call me an old cynic but I'm not sure how useful another white paper on where we are all going wrong is going to be. We can all refer to numerous references that describe what the problems are and what needs to be done to produce secure software and I'm sure that the Secure Software Development SIG will find an interesting way to write up the messages but, come on, we don't really need another white paper.

Maybe the place to start is by reviewing the tools being used for development and making a point at how easy they have made it to produce complex products without there needing to be many of the old-school development skills in place. To give you an example of what I mean I was recently chatting with a senior software architect who works within my own organisation: years ago he worked on Russian satillite navigation systems and was describing to me how his team would be required to write working code without having either a compiler or a system to test the code on! He went on to discuss his incredularity at the developers he now works with who need to compile their code every few lines to check that it works. It's like modern aircraft: you can sit in the cockpit and have the plane fly without needing to understand anything about aerodynamics or being a pilot: there's a danger that the skills required to remain in control if the auto-pilot fails are being lost.

So, one of the causes of the problems we have with insecure software is the tools that have made it easy to do a good job badly. The products we are producing are increasingly complex but how many developers making them have the deep understanding of architecture and platforms and how information behaves when it's being passed across the network. I hear developers talking about protocols but then they can't explain how those protocols work. They talk about encryption but often don't even know what algorithms they themselvs have implemented, and sometimes not even how.

So, back to the Cyber Security KTN Secure Software Special Interest Group: don't spend too long on another white paper - what would be good to see is some plan of action (perhaps working with the vendors of the common development platforms?) that wil go some way towards tackling problems at the root.

To round off, there's a good blog from Michael Howard of Microsoft on the subject of secure software here.

OWASP announced in their latest newsletter the completion of a number of projects designed to assist developers write more secure code. For more information go to http://www.owasp.org/index.php/OWASP_Autumn_Of_Code_2006.

I also want to recommend the blog of Diniz Cruz at http://blogs.owasp.org/diniscruz/. There are some excellent, well informed posts on the theme of secure development.

First Direct bank here in the UK have managed to infuriate their online customers by enforcing an en-mass change of authentication credentials. Read all about it here: http://news.bbc.co.uk/1/hi/business/6446919.stm. All credit to them for trying to improve security for their customers, but I wonder how much more secure the new procedures are.

It seems obvious that First Direct are torn between a rock and hard place. They clearly want to improve security and in doing so have increased complexity thus making it more difficult for customers to gain legitimate access to their accounts. While the increased complexity keeps out otherwise authorised customers does it really make things more secure? According to this report from APACS, out of 15million online banking customers it is claimed that less than half "regularly update their anti-virus software, with only 1 in 10 people having anti-spam software installed and about a third having a firewall." Not only does this fly in the face of the advice given by the "Bank Safe Online" campaign and makes you wonder who actually reads the advice (or even knows it's there) , but it also means that until we move to using additional form factors that mitigate key loggers and other insidious spyware then the measures taken by First Direct are ultimately futile because, if the statistics are true, then half their online customers are potentially already compromised.

The banks need to be doing the equivalent of what they do if you walk into a branch and want to withdraw cash in person: they ask for identification that proves as far as possible that you are you: a drivers license or passport. Asking for an unknown individual to enter a series of characters using a keyboard does not give anything near that level of assurance.

My question is: do FirstDirect think they are doing the right thing or do they want to be seen to be giving the impression of doing the right thing to a mostly (as the statistics suggest) ignorant consumer market where "62.5% (nearly two thirds) never change their password and 1 in 5 use the same password for non-banking websites as well as their online bank." (taken from the APACS report).

Quite honestly, being made to enter a few more characters as added security when you're not protecting your PC from spyware in the first place is like leaving your front door open and your wallet on the door mat when you go on holiday and hoping no-one will notice.

An interesting new service being offered by RSA: http://www.rsa.com/press_release.aspx?id=7922.

RSA, The Security Division of EMC (NYSE: EMC), today announced it will launch its new RSA FraudActionSM Anti-Trojan service, designed to help companies secure their organizations, brands and customers from a new generation of crimeware attacks.

While financial institutions are undoubtably the principle targets they are are not the only high profile online properties that get attention and we all need to be aware of the risks.

An interesting new service being offered by RSA: http://www.rsa.com/press_release.aspx?id=7922.

RSA, The Security Division of EMC (NYSE: EMC), today announced it will launch its new RSA FraudActionSM Anti-Trojan service, designed to help companies secure their organizations, brands and customers from a new generation of crimeware attacks.

While financial institutions are undoubtably the principle targets they are are not the only high profile online properties that get attention and we all need to be aware of the risks.

If you had £20k to spend on web product security and could choose between training your team of developers in appropriate secure coding skills or purchasing an application firewall, which would you choose?

Here's my answer - I'd buy the firewall.

Now, there might be a few of you who are surprised at my response and a number of you who disagree. That's great, I don't mind people disagreeing with me because I'd love for you to prove me wrong and help me make a better decision if, indeed, you can argue why I'm making the wrong one.

There are a number of reasons why I'm going to take the device over training and here they are:

1. The firewall buys me risk mitigation that I can measure. It doesn't matter if the product contains security holes (known or unknown) because the device will prevent the vulnerabilities from being exploited.

2. The money spent on training will be wasted. The developers will still write buggy code in their haste to meet deadlines and after six months most of them will have left to either become plumbers or security consultants.

Ok, I'm generalising - and I know plenty of developers who did not become plumbers and one in particular, namely me, who did become a security consultant - and I frequently hear anecdotal evidence relating to the value of training but I reckon we can do a better job without spending the money. For example, take a look at the fantastic opensource resources (IMHO) provided by Foundstone: Hacme Bank, Hacme Books and the rest of their free security training tools (go to Resources - Free Tools). I can think of few reasons why you shouldn't be encouraging your developers to work through the training guides provided with these resources and many reasons why you should. And I take my hat off to Foundstone for continuing to provide and update them.

Application firewalls are not a solution to insecure code, but they are a solution when the problem you are trying to solve is an insecure product. With web products now reaching incredible levels of complexity it doesn't matter how well trained the developers are, you will have bugs, and the likelihood is that some of those bugs could result in a security breach and/or your business falling out of compliance with some legislation or other. In which case if I've got 20 grand to spend on either training or an application firewall, I'm off to the firewall shop.

To close off, this cartoon on the SecurityBuddha blog made me laugh out loud...
http://securitybuddha.com/2007/03/16/cartoon-023-automated-code-scanners/

I was involved in an interesting debate today around the value of documenting a good set of security requirements. The debate was the result of report written where it was stated that deficient security requirements resulted in increased risk. No-one disagreed with the conclusion however, what was asked was something more than hearsay to back up the statement: especially as a number of the security requirements being prescribed are likely to cost time and money to implement.

I can point to a good deal of anecdotal evidence showing insecure products where no requirements have been documented and secure products where they are. But to what degree do requirements need to be documented - and followed - in order to begin having a positive impact on security status? In other words, how much of what we are prescribing really needs to be done and can we prove it?

There is plenty of textbook quotes in support of the value of having well documented requirements. For example in "Building Secure Software" by John Viega and Gary McGraw (ISBN 0-321-42523-5) it's stated (page 34) that "the security engineer should be sure to craft requirements well."

Now, here's where we come up against business level push-back because if I mandate a high level requirement that is subsequently not implemented, and then if I perform a risk assessment where the outcome of not implementing that requirement is "low risk" then should the requirement have been stated in the first place and whose time is being wasted?

There's a fine line here between being seen to be providing quality guidance that development groups will follow and being ring-fenced for saying that the sky's falling down.

Clearly, in my ideal, ultra-secure world, I want a clean path from a to b where requirements are pristinely written and everyone follows them. In the real world, the business wants to deliver to it's customers against a fixed, often limited, timeline and budget, and if we want to tell them to spend more money on security then we'd sure as better be able to back up what we're saying with a crisp arguement and lots of supporting evidence.

There's an excellent and humourous article on OWASP on how to write insecure code. This is essential reading for all developers...

To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

These days, SPI Dynamics claim, amongst other things, that the new version of WebInspect (v7) "is the first and only solution to address the complexity of Web 2.0 and identify vulnerabilities that are undetectable by traditional scanners." Acunetix state their product "has a state of the art vulnerability detection engine which quickly finds vulnerabilities with a low number of false positives. It also locates CRLF injection, Code execution, Directory Traversal, File inclusion and Authentication vulnerabilities."

If the claims are true then we're all saved and we'll never see another vulnerable web product. The problem is in the words "automated scanner." Unfortunately, that is not how a hacker behaves. When I point my scanner at a URL and click scan, the machine will work as programmed and if you're lucky, it will identify some security flaws that you can fix, or report that your application is clean so that you can go running to the boss with the good news. Point a hacker at the same URL and I can guarantee that he (or she, because I'm sure there are lady hackers too) will not behave like a programmed machine. Firstly, there will be the requirements for coffee and pizza. Input both and the output, more often than not, is a lot of mess that no scanner is likely to find. If you're lucky, the cleanup will be the result of a test that you solicted. If you're unlucky it will be after you've discovered that the hacker has compromised your database.

If, after reading this, you still want to rely on the output of an automated scanner, then don't sign the purchase order before reading this report from Virtual Forge. The report, rather dissapointingly, does not name the scanners under test but the results are conclusive

The best scanner found 13 out of 85 vulnerabilities, the worst only 4

Do I think that application scanners have any place at all? The answer is yes IF you have some skilled in-house resources with the ability to use the generated reports as a guide and not as a statement of fact. Conversely, the danger if you don't is that you'll generate, for example, a PCI report that states you're compliant when you're not, or just as bad, generates a vulnerability report that has you running around screaming that the sky's falling down when it isn't.

Before I close down for the night, I promised my good friend Hassan that I would mention it was with his encouragement that I recommenced writing this blog. So, thank you Hassan. And do you know what? I'm glad I did...

I make no secret of the fact that my first interest in security is around the online product side of things. So easy to get completely wrong and the same old lessons are continually being relearnt. I used to take a smug satisfaction in showing developers how easy it could be to find the flaws in their code. Laterly, it's frustration because I still see the same errors being made and I still find a reluctance within development groups to make use of some of the excellent resources there are online that serve to educate and help solve the problems.

Here are the best ones:

OWASP at www.owasp.org. Still the number one product security resource. Continually updated and loads of useful projects in progress.

Foundstone's free tools and resources at http://www.foundstone.com/us/resources-free-tools.asp. The old HackMe Bank application is joined by variety of others that enable developers to learn about security across a variety of platforms. Essential resources and free!

Microsoft Application Security Developer Center at http://msdn2.microsoft.com/en-gb/security/default.aspx. If you're developing using Microsoft toolsets and not making use of this resource then you are a fool goddammit! I'm also a big fan of the Threat Modelling tool (see my blog from earlier in the year). Yes, it's time consuming to get it right but then so is fixing security holes.

Anyway, even the best of us can make daft code errors...some years ago whilst working within a large web development team I noticed that somebody had left in some debug code that displayed the complete database connection string, including password, on the web page. Worse still, the code had already been deployed to the production web server. I initiated an investigation and performed an audit of the Source Safe records only to find that the offending debug code was, in fact, mine....

I was chatting to a techie from SalesForce.com a couple of evenings ago and questioning him about the processes in place for ensuring the security of applications posted on their AppExchange. It's a pretty comprehensive process and one that might be useful to adapt for your own development work. The questionnaires used in the assessment process are available online here and well worth a look.

The associated spreadsheets are comprehensive enough although I will level a couple of criticisms: they look sloppy in the way they are presented and are not easy to follow. I'd also apply weightings to the various sections and use the questions responses to calculate a risk score based on the risk profile of the application in question (similar to the process used within my own organisation). For instance, for some applications, some questions might be more necessary to answer yes to than others. Because the assessment is going to potentially be used against thousands of applications, some benchmarking and scoring system could be useful - both to SFDC and to the developer.

Perhaps then SFDC could keep a league table based on assessment scores. Just a thought...

Thanks to James Penfold from SalesForce.com who has made me aware that there is an updated program relating to the AppExchange certification process I mentioned a couple of blogs ago. This can be accessed online here: http://wiki.apexdevnet.com/index.php/Certification_Listing_Review . I'm also informed that, contrary to what I wrote, there is a scoring system in use internally by SFDC.