Year Of Security for Java – Week 48 – You Will Get Hacked

No Gravatar

What is it and why should I care?

You will get hacked. That is not meant to be a sensationalist line, but rather a functional reality in the environment we currently occupy. There are a few reasons I feel safe in stating that assumption:
– Many have already been openly hacked, including those that are well known for being “more secure” and even those that are security vendors. Also, I know of many companies that have been hacked and have not gone public, and I’m sure that’s the case for many others.
– Information security is a relatively young field, with weak solutions compared to other “security” fields.
– The change of pace in the technologies we protect is significantly different than that of our solutions. New technologies are coming online faster than we can secure them, and the security of those technologies is no better (and often worse) than what we already have.

I should at least define what I mean by “hacked” in order to clarify my original point. I mean that there is some successful attack against your systems. That could be a data breach through a web service, a website defacement, an insider stealing data, a backup disk or laptop getting lost, hardcoded keys being found on your hardware, or any other of a number of possible successful attacks you’ve heard about recently. There are lots of ways you can lose, and as the old adage goes, it only takes an attacker one successful attempt, and you have to successfully defend against all of them.

If that sounds bleak, it should. However, I’m not suggesting we throw our hands up and quit, but rather we plan for the eventuality that an attack will succeed. Banks have been successfully robbed since they’ve been in existence. However, they don’t just shut down and go out of business because they know they will get broken into, but rather they put security controls in place, they monitor, they work with law enforcement, as well as use lots of other techniques to prevent the attack in the first place, and when necessary, recover from a successful one.

What should I do about it?

If we work from the assumption that the successful attack will eventually occur, it changes our mindset a bit. We now don’t just have to work towards preventative security, but we also have to think about recovery, or incident management. There are many components to a successful program to manage security when you plan ahead for successful attacks, and here are just a few for consideration:

Disaster Recovery Planning
While disaster recovery planning is traditionally associated with a natural disaster, there are significant benefits to performing this exercise for continuity (DR is also known as business continuity planning) in the wake of an attack. Tasks of interest here would include ensuring you have a solid backup plan for both your systems (servers, network, etc) and your data. For larger organizations that can afford it, this could mean having additional hardware at an off-site location generally a significant distance (far enough away that the same hurricane/tornado/flood, etc. won’t affect it) that can be enabled if the primary site goes down. If you are “in the cloud”, you should build your applications with the capability to roll over to different “regions”, effectively accomplishing the same goal, but on rented hardware.

DEVOPS
Devops is all the rage these days, and has numerous benefits. In the context we’re discussing today, one benefit worth noting is that updates and fixes can be pushed to production quickly and safely. You have processes in place that allow for code to be built, tested, reviewed, and pushed extremely quickly, and you also have the capability to roll back updates when needed. These are critical capabilities if you want to stay functional when under attack. If you found out you had an injection that could be (and was being) actively exploited, would you rather shut the site down until further notice, leave it up and vulnerable, or be able to fix it quickly and push out the update and keep the remainder of your site up?

Application Layer Intrusion Detection and Prevention
I’ve already written about this a couple of times before, but will provide a brief recap here for the relevant portions. This is an area where intrusion detection and prevention really shines. If we know we’re being attacked, and we are keeping track of our users and the “bad” things they are doing, we can take some actions to protect ourselves. One of the side effects of knowing people are attacking you and tracking those users is that you start to think about how you’d like to be able to respond. For example, with AppSensor, you can respond by disabling the user account, notifying an administrator of nefarious activity, or you can block resources within the application. The capability to block resources is interesting for our context. Let’s say you have a management console that allows you to do this, and you find out there’s a vulnerability within your application, but it only resides on a certain page. With this capability, you can just block access to that page/function, and leave the rest of the site up. That will give you time to get the fix deployed, and then you can re-enable the feature.

Incident Management Team
This is more of a resource issue, but can greatly improve your ability to respond. Depending on the size of your organization, this could be part of a person’s role, or the responsibility of a large group. By focusing effort here and building out a team to handle incidents, you can have focus and move towards better planning, root cause analysis, security controls, monitoring, etc.

Bug Bounty Program
Let me be clear that I would not suggest this for organizations that have either a)policy or regulatory concerns and consequences, or b)immature secure groups.
With those caveats, anecdotal evidence from organizations that have tried this suggest it can be very effective. You open up your applications to being attacked intentionally, and reward those who find issues and disclose them “responsibly”, as defined by you. You essentially are getting a lot of cheap testing (though it’s in prod). There’s a lot of concerns to consider here, but it can certainly guarantee that you get a good testbed of attacking activity against your application.

Normal Security Program
The above are a few ideas for things that I haven’t necessarily discussed in this series that come in handy when thinking about dealing with successful attacks. However, they all still fit into your normal security program and planning process. Also, they don’t come in to the exclusion of anything in your existing program. DEVOPS does not win out over code review. They are complementary and both should be used. Actually, in most cases, you’ll find that doing one is either a requirement for or benefits the other. Continue doing the things you’re already doing, and just consider these additional program components.

In conclusion, at some point, your applications and systems will get successfully attacked – it is only a matter of time. It is wise to recognize that and deal with the situation in advance. With solid planning, you can put in place controls that include prevention, monitoring and detection, response, and recovery. These controls should be added to your overall security program in order to further strengthen your overall capabilities.

References
———–
https://www.owasp.org/index.php/OWASP_AppSensor_Project

Be Sociable, Share!

Technorati Tags: , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *