Disaster recovery (DR) security issues pop up frequently in the IT industry. Storage managers often cover the basic...
security measures in their environment, but that's often not enough; data security issues must be addressed in IT disaster recovery plans. Also, storage managers should always look at data security from the perspective of a malicious attacker. With these two strategies, companies can better recover their systems if they're attacked and/or go down.
Kevin Beaver, independent information security consultant at Principle Logic LLC, takes a closer look at disaster recovery security in this Q&A. Find out the most important steps to take in order to best protect yourself against security vulnerabilities, what technologies are best suited for disaster recovery security and how to perform tests to see if your environment is secure. Read his answers below, or download the MP3.
Listen to the data security issues and DR plans Q&A
What are some of the biggest data security issues that pop up in the IT industry that storage managers should be aware of?
The biggest data security issues are the ones storage managers don't know about. The reality is that many businesses don't truly know where they stand. They usually cover the basics: The firewall is in place, systems are being patched, backups are being made and user accounts have strong passwords. But many managers assume these basic data security measures are enough. But you never really know how well you're protected until you take a look from the perspective of a malicious attacker or a rogue insider.
I know there are a lot of studies out on the Web right now saying that this year is going to be the year of malware with all of these command and control bots and things like that. And although that's a big threat, it's probably not as big of a threat as some of the basic stuff that's being overlooked. The things that stand out the most to me are Web application vulnerabilities, namely in and around the storage environment. A lot of storage management, data backup and DR management systems have a Web interface, and quite often these Web interfaces are full of vulnerabilities. Granted, they may be on the inside of the network, but if you have a bored or malicious and technical person on the inside, things can go wrong. Default passwords and flaws that allow you to bypass the login mechanism to a Web vulnerability called SQL injection are vulnerabilities that are exploitable in many different ways that administrators aren't really thinking about. To make things worse, sometimes these Web interfaces are accessible to the outside world.
Essentially, it pays to know where you stand. The vulnerabilities are always there -- Web vulnerabilities probably stand out the most to me, but you never really know until you take a close look at your systems.
What steps should you take to best protect yourself against security vulnerabilities?
The solution is relatively simple. Know what you've got. Understand what's at risk. And then do something about it. With the right technologies and business processes in place you can keep the risks to a minimum. The problem is that many people don't want to take these steps, or they get their priorities mixed up and take these steps out of order. For instance, you'll see people documenting their security policies and DR plans, or you'll see people implementing all the proper technologies to keep the risks at bay. However, they might not actually take a step back and look at the real issues to see what's really going on and what the critical systems and risks they're actually being exposed to. This creates a situation where they're focusing on the wrong stuff or improperly managing the issues that they do acknowledge.
Where does data security fit into a disaster recovery plan?
Information security has a direct tie-in to incident response. Incident response is basically a number of steps you take to properly respond to data breaches, malware outbreaks and so on. Incident response in turn has a direct tie-in to business continuity (BC) and ultimately disaster recovery. The reality is if your information system is taken down for whatever reason: a flood, malware, hack attack, etc., you still have a business continuity and disaster recovery issue on your hands. You can look at it that way, and that's a legitimate approach. I always tell my clients to be sure and include these components, especially security incident response, when building out your disaster recovery plans and your technologies, because you never know what's going to happen. And you never know what steps you're going to have to take to actually recover your environment. Again, if your systems go down or become unavailable, it still creates a business continuity situation, or a disaster.
What technologies are best suited for disaster recovery security?
Technologies for disaster recovery security are going to vary from business to business and depend on your network, layout, applications and your information system's complexity. As we grow and new technologies emerge, our information systems are becoming more complex, and complexity is the main enemy of security. There are technologies out there to help simplify things like virtualization. Other technologies might work better for some people like basic data backups or fancy continuous data protection (CDP). For some people, the technology that might work best for DR security is going to be your resilient network perimeter and server environments that have a nice failover or some sort of continuity built in. You may even rely on identity and access management technologies to manage users when something goes wrong. And even some of the cloud-based services out there will give you something to fall back on. In that case, at least you have some of your data offsite.
The type of DR security technology that's right for you is based on need and risk, so you have to step back and decide what's best for the business, and that's going to involve getting the right people in on the discussion, looking at your environment and seeing what the real risks are.
What can you do to test to see if your environment is secure?
Many businesses have an IT or security staff to handle this, especially larger enterprises. They typically have dedicated security administrators or internal auditors to do this type of work. And that's fine. You just have to be careful in that type of situation. Not knowing what's really going on when the fox is guarding henhouse can be dangerous. I've seen many situations where I've been called in to do an internal security assessment where the environment is supposedly secure, but when a security audit is run, issues are dug up that are big problems, and it usually links back to the administrators. The administrators were being lazy -- there were things where perhaps they knew about them but they weren't doing anything about it because it took too much effort. There are all sorts of issues like that.
It's often beneficial and sometimes required for certain contracts or even compliance to have an independent third party look at your systems. I think that can be good. If you bring someone in from the outside, they can get a fresh perspective; they're not caught up in the bureaucracy of the business and they have nothing to gain politically. They can just get in and get out and show you what's going out without having a conflict of interest. There's really a whole methodology to finding vulnerabilities in your environments.
The most important thing in testing to see if your environment is secure is to use a malicious mindset and go about it from the bad guy's perspective. Use good vulnerability scanning tools, but understand that they're not going to be all you need. You're going to have to poke and prod your systems manually in order to find the issues that really matter beyond what the scanners find. Then you have to look at all the important areas. A lot of people just look at the perimeters and the highly visible systems. Meanwhile, they've got these other systems and back doors where they're literally bleeding and wide open for attack. You've got to look at the areas that matter, the critical systems, and sometimes the non-critical systems. This may be storage, your disaster recovery environment, or other areas in your systems.