Website Risk Assessment - Where Do You Start?

---

Website Risk Assessment -Where Do You Start?

Written by: Bruce Mitchell, Expert
Experts Exchange

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 ...
 Rudyard Kipling

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 it may not be possible to deal with a new threat.  This will cause anger in the people who put you in that situation in the first place and their ire will descend upon on you.  From the very start, be cognizant of the consequences of company policy and changes therein so that you do not end up in that situation.  When it comes to security, along with expected and usual practices, significant allowances must be made for the unexpected.

The flip side of this is "Just a little more" and "Just this once."  No matter what the organization or industry, if "Just this once" occurs every week it is 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"

Stick with the standards

There are three major players for underlying web server software on which a site can be built.  In no particular order, they are:  Apache, IIS and nginx.

These three servers are well known and well supported.  Plugins exist to do nearly any function desired.  There are also subsystems which run atop these servers (e.g., Apache Tomcat, Wordpress) to do higher-level things such as wikis, catalogs, online ordering, blogs ... you name it, it's probably already out there.

The great advantage of using standard tools is that they are widely used.  If there is a problem, it'll be caught by sites that demand the bleeding-edge latest and greatest.  If you want a plugin, chances are somebody has already written it.  If there's a problem, there is a user community which can help.  If you want something done but don't have the expertise in-house, competent people will exist who can be hired to do it for you.

Running a web site is a high-risk situation at best, with hostiles everywhere ready to take you down "for the lulz."  Minimize your target size, maximize the supportability, and minimize the number of holes in your security by using standard tools.

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.  Don't even let it be a print server.  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 nice green padlock and site owner name on the browser line and confirms that information being transferred is a) protected and b) going where you think it is.

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 certificate authority. It will cost more; it's worth the extra price. "Bargain Basement" certificate issuers, no matter where they are located, have often turned out to have no internal security of their own, resulting in security credentials for their clients being 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.  It's better that you break something and fix it immediately, than somebody else breaking it and exploiting a problem.

Use The Optional Response Headers

At a minimum, provide the following HTTP response headers:

Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
X-XSS-Protection

If your site uses cross-site scripting, it should also provide:

Access-Control-Allow-Origin

If your site uses Secure HTTP, it should also provide:

Strict-Transport-Security

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, Part 1

When somebody is outside your door at 3 AM in the dark yelling "Let me in!", won't identify themself and doesn't know your name, it's reasonable to decline welcoming them to your house.  Likewise, when a request arrives at your site be sure that it is for your site and not for any site that might happen to be sitting on your IP address.

There is a vast difference between "http://www.mysite.com/index.php" and "http://192.168.1.247/"  The first one says "I want your site, no other, and I know the URL I want."  The second one says "I want any potential victim sitting on this IP address, and I want the default root page" -- and so begins trouble.

Enforce fully-qualified domain names incoming URLs.  This is easy in Apache with named virtual hosts, and relatively simple to do with mod_rewrite no matter what the configuration may be.

Don't Serve What You Don't Serve, Part 2

If your customers are within your own country, don't expose yourself worldwide.  If your customers are within your own state, province, canton or whatever, don't expose yourself outside the immediate geographic area.  Use GeoIP filtering to prevent access from unnecessary areas.  Just blocking the ex-Soviet Bloc, Africa and the Far East cuts intrusion attempts in half.

The increasing use of Tor and VPNs unarguably causes problems for geolocation and there is no universally good solution.  Only you can decide how to deal with this issue appropriately for your business.  A retail business might display a polite page stating "We're sorry, but we are located in Freedonia and it is not practical for us to (deliver food, lay cement, sell trucks) to customers outside our area.  If you are in our service area, then a VPN may be causing you to appear somewhere else."

Friendliness Must Have Limits

A degree of friendliness and accommodation is required in a good site.  If a request arrives with just your site name, e.g. http://www.mysite.com/, it is courteous and desirable to translate that URL internally to the correct root document URL so that a visitor can go to the front page of your site using just the site name.

But that should occur only at the site root.  Don't serve directory listings or automatically select index documents when any other URL is not complete.  Serving up a directory listing or a default URL when the incoming URL is http://www.mysite.com/secure/subdirectory is not a good idea and is definitely a potential data leak.

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 must plan for this because it's going to happen.  The universe consists entirely of quantum randomness, and as things scale up those little random events sometimes cascade and become problems large enough to notice.  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 the warm spare can take over quickly on failure of the primary. A cold-redundant server may give a warm, fuzzy feeling but the chances are that when it is actually needed it won't be up to date with the main server.  Further, a cold spare is cold until it is started and it does no good to have it around if it won't start when needed.

In a multiple-server environment, there must be continuous consistency checking between the servers so that any failed or 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 -- Flash: In The Can.

Adobe dropped support for Flash on December 31st, 2020.  During its active lifetime it was riddled with exploits which opened doors for viruses and malware.  However, at that time there was no standard for interactive video in browsers so it was used anyway despite the problems.

HTML 5 has corrected that situation and all modern browsers can display video.  There is no need for Flash for new projects and any existing Flash applications should be quickly migrated to other media because browsers will soon refuse to display Flash applets.

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 ... but your journey has only begun.

* Credit is due to Senior Page Editor Andrew Leniart, without whose determined prompting, this article would never have been written.