What are the most relevant 10 questions you need to ask a potential web developer before signing on the dotted line?

Network News outlines the questions, and a guide to the answer you should be seeking.1. Do you have a security policy?
It is vital that you ask questions about the security policy when you have a website developed. A security policy, which you should be able to examine, shows that the developer has thought carefully about the security of your site.

In addition, a security policy will lay out the steps to take in the event of a security breach. Without a proper disaster recovery plan, you can't be sure how long it will take to get back online or that the same kind of breach won't occur again.

A security policy gives you a benchmark to compare the service against. If a failure to enforce any part of the policy adversely affects your site, there are grounds for a serious complaint.

The final element to take into account is coding guidelines for the designers. Programmers are often not security-savvy. Their job is to create the site as efficiently as possible. It's important for web design companies to realise this and get programming guidelines written by security experts. These guidelines should then be followed by the programmers to ensure the safety of the site.

Make sure that you ask for a copy of these documents, so that you can be sure that all bases have been covered.

2. How are the servers set up?
Server installation is one of the most important parts of web hosting. While many systems may be easy to install and get running, they are not secure straight out of the box.

Default settings often leave systems open to well-publicised cracker attacks, while failing to apply the latest patches is also a cardinal sin.

For these reasons it is important to make sure that the web developer has thought of server deployment. You'll want to know what web server and version your site will run on.

Next, find out what the company does to the default installation. For example, does it disable internet printing in IIS? Does it change the default script directory?

Although you may be satisfied about the initial setup, it's important to remember that security isn't complete in a single hit. It is a continuous process and you need to be sure that the web developers will keep on top of it.

Ask them about the patching schedule. You need to know that the servers are looked at and updated regularly. In addition, you need to know that if a major vulnerability is released, the servers will be updated quickly.

Finally, ask about server logging, which is useful for tracking and dealing with cracker attempts.

3. What's the physical security like?
It's easy to think of security as firewalls, but not all attacks are performed remotely. The local physical setup needs to be taken into account, especially if you're storing important data.

You need to make sure that the web developer takes this seriously. Find out where your server and data will be stored. Make sure it's in a locked, air-conditioned room.

Only a select group of people should have physical access to any servers. It's no good if everyone can walk up to the machine.

Other more obvious aspects should be taken into account. Is there security on site? Are there any burglar alarms?

Aside from the room and building, consider the security of the hardware. How are the machines secured? It's worth finding out if security kits are used to anchor kit to the racks and whether the racks are lockable.

Find out how the machines are controlled. If it's a keyboard and mouse, then chances are that more people have access to your machine than necessary. If a KVM switch is used, there's less need for operators to get physical access to the machine.

Look into the web developer's security tracking. Serial numbers can be attached to machines that allow police to trace the owner in the event that they are stolen.

4.How is data moved and stored?
Data is ultimately the most valuable thing on any web site, so you need to make sure that it's being treated with the proper respect.

Start by asking your web developers how they plan to transport data around the site. Every time an update is performed on a site, private information has to be moved around. Make sure that they use a secure method of uploading files to the site.

It's important to ensure that some form of encryption is used when customers connect to your site. You have a responsibility for the safety of any data that they enter, and so does the web site manufacturer.

It's also good policy to make sure that too much data is not being stored on the site.

For example, the most efficient way to handle customer credit card transactions is to perform them in real time because then you don't need to store the card details on the site.

Finally, find out the infrastructure used. If you're using a back-end database, how does the web server connect to it?

Ideally, this needs to be secure as well. We'd suggest making sure that default accounts aren't used. There are a lot of sites using SQL Server and the SA administrator account, which doesn't make a site very secure.

5. What's the backup strategy?
A backup strategy is often ignored or consigned to a last minute decision. Both these choices are wrong. You need to make sure that your web developer will take backup issues seriously.

Find out what the backup schedule is. If you're storing critical data, then you'll want to make sure that it's backed up daily. The backup schedule should also include information on the type of backup being made, such as how often incremental backups are made, and how often full backups are made.

Make sure that tapes used for backups are cycled in use. A grandfather, father, son procedure is commonplace.

It's vital not to store all backups locally. Some should be stored at secure off-site locations. Remember, if there's a fire, your backups will also go up in smoke if they're on-site. Make sure that the offsite storage is secure. If tapes can be accessed, then the data could fall into the wrong hands.

Ask the developers for full details on their backup strategy, as you need to know that it's realistic for your needs. If you're running a round-the-clock operation, then a backup plan that needs servers to be powered down is no good.

