|
The following is a basic guideline for web security. Keep in mind that
there are specifics that are not addressed here:
 | What hardware and operating system are you working with? There are
specifics for each platform. |
| What applications and software are you running? |
| Who is involved and what is their level of expertise? |
Risk Assessment
| Identify the specific nature of what happens if your system is
compromised? |
| What is the risk to your organization or to those whose data you have? |
| What are the legal liabilities if someone steals your data? |
| How long will it take to restore everything if the system is taken down? |
| What types of attacks are you subject to:
 | Virus, worms, etc. via classic invasion (e-mail, software installation,
Trojan Horse via active documents). |
| Denial of service (e.g., overwhelming the site with hits to keep others
out). |
| Invasive take-over attack - e.g., remotely accessing the site and
triggering programs. |
| Virus, worms, and other software via Internet invasion (backdoor access,
etc.). |
|
| What is the impact of an attack (assuming worst case):
| Your "static" website is taken down (i.e., the site cannot
be accessed by target users after the attack) -- this a relatively minimal
risk. |
| Information on your site (e.g. a database of questions and answers for
your products) is stolen (minimal risk unless the information if
proprietary). |
| Operational capability is taken down - how much business will you lose
depending on time to restore - typical of denial of "service attacks"? |
| User and financial data (with privacy considerations) is stolen.
This includes names, addresses, contact information, personal data, credit
cards, accounts payable/receivable information, etc.. |
|
| Bottom line: how badly will I get hurt if the system is taken offline
or data is stolen? |
Procedural Security
| Do you have documented procedures for protecting your systems? |
| Documentation includes:
| A detailed risk assessment (see above). |
| What is being protected. |
| Who is responsible (administrators, end users, etc.) and
expectations for these individuals. |
| Where things are kept including:
 | Hardware |
| Software |
| Data and backups |
| Passwords, access codes, combinations, etc. |
| Also: who has control and access to these things. |
|
| When things are done, including:
| Data backups |
| Inspections are completed. |
| Passwords are changed. |
| Procedures in general are reviewed. |
|
| How things are done, including:
| Data backups (number of copies, where they go, who has access) |
| Password assignments and monitoring |
| Log files reviewed. |
| Testing of the system |
| Procedures for installing and testing new software |
|
|
| Documentation should be reviewed periodically (at least annually). |
| Everyone should be familiar with the documentation (it doesn't do any good
if people don't read it). |
Physical Security
| Where are the computers and data and how secure are they? |
| Who has access? |
| Is backup power available? |
| Are data backup systems removable and controlled. |
| Are environmental systems adequate, including:
| Cooling |
| Clean area (e.g., no dust, dirt, bugs, rodents, etc.) |
| Fire suppression systems (preferably halon) |
|
Administrative Security
| Administrators and users who have access to the system. |
| All operating system updates and security patches should be reviewed and
installed. |
| Monitor industry resources (hardware, software vendors, research
companies) for latest information on:
| Hacking techniques |
| New viruses and worms |
| Application vulnerabilities |
|
| All system and user passwords should be unique and changed periodically. |
| All passwords and access should be reviewed when there is significant
change in personnel (e.g., when employees are fired or have undergone
significant events including legal/criminal investigations). |
| People should only have access if there is a need. |
| Verify all user accounts:
| Read access should be the standard on a general basis. |
| Write and execute privileges should only be granted when necessary. |
|
| If directory level security is used (e.g., end users have accounts via
LDAP, etc.) - periodically review all accounts:
| If account is no longer being used, get rid of it. |
| Change passwords periodically (6-12 months). |
| Spot check, if possible, and make sure the right person is using this
account (hard to do, but worth it). |
|
| Monitor application user accounts (e.g., Internet users, database servers,
etc.) - make sure they have only the access permissions they need. |
| Turn on logging and review web and computer server logs on a periodic
basis:
| Look for repeating patterns; e.g., the same IP address hitting the
server many times in a short period of time (may be trying to breach a
password or implementing a denial of service). |
| Page accesses - how often and when certain pages, applications, and or
the server has the greatest traffic. |
| Check password log files for repeated/failed attempts. |
|
Data/Database Security
| Separate databases whenever possible from network and web servers. |
| Perform backups as often as possible; on web servers, use slow periods
(e.g., middle of the night on Saturday/Sunday) if the system must be taken
offline. |
| Store database backups offsite in secure facilities (safes, safety deposit
boxes) at a reasonable distance from primary facility. |
| If using a local database on the web server or in a web accessible server,
minimize the amount of vulnerable data by:
| Only capturing data that you need. |
| Removing data when no longer needed; e.g., remove credit card numbers
after the purchase is validated. |
| Off-loading data periodically that is no longer needed or used (e.g.,
customer names and addresses). |
|
| Treat external data sets (e.g., via XML) the same way as the database;
consider the fact that XML is easily readable. |
| Use passwords on databases to protect information. |
Application Security
| Limit FTP access to strictly controlled actions:
| Anonymous access in specific directories only; make sure everyone is
aware of what these directories are. Make sure these directories are
READ only. |
| Controlled access should ideally be made to directories with no script
or executable access (not always practical but should be considered as a
control mechanism). |
|
| Avoid script and executables unless needed; remove extraneous scripts and
programs that are not needed. |
| Set session timeouts to the minimum amount of time required or expected of
end users. |
| Use file uploading capabilities carefully - make sure data is loaded into
passive (read only) directories. Monitor these files for viruses, worms,
and other invasive programs. |
| Never store sensitive data (e.g., financial or personal data) in hidden
fields. |
| Never store sensitive data in cookies on a machine (even short term or
transparent cookies). |
| When possible, avoid write/executable situations except as needed and only
in isolated directories. |
| If using application-controlled access via a username and password or
other control, apply the same considerations as administrative security:
| Change passwords periodically. |
| Monitor users - remove from password lists as necessary. |
|
| Check application code and execution for remote access, for example:
| Remotely running any applications on the server through the web
application. |
| Remotely running parts of the web application out of sequence. |
| Running database queries/actions through the application. |
|
| Use SSL or other secure communications to handle sensitive or confidential
information (e.g., credit card information, personal financial information,
etc.). |
| If using SSL, make sure all certificates are up to date; and all server
security related patches are installed. |
| If using ActiveX or other "trusted" objects, make sure all certificates
are up to date. |
| Test all server and client application code -- consider the following
possibilities:
- Can the application be turned against the server.
- Can a client application (e.g., a Java applet) create havoc on the
client machine.
- Can someone replace a client application on the server.
|
| Publish legal and perceived liability notices on the web site (it may not
all hold up in court - but it's a place to start). |
|