Secure me now … or Secure me later

I recently suffered a two alarm fire in the building where I live; a tragic and nasty event that claimed a life, no less. My condo sustained significant water damage, so much so that the premises were in fact rendered unlivable. We had move to a temporary home and were completely uprooted. In the meantime, our condo was gutted and essentially redone. This took quite a bit of back and forth as it inevitably and sadly does in these matters, but thankfully we had insurance like most people, and we had dutifully paid our monthly premiums, so all expenses were covered. And we incurred quite a lot of them.

Well that's fine; these things happen. But what does that have to do with Web Application Security? Let's take a step back and draw a reference line first. In the realm of IT and security, some say you can never have enough. Security is built as multilayer foundation encompassing a protected asset. The multiple layers include operating systems, IP security, transport security, encryption and cryptography, protection against viruses, worms and malware. Then there is infrastructure security with demilitarized zones (and yes we are still talking IT), firewalls, security certificates, intrusion detection, etc. And last, but certainly not least, is the hardware and facility physical security, access control, electrical power backups and the like.

Protected Assets

What do all these concerns, efforts and investments secure? What are these precious assets that require protection? Computer systems. Data. And of course, applications.

Computer systems obviously wouldn't amount to much on their own without data. When new systems are procured, before they are put to good use they are just unused expensive hardware.


Application Security Layers

Application Security Layers

Security is important at different points within the lifecycle of a protected asset. How does the data get into the system? Well, that would be through applications. Once the data is amassed, it can be transferred, mined, sold, and safeguarded, but in a chicken and egg conundrum, data would never come into existence without an application to collect it in the first place.

Hence, the best way, perhaps, to secure a computer from a network perspective is to never have it connected to anything. But this is akin to taking the battery out of your cell phone to make sure no one is listening in on your conversations while your cellphone is sitting on the table turned off, next to you. And in this day and age, who keeps their computers unplugged and unconnected?

The best way, perhaps, to secure a computer from a network perspective is to never have it connected to anything. But this is akin to taking the battery out of your cell phone to make sure no one is listening in on your conversations.

So a vast majority of computers are connected to some network. And all security concerns exist within a pyramid, at the top of which is user access and interface. But that's just another name for applications, isn't it? And that's where all the web applications exist as well. You know, the ones we use to bank and pay bills, buy things online, enter various information on some regular basis...

Your App Has To Know

Once a pyramid is built and established, you want to protect your application. However, there is a little paradox in here. You put in place all these security constraints, checks, measures, but in the end you still have to allow your users to access your application. This means you regularly prevent bogus and ill-bearing requests to your application, you make sure your users go through proper authorization and authentication, each request will cross a rigorous (packet inspecting?) firewall, and your operating systems are patched up with the latest security updates.

And then you let your user in. Through the front door, which could be your application login page; the back door, which could be a file upload; the garage door, which could be a web service the user is invoking on your application; the living room window, which could be some intended user input on the application... in short, you never build a system for any other purpose than, well, to let your user use your application.

But when all is said and done, how does this application, running on a server all alone, fend for itself, when there is no one around? In other words, whom do you want to protect it from? Or better yet, whom do you need to protect it from? The simple answer is: you don't really know. You don't know whether malice is coming from a genuine, properly authenticated (but disgruntled?) user or a compromised credential, from someone who found a crack in your nicely polished front window, or whether it simply is an unfortunate set of accidental circumstances.

Should your application really care? No. It has to stand ground in all these cases equally well and withstand abuse. Not only should it care about the current user, but it also has to know exactly what that user is sending into it. It has to know how to tell good input from bad and malicious ones. It has to recognize when someone is interrogating it as opposed to when a true error happens. It has to know not to reveal any secrets. It has to know to recognize a true threat agent. It has to know what information belongs in its log file and what doesn't. It has to be smart and have enough protection.

Well, how much is enough? As it turns out, it's commensurate with risk. Risk is the criteria that determines what you need to do:

Risk = F(vulnerability, likelihood, assets)

