Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage
Website Risk Assessment -Where Do You Start?
Written by: Bruce Mitchell, Expert
This is a short discussion of website security in terms of protecting systems against hostiles, whether inside or outside of an organization. Specifically, we look at showing you how to get that first "foot in the door start", how to mitigate your own exposure and some of the other issues you may encounter along the way.
Before we loose the word
That bids new worlds to birth,
Needs must we loosen first the sword
Of Justice upon earth ...
Make it a group effort
"Spread the blame as thin as possible"
Get your Corporate Security Department involved
This is, after all, half IT and half Security. They should have a say in it. It's far easier to get cooperation before an event than after it. Perhaps you can even siphon some of their budget instead of funding it all out of yours. If they're not interested and there's an issue later, you can say "Security wasn't interested, here's their memo." If they do come on board and there's an issue, the blame can be spread around. "Security signed off on it, here's their memo."
When there's an issue, Security is going to get involved anyway, so it's an enormous help to have people who know from the beginning, at least the skeleton of the situation and don't ask "What's this TCP thing?"
Get your Corporate Legal Department involved
Legal exposure in all states and countries is not identical. Example: The European Union has some very strict privacy laws. If your website delivers infected content, can your company be sued? What constitutes a legally defensible "best effort"?
Only corporate counsel can determine that. Be prepared for endless "We would not like to give an opinion on that at this time" and "Well, that is, of course, your responsibility, not ours." Make them sign off on things, make them approve methods and approaches so if there's an issue, their neck is in the noose too.
Determine the level of risk acceptance and tolerance
This is important because after starting down the Security Road, you soon discover that it never ends and there are many side roads. Spend as much cash, time and effort as you have; there are always more issues. There always will be. Somewhere there must be a sign that says "STOP HERE. PROCEED NO FURTHER."
Consider... Can the organization tolerate five-minute outages? One hour? Six hours? None at all? "None at all" means keeping multiple systems active and the consequent headaches involved with managing content across multiple sites, plus someone qualified to troubleshoot issues sitting in a chair, at the site, 24 hours a day, 365 days a year.
If a server is penetrated, what will the policy be? Try to repair it, swap over to a secondary RAID set, reimage it from a clean backup? Will that happen immediately, or will the intrusion hole be plugged first so that it can't happen again?
Everybody has to sign off on these decisions, or when there is an issue, the blame will descend like a gentle rain from the heavens, but only you will end up wet.
Confirm that you can meet the target risk level within your resources
Management -- whether departmental or corporate -- and Security always want more than can be delivered within your constraints, and at the same time require you to deliver everything you can within those same constraints, without any overhead.
"Overhead is for the unexpected; good management means there should be no need for overhead" is the business school standard. Yet nearly everything in ongoing security practice is new and unexpected.
Computer security is like shooting at a target that not only moves but is sometimes invisible. Last year's standard practice won't work 100% of the time this year. You may need more resources at any time, but if your budget or personnel are locked down until next July, you may not be able to deal with a new threat. Along with expected and usual practices, significant allowances must be made for the unexpected.
"Just a little more" and "Just this once" are death by a thousand paper cuts. Cash, time and effort are limited resources no matter how big the organization is. If more security is demanded than you have resources, then (a) you need more resources or (b) you can't satisfy those demands. There is no middle path.
Putting It Into Practice
"The Time Has Come, the Walrus Said"
Pick the low-hanging fruit first
Run the free site security diagnostics available on the internet. Run a lot of them; not all of them target the same issues. Run them frequently, even after establishing policies and procedures. See what they come up with and fix those issues yourself, first.
Later on, you may be buying time from professional security analysts; if you do, be sure that you get your money's worth by putting them up against refractory and obscure issues, not just things you could have addressed yourself.
Separate your variables
The web server, whether a single system or several, should fulfill that function and no others. "One hat per system" is always a good rule to separate functions. Don't let the web server become the Mail Transfer Agent for your domain, don't let it handle your company databases, and don't let it be the file server for clients. Make one system the web server and nothing else. If it's subverted it can't affect the other functions; if other functions are subverted they can't affect the website.
Restrict access to the server, both physical ...
If you're keeping your server within your corporate network and server room (more on this later), then keep it locked away in its own rack and with its own firewall and power supply. Use a unique lock and issue keys only to people who need them, with signed key checkout receipts.
... and via the network
Are there any ports open on the server other than HTTP, HTTPS and possibly SSH? If so, close them and move those services elsewhere. Minimize your target size.
Keep the web site's network access outside the corporate network proper, in its own DMZ. Better, co-host the web site or put it on a commercial hosting server so that it's not physically associated with your corporate LAN at all.
If you sell directly over the internet, things will be sticky between Web Security and Marketing. They want, nay, they will demand direct access to the web site server so they can update whatever they want, whenever they want, however they want. This is a recipe for disaster. If they must have access, restrict it. Give them access only to the databases that drive the site (and of those, only the ones they need to have access to) and never to the server or its configuration.
If You Need TLS Security, Do It Right
If your company transacts business on your site or keeps any kind of personal information about customers or employees, then the site must use TLS security. This is what produces that padlock on the browser line and confirms that information being transferred is protected.
Don't try to "roll your own" security certificate. That looks cheap and unprofessional, causes browsers to hiccup and warns users that your page is not protected by a good certificate, and in any case doesn't save much money. Buy a certificate from a reputable, major U.S. certificate authority. It will cost; it's worth it. "Bargain Basement" certificate issuers, no matter where they are located, have often turned out to have no internal security of their own, causing security credentials for their clients to be leaked worldwide.
Your Enemies Can Be Your Friends
After you've been running a while and things look to be set up correctly, look around the internet and hire a "gray hat" intrusion team. Have them attempt to break in and disrupt the server operation. Require written documentation on how they did it and how to fix it. When they find a hole, patch it immediately. Do this periodically, at least every six months or so.
Spend some time trying to break your own site from outside. If there are inputs, insert unlikely and improper inputs. Remember the story of "Little Bobby Tables" and emulate him.
Use The Optional Response Headers
At a minimum, provide the following HTTP response headers:
If your site uses cross-site scripting, it should also provide:
If your site uses Secure HTTP, it should also provide:
Automate What Can Be Automated
Most companies cannot afford to have a qualified person in a chair next to the web server 24 hours a day, 365 days a year. The world, however, has 24 time zones, and no matter where your server is, there are always hostiles located on the other side of the planet. Automate what you can; it may be the only protection you have from 6 PM to 8 AM.
Implement automatic protection against DDoS (Distributed Denial of Service). If you have any significant exposure on the internet you'll eventually run into criminals trying to hold your website hostage by DDoS. So it's best to address that problem right from the start.
If you're hosting with a reputable hosting company you can usually buy DDoS protection as an add-on service. If you're hosting your own server (and again, this is a bad idea because DDoS can saturate your entire incoming bandwidth) then purchase a DDoS solution from one of the companies that specialize in this.
Most server software has provisions for plugins to do automatic IP lockout of troublesome IP blocks and individual addresses. Get them, install them, and use them. Use blocklists such as Project Honeypot and Spamhaus. Subscribe to a commercial blacklist if you can afford it.
Don't Serve What You Don't Serve
If your customers are within your own country, don't expose yourself worldwide. Use GeoIP filtering to completely block access from other countries, particularly the ex-Soviet Bloc, Africa and the Far East. This measure alone cuts intrusion attempts in half.
What Color Is Your Parachute?
Sooner or later something bad will happen. To some people, any website is a target of opportunity and they'll take you down just for fun. Disk drives fail; sprinkler systems go off unexpectedly; power supplies blow up. Employees become unhappy for any number of reasons; compulsive gamblers run out of money; somebody sells access to the system to outsiders.
You have to plan for this because it's going to happen. Again, determine the amount of risk you are willing to assume.
At a minimum: Up-to-date backups. This might mean monthly, weekly, daily or even shorter intervals. It might mean redundant RAID sets current to 12, 24 and 48 hours ago.
In a one-server environment, at least one warm-redundant server so one can take over immediately on failure of the primary. A cold-redundant server does no good if it won't start when needed. In a multiple-server environment, continuous consistency checking between the servers so that any infected machine can be taken down quickly.
Should I Bring In Security Professionals?
If your company can afford it, this can be helpful. It can also turn around and bite you, depending on who does the job.
If you bring in well-known professionals with a good reputation, it will be costly. But if you bring in relative unknowns with no reputation, it can end up even more expensive as they install backdoors that can't be detected and sell access to your server, your network and all of your information to the open market. Yes, it can happen.
Outside companies are just like yours. They have unhappy employees, compulsive gamblers, dishonest employees and Peter Principle people in positions they can't fill properly. You can never know who you're getting, but if you must ... stick with the companies that have a reputation to protect.
Down A Side Road -- Java: Just Say No.
Most browsers do not accept Java applets. That is a poor way to get a message delivered but a great way to infect your visitors. Your company does not want to be sued for delivering infected Java applets to every visitor to your site if security fails. It will reflect badly on you, personally, if that happens.
Here endeth the lesson.
If you found this article interesting, please do click the thumbs up button to endorse it.
* Credit is due to Senior Page Editor Andrew Leniart, without whose determined prompting, this article would never have been written.