Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : 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

Les mots clés de la revue de presse pour cet article : security policy guidelines
Les videos sur SecuObs pour les mots clés : security policy
Les mots clés pour les articles publiés sur SecuObs : security
Les éléments de la revue Twitter pour les mots clé : security policy





Les derniers articles du site "RLR UK" :

- Black Box versus White Box testing and when to use them
- Security groups should sit under Marketing, not IT
- EU Commission Working Group looking at privacy concerns in IoT
- Internal cyber attacks - more thoughts
- eBay's Weak Security Architecture
- Denial of Service DoS and Brute-Force Protection
- The Disconnect between Security and Senior Management
- Web Hosting Security Policy Guidelines
- Pentests Don't Make You Secure
- Here come the Security Police

---

S'abonner au fil RSS global de la revue de presse

---