If you design, develop, or host websites for SMBs, your clients are trusting you to keep their data secure. Here are our top 4 website security tips.
Too many small and medium-sized businesses (SMBs) have a pervasive, persistent delusion: “We’re too small—hackers wouldn’t be interested in us.” But it’s never really been true.
And now it is demonstrably, statistically not true. The latest Verizon Data Breach Investigations Report (DBIR) found that 43% of breaches involved SMB victims. That’s two to four times the percentage of victims in the public sector (16%), healthcare (15%), and financial (10%).
So if you’re a small business, face it—you’re a target. If you cater to SMBs, you and your clients are targets. If you design, develop, and host websites for them, you are one of their front lines of defense. Obviously, the health—even the survival—of your business depends on how well you protect yourself and your clients.
The list of potential damages from a breach are both familiar and painful: Loss of thousands to millions of dollars in business. Brand damage. Lawsuits. Compliance sanctions. Having your site blacklisted by search engines for being insecure. If SMBs trust your company to keep them secure, a loss of trust is an existential threat.
But you’re not helpless. No, you can’t bulletproof your software—in the online world, nothing and nobody is entirely free of risk. But you can make it a lot more difficult for attackers. And if you do, it’s a good bet that the bad guys will look for easier targets.
Thomas Richards, network and red team practice director at Synopsys, recommends a series of basic measures for companies that design, develop, and host websites to improve the security of those sites and send hackers looking for easier targets.
The traditional method of protecting web applications using corporate firewalls, authentication to an LDAP (Lightweight Directory Access Protocol) directory, and a hardened web server in the DMZ network is still necessary. But it’s no longer adequate in a modern infrastructure with cloud-based resources facing increasingly sophisticated attacks. This is where a WAF is useful.
A WAF helps protect web applications by filtering and monitoring HTTP traffic between the apps and the internet. Essentially, it functions as a shield. It’s useful for blocking zero-day exploits, malware infections, and attacks such as cross-site request forgery (CSRF), cross-site scripting (XSS), SQL injection (SQLi), and file inclusion. But keep in mind that it’s not designed to block every type of attack—it ought to be part of a suite of tools.
It is also known as a reverse proxy. While a proxy server protects a client machine’s identity by using an intermediary, a WAF protects the server by having clients pass through the WAF before reaching it.
The rules governing WAF operations are called policies, which are used to filter out malicious traffic. A WAF is designed to allow quick and easy policy modifications, which lets the user respond more effectively to attack vectors.
What’s the difference between a forward proxy server and a reverse proxy service? Cloudflare explains it here.
Essentially, the forward proxy sits “in front” of client machines. When those machines make requests to sites and services online, “the proxy server intercepts those requests and then communicates with web servers on behalf of those clients, like a middleman.”
Why have a digital middleman? There are several reasons: to avoid institutional browsing restrictions, to block access to certain content like social media sites, and to make the user anonymous.
The reverse proxy, by contrast, “sits in front of an origin server and ensures that no client ever communicates directly with that origin server.” A reverse proxy service such as Cloudflare assists with DDoS protection, load balancing, and distributed content delivery.
Among the benefits of using a reverse proxy is that it improves website security. As Cloudflare explains, “With a reverse proxy in place, a web site or service never needs to reveal the IP address of their origin server(s). This makes it much harder for attackers to leverage a targeted attack against them. Instead the attackers will only be able to target the reverse proxy.”
Multifactor authentication, or MFA, provides a layer of security that ought to be mandatory for every organization. It won’t make you bulletproof (nothing does), but it makes users, and therefore websites, much less vulnerable. Enforcing MFA on the administrative interface your clients use to manage their websites can help prevent account takeovers.
MFA does what its name implies: It requires more than one authentication mechanism. The most common type is two-factor authentication, or 2FA, but MFA can stack multiple mechanisms, each one serving as another tier of protection. Those mechanisms include something you know, like a password or PIN; something you have, like a smartphone or hardware token; and something you are, such as a fingerprint or a voice print. The latest frontier in MFA is “something you do,” or quirks in the way you behave or interact with a device that set you apart from other users.
A common type of multifactor authentication is SMS-based authentication, which combines “something you know”—a username and password—with “something you have”—a phone. When you create an account, you register your phone number. On later log-ins, after you enter your username and password, the site sends you a text with a unique one-time passcode (OTP) to enter.
At Synopsys, 2FA involves an app that produces a numeric code every 30 seconds. Without it, even if a hacker steals someone’s password and username, they can’t impersonate the user or gain access to their account.
If you use software hosted and deployed by providers, such as a CMS like WordPress, keep it up to date to prevent known vulnerabilities.
This is otherwise known as “patch, patch, patch!” or “update, update, update!” It is one of the cheapest and most reliable ways of improving website security, since patches are (usually) free and fix known vulnerabilities.
But—and this is a colossal “but”—many patches, particularly in open source software, are not installed automatically. It is up to the users of the software to keep track of what they are using and when and whether to patch.
As has been said many times, but needs to be said many times more, you can’t patch what you don’t know you have.
The consequences of failing to patch can be catastrophic. Perhaps the most notorious instance is the 2017 breach of credit reporting giant Equifax, when hackers stole the personal information of more than 145 million people. The company had failed to install a patch for a flaw in a popular open source component used in their dispute portal. Though they knew about the patch in March, they were breached in May, and they didn’t even discover the intrusion until the end of July.
Don’t be like Equifax. It takes time to do the basics, but not much money—far less than what it costs to clean up after a breach.