This further begs the question: when are you at risk? And because the vast majority of web applications are at risk just by virtue of having been deployed (if nothing else), then that question more precisely is: how much are you at risk? The math is rather simple: the more value your assets have, be they data or applications, the higher the likelihood that someone will want to steal or compromise them. This is why you need to keep your vulnerability as low as possible. In turn, that is what gets you lower risk. Obviously if you are building a web application that will show local cinema showtimes, then your assets are not that valuable to begin with. Hence lowering vulnerability will come at an expense that isn't really justified, because the likelihood is also very low.

Will the Development Process Change?

But if you have valuable assets that need protecting, how do you do that? How do you minimize vulnerabilities in order to mitigate risk? One of the many solutions to this problem is the adoption a Security Maturity Model. There are quite a few of them, all of which are outside the realm of this article. However, the following guidelines present common measures that can be undertaken to mitigate application risks, regardless of which maturity model you adopt, if any.

You must make changes to your software engineering and development process. Regardless of the methodology you use, every project will have requirements in some form. Either formal documents that articulate business needs for waterfall and RUP approaches, or the client on site perhaps for agile approaches. Seldom are security requirements discussed, though, and this is where the problem starts. These are requirements like any other, and they need to be formalized and articulated.

Are there any assets the business wants or needs to protect? How valuable are they? How will the system be accessed and (ab)used? What does that mean from an application security perspective? Answers to these and many more questions need to become part of the project requirements. Only that way can they actually be implemented, and more importantly, verified. So security concerns need to be brought up with clients and scheduled for. When it comes to the actual engineering, a little education will go a long way, but many developers won't have security concerns in mind, especially when they are not captured by requirements.

The extra work required to produce a far more robust and secure application is not all that big of a burden and addition to the budget. It may require just an extra 10% to get you there. However, like the requirements, the application architecture needs to reflect the security concerns and solutions that address them. The fun can begin once a deployable artifact is produced, or an early application build or prototype, depending on the implementation process and methodology again. And the fun is penetration testing.

The extra work required to produce a far more robust and secure application is not all that big of a burden and addition to the budget. It may require just an extra 10% to get you there.

Web applications get attacked and exploited by a very small percentage of users, but the damage can be overwhelming. This, like many others, is a numbers game. This is why during any testing cycle, whether formal by a dedicated QA group, or informal by the development team and customer, the implementation of solutions that meet security concerns need to be verified. In one of my favorite engineering and organizational considerations, this should also answer the question of 'who does what' in your project team. This again will inevitably be influenced by your development methodology.

The Principal Driver

Ok, so that may have struck a chord but there is a little something missing to bring the message home. The "why". Why would any project and/or application need to do this? And sure enough, there are many applications out there, in production and full use, that have no security considerations projected for them, much less any implementation, but are happily fulfilling their purpose with a varying number of users. So why should more funds be spent to produce a more secure application? To answer that question, let's look at the damage cycle and exploiting any application vulnerability.


Damage cycle

Damage cycle

In the three initial phases of the damage cycle, the vulnerability exists, but no one bothered to either discover it or figure out whether it's exploitable. And even if it were, it's a huge step from an exploitable vulnerability to a fully blown attack. So in these first three phases, the risk is there because the vulnerability is there all along, whereas the damage is negligible. If and when, however, an attack gets mounted, then things get a little more precarious. All of a sudden, your protected assets may become compromised, and this is how damage escalates. This vicious cycle ends with repairs. If your application is complex or large and already in production as it often is, after-fact and after-thought security remediations are going to be tremendously more expensive to implement.

When you get exposed to damage, bad things ensue. Depending on your protected assets, significant damage to the business may be sustained. Should this involve confidential information disclosure, lawsuits and litigation will follow. This cost of missing application security can balloon to astronomical levels. Company reputations get tarnished. The usual companion and aftermath of this outcome is that heads will roll and careers undergo forceful changes. And then, repairs will still need to be made, provided there is anything left worth repairing. So there is really no reason not to promote application security consideration into a forward engineering concern; to schedule for the beginning of the application lifecycle and absorb the relatively little overhead this brings.

Small Premiums

Naturally, I was relieved that my insurance covered all the expenses for the condo remediation. Had it not, I would have been out of pocket a nice fat hefty sum. So I will happily continue to pay my premiums. Application security is really no different. It's a small insurance that buys an extended peace of mind. And the more valuable the assets, the more invested one needs to be in peace of mind.

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us