Skip to main content

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here.

Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts.

But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform to many of my recommendations, but I have yet to find one that, by default, conforms to them all.

Site Categorisation

There are several different categories of hosting and several different ways to categorise sites, with different requirements. However, in my opinion, sites should be categorised based on the information that they contain and the level of interaction allowed. Sites should then be logically and physically separated into their categories.

Sites can be categorised as brochure sites if they have static content or do not collect information. These sites can then further be categorised into public or private depending on whether the data that they contain is public or not. Sites within these categories may be co-hosted with other sites in the same category, but the two categories should be segregated.

Sites can be classed as data collection apps if they collect sensitive or personally identifiable information (PII) from the user. Sites within this category should be hosted on their own servers with no co-hosting and be segregated from all other sites. The data must be stored on separate segregated database servers that are secured and firewalled off.

Finally, any site with even more sensitive data on it or company secrets should be hosted internally if you have the expertise in house.

Hosted Environment

The following list is an example of the requirements for secure web hosting. It is not necessarily complete, but if you do not have the following then you may have issues in the future. All websites and web applications must:
  • be hosted on a dedicated environment - the hosting machine may be virtual or physical, but must not be shared with any 3rd parties. Multiple websites and applications from the same company may be hosted on the same machines according to the categories above
  • have DDoS protection in place
  • have AV running and configured properly on the server along with appropriate responses and reporting
  • be hosted behind a Web Application Firewall (WAF) to protect against common attacks, plus allow the ability to configure it for specific services
  • be hosted on security hardened Operating Systems (OS) and services to an agreed build standard
  • be subject to regular and timely patching of the OS and services
  • be subject to regular security testing and patching of any Content Management System (CMS) in a timely manner if used
  • be subject to active monitoring and logging by the provider for security breaches and reporting to/from the organisation
  • have formal incident management processes for both identifying and responding to incidents
  • not be co-hosted with additional public services beyond HTTP/HTTPS (e.g. no public FTP)
  • not allow DNS Zone Transfers
  • use proper public verified SSL certificates - with a preference for Extended Validation (EV) certificates
  • ensure that management services and ports are on different IP addresses and domain names preferably, but must not be available through the normal login or visible on the website
  • ensure that administrative interfaces and services are restricted to certain IP addresses at least, but make use of client-side certificates or two factor authentication (2FA) if possible
  • ensure staging servers are available for test and development, which must not be shared with live sites and should be securely wiped at the end of testing as soon as the site is deployed live
  • ensure staging and test environments are not available on the public Internet or, if there is no alternative, they must be devoid of branding and sensitive information in all ways and restricted as above
  • be built on a tiered architecture, or at least the database (DB) server must not sit on the same server as the web front end, must not be accessible from the Internet and must be securely segregated from the front end
  • use encrypted storage for all sensitive information, (e.g. passwords and sensitive information)

Hosting Services

It is up to the hosting provider and third party developers, but should be backed up by specific contractual clauses, to ensure that:
  • the site is backed up regularly off site in a secure location using encrypted media where the keys are stored separately from the media and able to be restored in a reasonable time frame with a suitable rotation and retention policy
  • hardware and media that has reached the end of its life is securely destroyed
  • all sites are made available for pentesting prior to going live and at regular intervals
  • all vulnerabilities considered of medium risk and above should be remediated prior to go-live
  • all sites are available for on-going regular automated Vulnerability Assessments
  • domain names, code and SSL certificates are registered to the company and not a third party
  • there are agreed processes for identifying approved personnel to authorise changes
  • change management processes that track all changes are in place along with rollback and test plans
  • capacity and bandwidth are actively managed and monitored
  • all management actions are accountable (unique accounts allocated to individuals)
  • all management should be through secure ingress from trusted locations
  • egress filtering should be in place to block all non-legitimate traffic

Comments

  1. I just review your every single blog post..and it was awesome..will be back to read this blog soon.

    ReplyDelete
  2. Hi Luke,
    I am searching for a web hosting service that can give me reliable service, my own domain names, a series of email accounts, PHP capabilities, decent storage space, and not cost much. Does u know of any businesses that are particularly good and well-known? Thanks.

    ReplyDelete
  3. Hi can you tell which hosting will be best for my business, it's an small business.
    btw nice post. thanks for sharing.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. I found your article helpful to me. Your article is attractive and increases the curiosity to know about the affordable and reliable web hosting companies using these two keywords together thanks for sharing such post.

    ReplyDelete
  6. Very handy allocation about web hosting security policy and guidelines. As a website owner I think this well contribution will be handy for those people whose are not known with this guideline. Its very much vital for all of us to know the perfect guideline for web hosting. Thanks

    ReplyDelete
  7. That's good, that's really good. I'm truly very benefited to get in such guideline and policy because I'm a newcomer and did not know much more about web hosting but your well contribution really assisted me to increase my knowledge. Thanks :)

    ReplyDelete
  8. Totally outstanding piece of writing! Actually I was looking for long time for knowing about web hosting security policy and guidelines but didn't get well information except this because here I got everything which I was accepting from anywhere and finally perfect match from here. So lot of thanks to you for providing this superb blog.

    ReplyDelete
  9. This comment has been removed by a blog administrator.

    ReplyDelete
  10. I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. paginas-web.mx

    ReplyDelete

Post a Comment

Popular Posts

Coventry Building Society Grid Card

Coventry Building Society have recently introduced the Grid Card as a simple form of 2-factor authentication. It replaces memorable words in the login process. Now the idea is that you require something you know (i.e. your password) and something you have (i.e. the Grid Card) to log in - 2 things = 2 factors. For more about authentication see this post . How does it work? Very simply is the answer. During the log in process, you will be asked to enter the digits at 3 co-ordinates. For example: c3, d2 and j5 would mean that you enter 5, 6 and 3 (this is the example Coventry give). Is this better than a secret word? Yes, is the short answer. How many people will choose a memorable word that someone close to them could guess? Remember, that this isn't a password as such, it is expected to be a word and a word that means something to the user. The problem is that users cannot remember lots of passwords, so remembering two would be difficult. Also, having two passwords isn't real

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most