-----BEGIN PGP SIGNED MESSAGE----- Author : Peter StJF Bance Project: Secure Web Hosting for Client X Date : 04 May 2001 Background: during extensive discussions with the Client, the Author explained that there is _no_ 100% secure Web server. However, this was not acceptable to the Client, and so the Author was charged with the task of finding a solution. After much investigation, it turned out that there are two potential answers to this difficult problem. This document presents these proposals in detail, and it is left to the Client to select which is preferable. Every effort has been taken to keep this document brief, and layman's terms are used wherever possible. However, the technical nature of the project means that some technical terminology is inevitable. Client Requirement: Our Web Server must be 100% secure. Any less, even 99.999%, is unacceptable. In the event of any security-related problems or events in the near, distant or unimaginable future, we would hold you, our Security Consultant, ultimately liable for any damages or embarrassment caused, whether you are still working with us or not. Proposal 1 - Ten-step plan to securing the Web Server ===================================================== 1. Perform the standard 'Server Hardening' procedure developed by the Author during his time in the industry, drawing upon the combined experience of: - Other experts - Internet Authorities - Commercial security specialists - Miscellaneous other sources of best-practise in the Network Security arena Note - this process will not achieve 100% security. See the following steps. 2. For content to be updated on the server, there must be a way for authorised personnel to make file changes. This represents a security risk if achieved through FTP, SSH, remote-control software, etc. Hence, the next step is to remove all remote update mechanisms. Authorised content editors and/or the Webmaster will then be required to visit the server and place content on it manually. For the purposes of this proposal, and in an attempt to reduce the size of this document, the possibility of Virus or Trojan infection has been ignored, but should be considered when update processes are implemented. 3. The server is still susceptible to attacks brought about through lax physical security. Hence, implement strong processes for gaining physical access to the server - this must include _all_ of the following for maximum effect: - Passphrase required for entrance to hosting facility - Passcode required for entrance to hosting facility - Photocard required for entrance to hosting facility - Biometric authentication required at hosting facility (retinal scan, thumbprint and voiceprint analysis) - Digitally-signed authorisation required prior to visiting hosting facility 4. The server is still susceptible to 'social engineering' attacks by malicious individuals contacting the ISP, the hosting facility, the Webmaster or even the content editors and masquerading as someone authorised to handle passwords and other security protocols. To deal with this threat, the following safeguards must _all_ be implemented: - Fully educate all authenticated users of the system in the workings of social engineering attacks - Content Editors should not be permitted to update the server directly - hence, they will not need to be given a User ID and/or password, so there is nothing for them to give to an attacker - Reduce the number of authorised personnel to 1 (one) to minimise the leak potential - that user must be fully trained in all aspects of Network Security, and must be capable of accurately predicting future trends in hacking technology and techniques 5. Since the future must also be considered, there is still the possibility, albeit fairly remote, of phone-line tapping, room-bugging, brain-washing, use of truth serum, plastic surgery, invisibility potions, astral projection, etc. Therefore, the server is not yet 100% physically secure. Hence, to secure this potential breach, the following action must be taken: - Nobody, including the ISP, should be allowed access to the hosting facility - Any server IDs and passwords should be randomly generated by the server itself and not given to anyone - The server must be surrounded by a sealed lead box, and this box must then be filled with concrete Note: This step can be implemented independently of the preceding ones. 6. The above steps assure _physical_ security as far as possible given known technology. The next aspect that needs to be addressed is network security. The largest potential hole in the system is that it will be running a Web server daemon. This must be removed. 7. The server is still not 100% secure, as there is a network connection to it, and future exploits may be found and used whatever the operating system in use. Hence, the network must be disconnected. 8. Technology is moving rapidly, and it is not outside the realms of possibility that wireless (radio, laser, microwave, etc.) means to access a server could be developed. Therefore, the only sure protection is to switch the server off. 9. The server is almost secure. However, the concrete and lead may not be effective in the future - even now, corrosives exist which could defeat this measure. Hence (and this action can be taken immediately whether previous steps have been performed or not), the server must be removed from the hosting facility and dismantled. 10. Finally, to ensure the security of the data on the server and to protect any accidental exposure of information regarding its configuration, the individual components must be crushed, ground to a fine powder, melted down and buried as close to the Earth's core as possible. Note that even after following the above steps, future research may find a way to extract a 'memory' of an object from materials that have ever been in contact with it, or perhaps even to rebuild an object that used to exist given one or more atoms from its remains. Proposal 2 (see below) does not have this limitation, can be implemented far more rapidly, and will cost considerably less. Proposal 2 - One-step plan to securing the Web Server ===================================================== 1. Don't implement a Web Server until you have a clue. The minimum requirements for being categorised as 'having a clue' are that you are in possession of a fully-working combination of ears, brain and short-term memory, all of which must be owned by a single individual. That individual must be alive. Failing this, the Author can recommend several 4-year-olds that would be happy and more than able to assist. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQIVAwUBOvK6Rb4wsfF3G+5LAQEIcQ//Z6CAueEwGiGGcJfjHbrZHeFpXOFKhv6i pNPOGUXvVFPC05pncsYUxwIn20W5EOtphWh1GS2Eq1nHYN+K3WW/Z0YCVrfKFQrU qHHjtR1ZeNOfo5omF6A3oR5knzanMlr8O4qfqyRmov3PgOfnZJGFArMwpJgtDLL3 iETC4H0t69F89W3QK1sizcG5fyUhS4rEXH2085cMValzwxFOQYYuRfT3wy8tynkJ LDg4Plse0mpT+tWJzvcX2hEPfsSvVhZgI+nbUmoSfWk2GEsxf3FGpIY6ACPTl7o1 msRE1bF6kqtEsq9NY0rYMkzNOW1hNYrJosquO8TAPTRkeAOFRyVvP+2wdvUEAEFP tFp2flxB+trgmb0C0bmW5dgbE7pJSsEcW8twJc9H7wPt49BnNHXEHXrvTLd16nHM sH1fdhxZVhceDw8mr/a6A/xIIj5lA8gKbWRVVRHicsAXqvcRA4d3iUAkYQcR7U5c 52BEdK6QuUxrR7pu0lvvjDw6rvyLMNXW8CSug6dd1C/bdFjXnvlZjrvl3HuIqBNY TtDxMElJ3xRTOWrtVEbmqDM/Q99Nv/C8FoHltNXJslFQprPuzlkOzxBz6AkxUxUu dZjWYIekOrrc6oT6YBTYLngy7mldyWepJJzSyiFyblq1vbkMYd/QaaccwBg3vuST M0e5a/nWOVI= =xeix -----END PGP SIGNATURE-----