Skip to main content

Legacy and scale: Why IT still hasn't solved the challenge of website security

This article was originally published on Technology.Info.
As part of our continuing strategy for growth, ITProPortal has joined forces with Technology.Info to help us bring you the very best coverage we possibly can.

Practically every day, another organisation - whether FTSE-listed or startup level - has to publicly admit that its website has been hacked and sensitive data compromised. Whether politically motivated, for financial gain, an ego-stroke, retaliation, or just for the heck of it, any business or website can be victimised.

Critically, many attack techniques aren’t particularly new or sophisticated. From SQL injection to cross-site scripting and so forth, we tend to have seen them all before. We know how to find these vulnerabilities, how to fix them, and yes, we even know how to prevent them. So why do the hacks continue to happen? Why is it so difficult to solve the challenge of website security? The answer: legacy and scale.

A challenged beginning

For most organisations, starting a website security programme doesn’t actually mean starting with a clean slate (or zero code) but having to introduce security into the software development lifecycle (SDLC). In fact, unless you’re a brand new organisation launching its first website, it’s more likely you have dozens, hundreds, and possibly even thousands of websites already. We’re talking millions of lines of code written over years. It’s unlikely you know where all your websites are, what they do, and who is responsible for them, or have any real idea of their security posture. At best, visibility is limited.

So, rather than facing one challenge, most organisations face at least two: securing existing code, and ensuring that new code is written securely

Effectively tackling these problems requires separate approaches and separate strategies. Let’s discuss them in turn:

Securing legacy code

The web as we know it is about 20 years old and, for most of its history, the act of developing websites and web application code has been focused on introducing features and functionality to fuel business growth. For the first 15 years or so, security wasn’t even a consideration. And when it did become a factor, there was little comprehension of what’s needed or how to apply it.

So what do you do with the code that’s already written and, in all probability, vulnerable?

First of all, organisations need a website asset inventory to determine what exists and needs to be protected. This seems obvious, yet rarely happens.

Then, once a clear picture is obtained, you need to hack yourself first to discover what the bad guys know now or will know very soon. Force your websites to endure the exact same battery of attacks the bad guys will levy against them. This can be achieved using solutions, such as vulnerability assessments, and then triaging the results.


While these steps sound simple and straightforward, the difficult task is actually fixing the vulnerable code. Developer time is typically dedicated to creating revenue generating features, so a decision must be made: does the developer continue to focus efforts on introducing features that, if delayed or not released, will costthe company money? Or should the developer shift time and attention to fix issues that might get exploited and potentially costthe company money? The outcomes are potentially the same – the company may lose money – however, the overall impact and financial losses of one over the other could be greater in the long-term.

While it’s a difficult predicament with no long-term magic answer, there are temporary options to consider, such as a virtual patch. Integrating vulnerability findings into a web application firewall offers a bit of breathing room by protecting against exploitation while figuring out how to fix the code.

In parallel, and assuming there’s budget available, a third party could be employed to fix vulnerable code leaving the in-house developers to do their regular day jobs.

The bottom line is this: the code needs to be fixed, whether it’s done in-house or outsourced. Otherwise it’s not a matter of if but when you will be hacked.

Securing new code

Having understood the ramifications of fixing code retroactively, the next generation of applications and websites being developed must be secure from the outset to break this cycle.

This means understanding what the business is trying to accomplish, and the security controls necessary to ensure the functionality of the application stays within the rails. As an example, different controls might include: threat modelling, periodic source code reviews, coding guidelines, developer education, and software testing as new code goes out the door. Bear in mind that every change in the application has the ability to impact the security of the code; therefore, just as code is assessed for quality and functionality, security must also be checked.

Of course, it is rare that new applications are written completely from scratch, as developers will incorporate code from third party vendors and libraries. The security of this borrowed code must also be assured to ensure vulnerabilities don’t already exist.

A further consideration is the need to protect systems from attacks that haven’t been invented yet - which is very difficult, if not impossible. Rather than the 'what if' scenario, developers should design systems and processes that can be iterated fast. That way, when an attack vector is launched, the system can be quickly changed without incurring extensive business downtime or costs.


Measurement is another valuable indicator as, typically, anything measured tends to be improved. Release cycles, vulnerability rates, types of vulnerabilities, and recording the number of bug fixes that have to be completed all help measure the effects of software development lifecycles or security programmes.

Whether its loss of data, malware infection, loss of consumer confidence or even a failure to meet regulatory requirements, the truth is no company can afford the black mark of a website attack. Organisations must solve the challenge of website security if we’re to see a reverse in the upward trend of compromises.

Having sensible people, processes and technology in place provided from the very best you can afford can go along way to safeguarding your company from today's 24/7 hacking onslaught.

Jeremiah Grossman is CTO and founder of WhiteHat Security.