How to protect off-the-shelf web applications?

Question

As an exercise, please consider the following:

If you are faced with having to deploy off-the-shelf web applications that you are unsure about the vendors security coding practices, which techniques or technologies would be worthwhile applying or deploying for some protection?

Assuming the following:

• You don't have access to the source code or can't easily influence changes.
• You don't have the resources, funds or skills, for penetration testing or vulnerability assessment of individual applications but funds maybe available for protection technologies that could be used across a range of web applications.
• You have no ability to veto the deployment of the applications.

Update: Think SysAdmin rather than InfoSec professional, that is you have some idea about security but it isn't your main thing.

What are the approaches, techniques or technologies that should be considered at the SysAdmin level without a Security Team to call on that would help them sleep better at night?

Answer 1

First, my condolences. That sounds like a real bummer - having to bolt on security after the fact with little or no analysis time, with a black box commercial product, no way to get fixes and a forced hand in terms of what product is chosen and when it's deployed is something like a security nerd nightmare. I'm sorry if this is a real situation - it's not a position I would want to be in, and my first advice would be figure out ways to politically wrangle yourself out of such a situation. This speaks loudly for an organization where security plays a serious backseat to the demands of IT. That always spells a bad case for good security practices and it could be your organization's #1 security problem.

Failing an organizational approach at changing the game, here's my common sense thoughts.

1. Know what authentication and access control the product provides. Not a full on pen test, just stage it, test it, read what docs you can get, and get some sense of how it fits together. That'll at least give some clues on weak points that bear some protection.
2. Application level firewalls that can watch and detect problems in incoming and outgoing HTTP traffic. Challenge - these are not usually cheap, and they take time and effort to tune. They are quite likely to have an unacceptable number of false positives right out of the box, and you will need time to get it set up correctly. Plan on plenty of testbed time before deployment and get a handle on as many valid use cases as you can for setting up test scenarios so that when you deploy you risk very little in terms of operational functionality.
3. Good backup strategies - figure out a way to deploy quickly and loose as little data as possible in the process. From what you've said, the new application is untrustworthy, but necessary - so figure it'll get hacked, and figure out a way to recover so that the downtime is minimal with as little impact as possible to your business' mission.
4. Isolate it. Don't put this untrusted app on a machine that also holds well-vetted systems. Similarly, keep the data somewhat isolated if you can, and use some sort of out band transfer mechanism if you have conjoin this data with other business data. When you have to do something like that, also consider that the data may be corrupt and build in protection mechanisms there. If it is built off access control systems used by other areas of the company, be sure that the web app has it's own account for privilege lookup functions, and that this account is kept to a bare minimum of capabilities with no change/modify permissions. Also - log anything that occurs where this system touches some other system so you have a good record.
5. Build your knowledge base slowly and surely. I can see a company balking at a security review if security isn't a high priority for them, but no one seems to object to admins learning more about the system as they go. Start small and cheap with trawling the web and then see what you can do in terms of weaseling free support from the company who provides the product. Some companies will be happy for the free customer feedback and the diagnostics of security issues. I've managed to weasel a fairly respectable amount of free tech support simply by being charming, assertive and non-judgmental.

Those are my thoughts. My basic premise is - treat this thing as a potentially dangerous hole in your system and do everything you can to protect the system, keep all functionality functioning and build up enough knowledge and protection mechanisms that you can eventually upgrade your faith in the product.

Answer 2

I think the most important action you can take is to expand/grow monitoring and observation capabilities.

If you know or suspect vulnerabilities exist without controls in place to prevent exploitation then what you really want is to learn as soon as possible if something bad has occurred.

Get great at logging. Plan to spend time reviewing logs. The more familiar you become with the behavior of the systems involved the quicker you can identify strange activity – and your brain is the ultimate pattern matcher. (btw, this is good to do anyway given the accepted belief that all prevention techniques/tool/products fail at some point)

You can start cheap by taking advantage of popular open source tools:

• ModSec (already mentioned) works great – check out Ivan Ristic's book (author of modsec) https://www.feistyduck.com/books/modsecurity-handbook/. Ivan describes ModSec as "Other times I will call it an HTTP intrusion detection tool, because I think that name better describes what ModSecurity does.” It will take time for you tune ModSec and gain proficiency, but it can go a long way to giving you the visibility you need.
• OSSEC for HIDS. You can even configure OSSEC to alert on ModSec events.
• Store netflow records to help you with incident triage/forensics if the need arises. You can look into a free network behavior analysis tools like FlowMatrix
• As mentioned, network segmentation to prevent a successful attacker from moving lateral is smart.

Basically, actively monitor for bad activity. Otherwise you may never know if the systems are compromised. Making the business owners aware of the number of attacks (derived from monitoring) may help you to win budget as well.

Answer 3

If you must blindly protect a web app, a Web Application Firewall (e.g. mod_security on Apache) may be of use.

Unfortunately, unless this is a critical core system that deals with financial transactions, it probably would not be raised as an issue even in an audit. I'm with Iszi -- cross your eyes, fingers, etc.

Answer 4

You can wait until a very large data breach occurs and then tell the business owners that the only way to protect their web applications is to apply secure application deployment standards that cover third-party, contrib, and outsourced software packages/components.

Yes, ModSecurity integration with OSSEC, with additional integration with a SIEM like OSSIM is an excellent starting position to be in. But this isn't the end game -- you will need to do a lot more.

OWASP AppSensor is one possible solution to some of the issues that ModSecurity can't deal with, such as authentication and authorization in web application security.

However, without standards and policies created by an application security expert regarding software component use -- every large-installation organization will continue to have major data breaches. The application layer is the greatest weakness.