To protect your Web site assets, you should do two things. First, get a list of all of your company's registered addresses. You may think that the only domains your company has registered are company.com, company.net, company.co.uk or other country-specific domains. But many departments create their own URLs for projects or may have consultants or ad agencies create URLs for them. If any of these are in production, you should add them to your list. If they're not, you should release them before someone implements a system using one of them. Second, you should change all of the administrative contacts and technical contacts associated with those domains, to individuals in your organisation. These may be the same staff members who are responsible for other technical services, like security or technical asset management. You may also consider setting up generic email addresses like AdminWeb@Company.com or TechWeb@Company.com. This gives you two advantages. First, the email addresses won't have to be changed if the person responsible for maintaining the domain leaves the company. Second, when (not if!) Web crawlers look for contact addresses for spam advertisements, they will pick these up and won't litter up anyone's day-tot-day mailbox. You can also set up custom filters and forwarding rules on the email addresses to get rid of the junk and forward important messages from the real registrar to someone in the organisation who can handle them. Protecting access to domains
Even if your servers are running, and you have clear rights to the domain names, that doesn't mean that everyone on the Internet can find them. Location is handled by a series of domain name service (DNS) servers housed on the Internet. When you first register a domain, you have to tell the registrar which DNS will handle location services. Unfortunately, many companies who chose local providers or data centres to provide these services have been surprised to find out that when the companies fail, the DNS gets turned off--cutting off access to customer sites. To guarantee continued access, you should update your DNS entries for each domain to include a DNS server from two different providers as primary and secondary servers. You may also consider running your own internal DNS server as the secondary server for all of your domains, and then using an external provider as the primary. This will provide continued access if the primary provider's servers are down, and will give you more control over the registration of new domains. Many companies run their public DNSs using a Linux box with one of the publicly available DNS servers, or a Microsoft Windows 2000 box using the built-in DNS. Securing your domains
Although using server and client certificates to secure all or part of your domain using a Secure Sockets Layer (SSL) connection doesn't pose a security issue, it can pose a financial one. Paying an external service to provide certificates makes sense for public Web sites where operators want to collect confidential information or sensitive financial data. But it may not be the most cost-effective solution for companies needing certificates to allow employees or trading partners to access their network. It often makes better financial sense to set up and maintain your own certificate server in that scenario. There are publicly available, Linux-based certificate servers, and Windows 2000 has its own built-in certificate server. As long as your trading partners accept your company as a certificate authority, you can issue your own certificates. This allows you to set up secure communications for Web sites or Web services between your company and the trading partner. Until there is an industry standard for authentication, it's likely to be your company's best bet for allowing secure external access to your domains.
Have your say instantly, in the Tech Update forum.
For a weekly round-up of the enterprise IT news, sign up for the Tech Update newsletter.
Find out what's where in the new Tech Update with our Guided Tour.
Tell us what you think in the Mailroom.