Equally, ensure there's a plan for recovering data in the event of a disaster. Backups aren't just about putting data on tapes; it's the whole picture that's important.

6. How are the scripts written?
Scripts will be used to create large portions of your site, such as data entry screens. And while they can give your pages an attractive, customised feel, badly written scripts are a danger to your site and your customers.

Ask your web developer which scripting language he or she is proposing to use and get a justification for the choice. Next, find out how the scripts are developed.

Make sure there are strict coding rules and they are strictly enforced. Guidelines should include security aspects that are written by experts who understand the issues involved.

For example, if scripts are badly coded and don't properly check data input, then a simple search engine can be used to display the password file.

Scripts will often access data stored in a database, but this can be dangerous. Find out where the database password is kept. If it's in the script, then there's scope for a cracker to pull it out and directly access database data.Even if the password is to be stored in a script, make sure that it's not the administrator log-in and password. Too many sites have come to rue their reliance on SQL Server with the 'sa' account and password.

7. How are transactions processed?
For a lot of web sites, the whole point is to sell goods and services to customers. While this is all well and good in theory, sensitive data, such as credit card numbers, need to be kept firmly away from the eyes of crackers.It is vital that your web site developer understands this and builds the site with this potential problem in mind. First, find out from the developer how the site will handle credit card requests.

Ideally, it's best if the web site can perform real-time transactions, as this solves the problem of having to store credit card numbers. If card numbers do need to be stored, perhaps for return customer visits, then make sure that the data is stored securely. A text file in the root of the web server is not good enough; a database is a much better idea.

With any online commerce site, the shopping basket application is very popular, but often known to contain flaws. Make sure that the developer is aware of the potential problems.

Find out what kind of software is used and how resilient it is. Customers will often leave a site with a full basket, so what happens when they do? Get the developer to explain why its application is secure, and ensure it supports full transaction processing for fault tolerance.

8. How is email used?
Email is far and away the communication tool of preference of the online world. For a web site email makes perfect sense, as responses, order information and monthly newsletters can be automated. But with the technology come dangers.

By its nature, email is not a terribly secure method of communication. The developer that you hire needs to be aware of the problems and construct the site accordingly.

The most important aspect is the use of email in the sending of confidential information. Generally speaking, emails should not include any confidential content such as credit card details, usernames and passwords.

Instead, email should be used to link to an encrypted log-in. Information should not be displayed until authentication has been performed.

This should start with the creation of new user accounts. Instead of emailing out information, a secure web page can be used to summarise the account information: username and password.

Users should then be warned to take note, as they will only be emailed a link that will enable the account. This provides data security and verifies that the email address given was the correct one.

9. What part do firewalls play?
Firewalls are one of the most important security products that you can buy. Like a border guard, their job is to check all incoming and outgoing traffic and turn illegals back.

The web developer has to appreciate the importance of this and secure access to web servers. Make sure that the developer knows exactly which services need to run. That way only the relevant ports need to be opened on the firewall.

All other access should be blocked off, as this will cut down the number of routes into the network.

The internal network should not be ignored. Most attacks will come from inside your building, so your web servers should be firewalled from this as well.

If you are using databases at the back of the system, it would be sensible to firewall these as well. Ask the developer how it does this. A good tactic would be to allow only the web servers through the firewall to the database.

This has the added advantage of forcing crackers to break through another firewall if they manage to get on the web server.

Finally, make sure that the developer doesn't think that firewalls are the only security measure to take. They're just one component in a reliable security infrastructure.

10. Are security audits performed on a regular basis?
Security is never accomplished in one sitting, it's a rolling process. A key part of this is performing security audits.

Because crackers are constantly looking at systems and finding new ways of breaking them, it is essential to try and keep one step ahead of the game.

From a hosting perspective, this means ensuring that rigorous tests are performed at set intervals. This may involve an onboard security team with scanning tools, but could also include external companies performing a penetration test on the network.

You have to make sure that there is a sensible security policy in place. The key thing to remember is that a large number of attacks come from script kiddies. Regular security audits should highlight common flaws in the system and help lock the kiddies out.

But security audits aren't just designed to probe for vulnerabilities. Servers should be checked for suspicious items, such as new accounts. This would be a sign that the machine had been breached.

With this method, it's important to know what happens after the security audit. Ideally, you want a fast reaction time. There's no point in discovering vulnerabilities in this fashion and just generating flashy reports.

Questions supplied by Malcolm McIlhagga of Sigmer Technologies
Comment on this article