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.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

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.


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.

The post Three Incident Response Preparations You Should Be Making appeared first on Wordfence.


5 Things to be Aware of When Buying WordPress Security

If you are new to WordPress or reevaluating your security strategy, you are overwhelmed by choice in today’s market. The reality is that there are only a handful of tools that truly protect your WordPress website from a hack and help you detect an incident. With all of the claims that vendors are making, it can be tough to choose the most effective product to protect your investment and your customer data.

To help you in your decision making, I’m going to call out 5 things in this post that you need to be aware of before you choose a security plugin, a cloud solution or something that runs in the hosting environment that your hosting provider is selling.

1. Not all security products include a firewall

Many of the best known security plugins for WordPress don’t actually include a firewall. To understand this, it’s important to understand what a firewall actually is. The firewall in Wordfence is known as a Web Application Firewall or ‘WAF’.

For a WAF to be effective, it needs to fulfill a few basic requirements:

  1. It needs to block a wide range of attacks based on it’s ability to recognize website requests as attacks. Types of attacks include SQL injection attacks, remote code execution, cross site scripting and cross site request forgery attacks.
  2. The WAF needs to have a rule-set that is continuously updated. These rules are used to recognize attacks and block them. They can’t be updated only when the software is upgraded. They need to be updated constantly via a ‘feed’.
  3. The WAF needs to analyze ALL requests, not just requests that hit a particular application. In other words, if you have installed a WordPress WAF, it must block requests that try to directly access a script in a WordPress subdirectory along with requests that hit WordPress itself.
  4. The WAF needs to be very high performance. It will be inspecting every request that hits your site and it’s very important it doesn’t slow your site down at all.

Wordfence fulfills all these requirements. It has a comprehensive rule-set that blocks a wide range of attacks and is continuously updated via our Threat Defense Feed. The Wordfence WAF inspects every request made to a PHP application on your website. Whether it’s a WordPress request or a direct attack on a script like Timthumb, Wordfence will see it and analyze it and block it if necessary. Wordfence is extremely high performance. We use core PHP functionality for our rule-set that executes very fast, we pre-filter rules and only execute what is relevant and our rule-set is highly optimized.

Many popular security plugins for WordPress don’t include a WAF, or firewall. They include features like brute-force protection, file change detection, backups, strong password enforcement and so called system ‘tweaks’. But they don’t include the most basic security component of them all: An effective web application firewall.

When purchasing a security product, make sure it actually includes a firewall.

2. Cloud firewalls can be bypassed and don’t have identity data

cloud-waf-diagramBecause cloud firewalls execute on remote servers out on the Internet, it’s possible for an attacker to go around them and attack your site directly. We’ve written about this in some detail.

Because cloud firewalls execute remotely, they don’t have access to your WordPress API and database. That means they don’t know basic things like: “Is a user signed into your website or not?” They don’t have this data so they can’t use it in their decision making about who to allow and who to block.

If you don’t even know whether a request is coming from a site administrator or an attacker, how can you provide effective protection? We’ve written about the cloud WAF user identity problem in some detail.

Cloud firewalls also use a rule-set that is generic. Their rules are designed for all websites. That means they don’t specialize in a specific platform. The result is that they can allow through some of the best known and most basic attacks on a platform like WordPress.

Wordfence Protecting the EndpointWordfence is designed specifically for WordPress, it knows and uses user identity to make it’s decisions and it’s not possible to go around the Wordfence web application firewall because it runs directly on your WordPress website.


3. Some malware scans don’t check very much

When choosing a malware scanner for WordPress, it’s important to choose one that does a deep thorough scan of your site. Malware authors have become very creative in how and where they hide malware once they’ve compromised your website. Without a deep scan, your site may be infected and you won’t be aware of it.

iThemes Security, the second most popular security plugin for WordPress, uses Sucuri Sitecheck to perform a malware scan. You have to pay for iThemes Pro to gain access to this feature, which currently costs $48 per year.

Once you’ve paid for iThemes security and have access to the malware scan feature, you can launch a scan. A Sucuri scan using iThemes Security on my test WordPress site only performed 22 page requests. All the checks are remote, so no source code is inspected.

After doing this scan, this is what my logfile looks like. Click for a larger image.

ithemes sucuri malware scan

As you can see, it didn’t do very much.

Below we show what a typical free Wordfence scan looks like (it’s in reverse chronological order). As you can see we analyze the source code of over 4,000 files on the same site and perform a host of other checks. Click the image for a larger version in a new tab.


When choosing a malware scanner, make sure you pick one that performs a comprehensive scan of your website and doesn’t just do a cursory check. Malware can be hard to find and well hidden. Wordfence performs a deep and comprehensive scan of your site every time it runs.

4. Malware scanning takes a team, forensic work and processes

Forensic WorkHave you wondered why our Wordfence site cleaning service is is so reasonably priced, even though you get your own Wordfence analyst working closely with you to fix your hacked site?

It’s because your hacked website is an amazing source of forensic data for us. We take the footprints that a hacker left behind and add that to our malware scan.

To provide an effective malware scan, you need to perform hands-on forensic analysis of the latest attacks as they happen. That’s what our site cleaning team does.

Then you need to take that attack data and run it through a process to turn it into threat intelligence and distribute it, in real-time to a great malware scanner. That is what our Threat Defense Feed is. The TDF describes our process of gathering, analyzing and distributing threat intelligence to the Wordfence malware scanner and firewall.

I’m not currently aware of a single WordPress specific malware scanner that combines a high performance scan engine with a team and process like Wordfence does.

5. Watch out for ‘automated‘ malware removal

Some companies offer an ‘automated’ fix if they detect malware on your website. When we first heard about this we viewed the concept with deep skepticism. If malware is detected on a website, it has been compromised. The definition of a ‘compromised’ site is that someone unauthorized has gained access to the site.

Incident response is a complex field. We have certified forensic investigators on our team who have developed our site cleaning process. To get an idea of how the a typical incident response process works, you can reference NIST publication 800-61 “Computer Security Incident Handling Guide” [PDF].

In general, forensic analysts will divide incident handling into three phases:

  1. Detection and Analysis: This includes analyzing attack vectors, documenting the incident, prioritization and notification.
  2. Containment, eradication and recovery: This includes evidence gathering, identifying what has been attacked and evidence gathering.
  3. Post incident activities: In this phase forensic data is analyzed, evidence is retained and the data is used to prevent future incidents.

There are several different approaches to incident response and you can visit OWASP to learn more about how they tackle the problem.

If a site is compromised, an automated fix would leave out many of these steps. For example, it would not be able to determine how an attacker gained access and so the site may be repeatedly hacked.

We currently recommend that you avoid products that claim an automated fix is possible for a compromised website. Instead we suggest that you use a security analyst trained in incident response to help fix your hacked website. One of our human analysts would be glad to assist you.

The post 5 Things to be Aware of When Buying WordPress Security appeared first on Wordfence.