Three Incident Response Preparations You Should Be Making

In the context of cybersecurity, the adage “An ounce of prevention is worth a pound of cure” is a massive understatement. Make no mistake, the easiest way to handle a security incident is to prevent it from ever happening in the first place. We continually remind our readers about security best practices because the time spent implementing them is nominal compared to the time that would be spent responding in the aftermath of a successful attack.

The unfortunate reality, however, is that sites continue to fall victim to malicious activity every day. Even perfectly responsible site owners who follow every security guideline in the book need to prepare for the possibility of a critical security incident. Similar to household emergency readiness preparations, like owning an appropriately classed fire extinguisher or keeping a first aid kit, there are a few favors you should be doing for yourself as a site owner to help you get back on your feet in the event of a disaster.

Logs Or It Didn’t Happen

When an owner hears for the first time that their site has been compromised, the first question on their mind is usually the same: How? It’s a natural response, and it’s a question that security firms are commonly brought in to investigate. Forensic review of the breached system can provide answers in some cases, but the efficacy of these efforts frequently hinges on the existence of reliable event logs to be reviewed.

Server logs provide investigators with a dataset they can use to establish a timeline of events leading up to and during an attack. By identifying the activity taking place and its source, it can be possible to determine the scope of the compromise. That intelligence is how you can know whether an attacker had access to your users’ data or if you simply fell victim to a defacement campaign, and being able to confidently disclose these details to your users can be crucial in dampening the impact to your business’s reputation following an attack.

Log retention policies seldom come up in the conversations between new site owners and their prospective hosting companies, so it’s possible to unknowingly be a step behind in this process based simply on your site’s provider. If a host has an opt-in logging policy, or defaults to very short log periods, in all likelihood an inexperienced user will have no usable logs of a security event by the time they’ve been made aware of the issue.

Just how long to retain server logs for security purposes depends heavily on your industry and location. Industry compliance regulations may demand retention minimums or specific destruction timeframes, and regional regulations can introduce their own requirements. If you believe that your site might fall under such restrictions, consult with a legal expert familiar with your particular case. Otherwise, the amount of log history to maintain depends on how closely you monitor your site in other ways. If a site doesn’t see much attention under the hood it’s much more likely that a compromise can go undetected for months, so lower-maintenance sites might opt to retain logs longer to shore up that disadvantage a bit.

If your site is running on shared web hosting, take a moment to identify how your host handles access logging. Standard cPanel-based hosting accounts are becoming more and more common and default to a functional logging policy unless the host enforces changes, but proprietary hosting solutions may not play so nicely in every case. Either way, ensure that you’re able to archive and retain logs for an appropriate amount of time for your needs.

If your site lives on a server you have more direct control over, you can really roll up your sleeves and set up your logging however you like. For example, your run of the mill Linux webserver is probably making use of logrotate to manage the storage and archival of various logfiles. Logrotate leans on a fairly simple scripting syntax to build rotation rules, so it’s easy to configure retention policies for just about any purpose. Windows servers typically handle event logs directly, so there isn’t as much to worry about on a private Windows system in terms of storage and rotation.

If You Have One Backup, You Have No Backups

If the scope of an attack isn’t conclusively determined, or if a compromise has left a site owner uncertain of the continued integrity of their environment, it often becomes necessary to revert to a known-good backup of the site. This also facilitates the process of migrating a site from a compromised server to a new host while minimizing the potential to include infected code in the migration.

Of course, an owner’s ability to restore a site from backup depends entirely on whether they were making the backups to begin with. This, again, is a problem many unfortunate business owners fail to identify until it’s too late to be of use. Maybe they assumed their hosting provider was handling their backups for them, or that their site was so stable that they’d never need backups to begin with. Either way, a site needs backups.

To be clear, we’re using the plural “backups” very intentionally. Your filesystem and database contents are typically changing constantly, especially with a dynamic web application like WordPress running the site, so as backups get older they begin to lose usefulness. At the same time, having backups across a span of time can help ensure there’s a clean backup if a breach went unnoticed for too long.

There’s a commonly repeated guideline for backups called the 3-2-1 rule which suggests keeping three copies of your data, on two different media, with one off-site. It’s a pretty basic guideline, one which has been around for a while and may be due for a revamp in the age of cloud storage, but its basic tenets are sound. You can pull the numbers from the rule and still end up with sound advice: Keep redundant copies of your data, diversify how your data is stored, and make sure at least some backups are accessible regardless of the nature of the disaster.

One point that the 3-2-1 rule does fail to address is the need to test your backups. The aftermath of a cyberattack is the worst possible time for you to learn that your backup script broke five months ago. Periodically check your backups for integrity and watch closely for errors reported by any automated scripts you’re running. For critical systems, consider performing complete disaster recovery tests by spinning up a temporary server and restoring a backup to a running environment.

It sounds boring, but spending the time every now and then to make sure your backups are reliable brings with it a great deal of peace of mind. Simply put, it’s better to have them and not need them than to need them and not have them.

Hope For The Best, Plan For The Worst

While there are precautionary measures in place to prevent fire hazards in an office building, the workers in the building need to know there are fire alarms and an emergency exit plan just in case. By the same token, the members of your organization need to have a security incident response plan in place to ensure the issue is handled appropriately.

Depending on the size of your business, your incident response plan can be as simple as a sheet of instructions or a massive PDF document with diagrams and walkthroughs. Regardless of size, this document should clearly establish at least these few important pieces of information pertinent to the immediate aftermath of an incident:

Who is the person or team in charge of responding to security incidents?
Include any relevant contact information. If you retain the services of a third party team for your security, be sure to make note of who is authorized to contact them.

Which other parties need to be involved in which situations?
Above a certain scale, where your infrastructure relies on multiple teams, the security team handling the incident may not be directly familiar with the affected systems. Identify who needs to be called for each system, so your incident handler knows how to contact your database administrator for a database breach without pinging your entire IT staff.

What defines success in your response?
The key is to have measurable goals. These goals could be to limit service disruptions, or to publish a public disclosure of the event within a certain timeframe, et cetera.

Are there any mandatory steps that need to be taken?
If your region or industry imposes disclosure timeframes or other incident handling regulations, put these in plain language in your plan. Assign ownership of these steps to relevant parties to ensure they don’t slip through the cracks.

Include this information alongside details of where backups and logs are stored, and any other information that may be pertinent to your organization’s response. Having a predefined plan accessible to your team allows your organization to hit the ground running after a successful attack takes place, where time is critical. Even if your team is small and the contents of a plan could probably just be assumed, putting it on paper helps to remove any ambiguity in what is already a stressful event.

Conclusion

A common thread in the world of security advice is that any effort you’re able to give is going to be more effective than not doing anything. Even if you don’t have the capital to implement a redundant and scalable automated backup strategy for your site, you can at least set a reminder to yourself to pull a backup of your site down to a local drive once a week. Just put something into place sooner rather than later, because you can always improve it further down the road.