Security policies matter for disaster recovery
- Details
- Published: Wednesday, 22 February 2017 10:20
Replicating the production security infrastructure at a disaster recovery site can be a problem: Professor Avishai Wool looks at how organizations should approach security policy management in their disaster recovery planning.
When it comes to downtime and cybersecurity attacks, despite many high profile incidents in the past year many businesses are still stuck in the mind-set of ‘it won’t happen to me’ and are ill-prepared for IT failures. And with IT teams facing a broad range of unpredictable challenges while maintaining ‘business as usual’ operations, this mind-set places organizations at serious risk of a damaging, costly outage. Therefore, it’s more important than ever to have plans for responding and recovering as quickly as possible when a serious incident strikes. As the author Franz Kafka put it, it’s better to have and not need, than to need and not have. In short, effective disaster recovery is a critical component of a business’ overall cybersecurity posture.
Most large organizations do have a contingency plan in place in case its primary site is hit by a catastrophic outage – which, remember, could just as easily be a physical or environmental problem like a fire or flood, as well as a cyberattack. This involves having a disaster recovery site in another city or even another country, which replicates all the infrastructure that is used at the primary site. However, a key piece of this infrastructure is often overlooked - network security - which must also be replicated on the disaster recovery site in order for the applications to function yet remain secure when the disaster recovery site is activated.
Building security into disaster recovery
Replicating the security infrastructure, however, can be more of a challenge than it may initially appear. The network at the primary site will contain routers, firewalls, servers and so on, and the disaster recovery site may be set up in exactly the same way. But the problem is, just installing the same equipment in the same configuration isn’t enough. All of those devices have security policies within them and these policies change on a daily or even an hourly basis, every time applications and users are added, amended or removed.
As such, whenever a policy change is made in the primary site it is critical to ensure that an equivalent change is made on the disaster recovery site. This requires synchronization between the two sites’ security policies to automatically replicate policies every time they change. How that synchronization is implemented will depend on the exact equipment and setup the organization is using, and it’s not always easy to do.
The most straightforward scenario is when the same equipment from the same vendor is deployed at each site – and that vendor offers a unified firewall management system. This means the same policies can be simultaneously installed on security devices on both sites; IT teams only have to make the change once in the firewall management system, and it’ll push the change out to the security devices in each site.
Overcoming language barriers
More complex scenarios occur when organizations don’t have such a firewall management system – or if the organization is using equipment from different vendors, or different models from the same vendor, at each site. In this setup, the policies at the two sites will not be truly identical, so synchronizing the two sites’ policies will need to be done in some other way. And if you rely only on human processes to synchronize the two sides – the polices will eventually diverge. Therefore, an automated system is the right approach to maintaining the synchronization.
The last thing to consider is the IP addresses in use at the primary and secondary sites. Are they identical or, as is more likely, are the IP addresses on the main site mapped to their logical counterparts in the disaster recovery site? In this case, any rules that are installed at the secondary site are going to look slightly different to the ones at the primary site – and again, you will need an automation solution to carry out the rule conversion.
It is essential to consider all of these aspects of security policy management when building a disaster recovery site. If you neglect these points, when disaster happens and you need to switch operations to your secondary site, then your systems and applications won’t work as you need them to.
As we’ve seen with recent serious outages, prevention is no longer enough to ensure robust readiness to unplanned incidents and cyber threats. Organizations also need to ensure that their incident response is as slick and unified as possible, so that when (not if) the worst happens, they can get critical systems back up and running quickly, to cut disruption to a bare minimum. And having your security policies configured and orchestrated across the entire organization, in both primary and disaster recovery sites, is a critical facet of this.
The author
Professor Avishai Wool is CTO at AlgoSec.
