There's more and more incidents in the public domain where a security issue has seriously tarnished an organisations brand identity. Worst still is the simple fact that it could have been avoided in most cases.
Some of the most notable in the last 12 months that I remember were when the MySQL website was taken down using a SQL Injection attack vector, and the more recent PHP exploit on militarysingles.com (link takes you to the Imperva report PDF).
"Why are these such a big deal?", you may ask. Well from a distant perspective the former details an organisation (now owned by Oracle) who specialise in database systems. Even though the worst effect for customers was to have their details taken and published, it wasn't actually a vulnerability in their product. It was down to the website team not approaching the project with defensive coding in mind.
It was a political coup over brand identity.
The latter example (militarysingles.com) is both an exploit of a vulnerability as well as a lack of defensive coding for the particular scenario in question. The problem there is that gaining access to customer data in this instance means potentially sensitive information on military personal across the globe.
It's almost as if there's a lack of general awareness about key issues, and I can only draw from first-hand experience of contact with developers. For instance, I've done over 200 telephone and face-to-face interviews in the last few years for what is effectively around 30 or 40 actual roles. It's hard for me turning down applications from good developers when we find them but we're after a very specific skill set and way of thinking - especially with regards to security issues or vulnerabilities.
Hypothetical interview question: Array processing and sorting, with the ideal being some sort of pseudo-code or algorithm that details specific mechanisms or sorting. The answers to this vary but most people seem to respond with LINQ extension methods that do it all for you, without any real explanation. As an interviewer it's best to give as much chance as possible so you take the toys away and ask the question again (this time, only using .NET 2.0, or just C if it's familiar).
It's not really about the answer so much as how you come up with a solution but it's also surprising how few people think at this level. It's like all the available frameworks have dumbed-down general technical knowledge. Yes, they're useful in given situations and, yes, they make developers lives easier...But easier doesn't mean better*.
We used to ask a set of questions almost made up on the spot, but that's evolved to a question list - Some candidates recently made comments about some of them being straight from the interweb so I've added a few more different ones over time.
Some questions relate to defensive coding practises and are quite revealing in terms of the level of awareness of these attack vectors. Very few developers seem to know any more than how to prevent SQL Injection in .NET, and throw in a few answers about SSH, firewalls and DDoS mitigation. The last three are good to be aware of but only the third could be dealt with in any way by some development work - It's usually better to get something like RioRey or BlackLotus on the case.
Even the basics will only get you so far - The classic is hashing stored data. Great, but the other guys have read the same book and can break it. MD5 stopped being effective nearly a decade ago, even SHA-2 will have a shelf life defined only by "the other guys" intelligence. Maybe processing power too. CrackStation has a pretty good article actually explaining not only how but why.
At my current employer we have to take the topic very seriously - We're a global organisation who is a big target for black hats, hacktivists, competitors, money launderers and other such activity; so if there's a security problem it's got to be dealt with there and then. The sources of the majority of attacks are unsurprising, as are the sources of screen-scraping attempts. I supposed psychologically if it's not a physical attack, it's more difficult to easily quantify - which can make it more difficult to justify the additional expense for shoring up the defences to the board of directors in some places.
However, RSA were actually physically broken into and later some of their clients had their systems compromised as an indirect result. [RSA Labs has a pretty good collection of docs + discussions here]
There's always something out there that you don't know about - No system is impregnable when faced with a sufficiently well motivated and financed group of people - but you can do a lot to ward off and discourage the majority of infiltrators.
You / me / an individual can't know everything, that's why having a good team is important but here's a good place to start... OWASP (have a read of the reference area)
*(Comments about knowledge levels are generalisation only, there's a huge number of really good developers and specialists if you're lucky enough to find and hire them)
Some of the most notable in the last 12 months that I remember were when the MySQL website was taken down using a SQL Injection attack vector, and the more recent PHP exploit on militarysingles.com (link takes you to the Imperva report PDF).
"Why are these such a big deal?", you may ask. Well from a distant perspective the former details an organisation (now owned by Oracle) who specialise in database systems. Even though the worst effect for customers was to have their details taken and published, it wasn't actually a vulnerability in their product. It was down to the website team not approaching the project with defensive coding in mind.
It was a political coup over brand identity.
The latter example (militarysingles.com) is both an exploit of a vulnerability as well as a lack of defensive coding for the particular scenario in question. The problem there is that gaining access to customer data in this instance means potentially sensitive information on military personal across the globe.
It's almost as if there's a lack of general awareness about key issues, and I can only draw from first-hand experience of contact with developers. For instance, I've done over 200 telephone and face-to-face interviews in the last few years for what is effectively around 30 or 40 actual roles. It's hard for me turning down applications from good developers when we find them but we're after a very specific skill set and way of thinking - especially with regards to security issues or vulnerabilities.
Hypothetical interview question: Array processing and sorting, with the ideal being some sort of pseudo-code or algorithm that details specific mechanisms or sorting. The answers to this vary but most people seem to respond with LINQ extension methods that do it all for you, without any real explanation. As an interviewer it's best to give as much chance as possible so you take the toys away and ask the question again (this time, only using .NET 2.0, or just C if it's familiar).
It's not really about the answer so much as how you come up with a solution but it's also surprising how few people think at this level. It's like all the available frameworks have dumbed-down general technical knowledge. Yes, they're useful in given situations and, yes, they make developers lives easier...But easier doesn't mean better*.
We used to ask a set of questions almost made up on the spot, but that's evolved to a question list - Some candidates recently made comments about some of them being straight from the interweb so I've added a few more different ones over time.
Some questions relate to defensive coding practises and are quite revealing in terms of the level of awareness of these attack vectors. Very few developers seem to know any more than how to prevent SQL Injection in .NET, and throw in a few answers about SSH, firewalls and DDoS mitigation. The last three are good to be aware of but only the third could be dealt with in any way by some development work - It's usually better to get something like RioRey or BlackLotus on the case.
Even the basics will only get you so far - The classic is hashing stored data. Great, but the other guys have read the same book and can break it. MD5 stopped being effective nearly a decade ago, even SHA-2 will have a shelf life defined only by "the other guys" intelligence. Maybe processing power too. CrackStation has a pretty good article actually explaining not only how but why.
At my current employer we have to take the topic very seriously - We're a global organisation who is a big target for black hats, hacktivists, competitors, money launderers and other such activity; so if there's a security problem it's got to be dealt with there and then. The sources of the majority of attacks are unsurprising, as are the sources of screen-scraping attempts. I supposed psychologically if it's not a physical attack, it's more difficult to easily quantify - which can make it more difficult to justify the additional expense for shoring up the defences to the board of directors in some places.
However, RSA were actually physically broken into and later some of their clients had their systems compromised as an indirect result. [RSA Labs has a pretty good collection of docs + discussions here]
There's always something out there that you don't know about - No system is impregnable when faced with a sufficiently well motivated and financed group of people - but you can do a lot to ward off and discourage the majority of infiltrators.
You / me / an individual can't know everything, that's why having a good team is important but here's a good place to start... OWASP (have a read of the reference area)
*(Comments about knowledge levels are generalisation only, there's a huge number of really good developers and specialists if you're lucky enough to find and hire them)
