-----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-----