Website Pre-Launch Security Review Checklist
The review of safety at BP's Texas Refinery following investigation and report on the explosion in 2005 which killed 15 people, injured 180 and caused substantial property damage, included a recommendation to use pre-startup safety reviews (PSSRs).
We can all learn lessons from unfortunate incidents like this in other disciplines (e.g. also the sinking of the MV Herald of Free Enterprise in 1987). Do web site developers and designers have an equivalent pre-launch security review (PLSR)?
I remember once reading an email press release about a new web site, only to visit it and find out that within a few link clicks you ended up in some sort of CMS admin area; we stopped browsing immediately and contacted the site's owner. In the past I have also been asked to make a web site live on Friday afternoon at 4pm; the answer has to be "no".
What should a PLSR include for a new or revised web site? If you don't already have a security policy, standards and procedures, here is a checklist of suggestions:
| Part | Item | Check |
|---|---|---|
| Documentation | Launch/release approval by project owner | |
| Licences, permits, notifications, contracts, agreements and insurances in place/updated | ||
| User, operator, systems and administrative manuals | ||
| Full web site build documentation (from bare servers to fully operational web site) including platform definition and an inventory log | ||
| Detailed launch procedure, with a clearly defined launch initiation step, identification of dependencies, definition of duties, list of responsibilities, estimate of timescales, possible issues and roll-back plan (approved by the project owner, installation/launch checked on a clean test system and checked against other recent web site launches) | ||
| Post launch checklist (updated subsequently following a review of the launch, documentation of issues and how they were resolved what was changed in the launch procedure) | ||
| Change management procedures | ||
| Vulnerability reporting procedure and response plan | ||
| Security incident response plan | ||
| Disaster recovery plan | ||
| Data retention, archival and disposal plan | ||
| Defects | Previously identified defects and vulnerabilities (security faults) corrected and re-tested, or accepted by the project owner | |
| Code smoke/regression tested | ||
| Changes to threats and compliance requirements checked | ||
| Pre-launch vulnerability network and web application assessment (looking especially for configuration issues) | ||
| Changes made since the previous project security review checked and approved | ||
| Resources | Project team availability (including client team) | |
| Server and network resource capacity and availability checked for launch, typical and peak usage (bandwidth, memory, processor and disk space) | ||
| Operational staff trained | ||
| Post-launch review meeting scheduled | ||
| Related systems | Effect on related projects and initiatives determined | |
| Related information systems and business processes ready | ||
| Third party services enabled/activated/ready | ||
| Integrity | Test accounts and test data removed | |
| Test, old, backup pages and other files removed | ||
| Temporary, debug, seeded defects and test code removed | ||
| Data revalidated | ||
| Source code reviewed for hard-coded configurations, test code and malicious code (e.g. back doors, bypasses, time bombs, other unauthorised functionality) | ||
| Source code repository updated | ||
| Installed code, scripts and other files checked against the approved release code and consistency checked | ||
| Electronic media (e.g. hard disks) and memory scanned for malware | ||
| Indexing systems configured correctly, the resultant collection/catalogue/index fully populated and do not include incorrect resources | ||
| Data imports, scheduled processes and data population routines executed (after consideration of the consequences/side-effects on other systems and processes) | ||
| Metrics information reset/zeroed/cleared | ||
| Backup | Backup and archival plans implemented and tested | |
| Backups of servers, web site assets and data immediately prior to launch | ||
| Backup protection | ||
| Source code protection, access and escrow arrangements in place | ||
| Configuration | Only the required software and services installed or enabled on the server(s) | |
| Operating system, services (e.g. web server, mail server) and other software (e.g. database, administrative interfaces) hardened and checked against standards and good practice guides | ||
| Accounts used by services and other software checked | ||
| File system permissions checked | ||
| Server operating system, services and other software patched | ||
| Anti malware (anti-virus), intrusion detection (IDS) and intrusion protection systems (IPS) enabled and updated | ||
| Launch configuration information set (e.g. IP address restrictions and exceptions, storage locations, SSL/TLS, session management settings, error handling, HTTP methods and headers, caching, robots exclusion, domain name(s), DNS, web server configuration, email addresses, authentication credentials for third party services, registry entries, firewall settings, alert recipients, security event detection settings, audit settings) | ||
| Logging, alerting and other monitoring facilities enabled (e.g. audit trail, intrusion detection, file system monitoring, third party services such as uptime, defacement/malware monitoring and other reputational monitoring) | ||
| URL aliasing and redirects configured | ||
| Access to the server(s) locked down (e.g. physical access, ports closed, IP address restrictions imposed, un-necessary accounts removed/disabled, passwords changed) | ||
| Registered site ownership with third-parties such as Google Webmaster Tools and Norton Safe Search | ||
| All resources registered in your own organisation's name (e.g. domain name registrars, SSL certificates, web hosting contracts, domain name service providers, agreements with partners and suppliers) |
Not all these checks will be needed for your project but the order in which they are done is important. For a small web site with little functionality, this doesn't have to be complicated. For example, the build documentation and disaster recovery plan could mean having a full set of source files (pages, scripts, images, etc), each night's full backup of any changing data (e.g. database and generated files), login credentials, some notes on the server's configuration and contact details for the domain name registrar, design agency and hosting company.
For any project, try to discuss launch as early as possible in its lifecycle—preferably at the bidding/tender stage, but if not, immediately on project initiation. Define the launch/release criteria well in advance. Find out what the client and project owner's expectations are and who will be responsible for what. A good launch takes time, so make sure the team have enough time to complete the launch and subsequent checks without it running into abnormal hours of the day. Your web site project's failings might not lead to people's deaths, but that doesn't mean sloppy configuration, launch and operation are acceptable. What standards do you have?
Please let me know if you think anything should be added to or altered in this launch checklist.
PS if you are looking for a launch checklist that addresses wider website issues, I'd recommend the The Ultimate Website Launch Checklist.
Posted on: 19 February 2010 at 10:23 hrs
Comments are filtered automatically and should appear shortly after they been checked.