The Case For Best Practices: Why Technology Alone Falls Short

An ounce of prevention…

Each new attack on the worldwide infrastructure refocuses our attention on information security. It seems that with each incident, new claims from vendors regarding the extent to which their technology is impervious follows closely. Equally abundant are the products and services offered to combat the threat, many with scare tactics attached.

Of course, many of the vendors’ claim their efforts, products and services have merit, but they are only part of the solution. It is impossible to assume that any combination of measures will provide perfect protection; such is a claim that should be met with immediate skepticism. However, it is a very attainable goal to ensure your infrastructure is a harder target to hit, and hence much less likely to fall victim to blanket attacks. The key to attaining this goal is to treat vendor measures and additional security-related products and services on a much larger scale.

The following steps can be employed in many different areas. Corporate email, firewall deployment, anti-virus protection, local user account security, file and directory access are among the important areas in which you should pair best practices with technology. So what best practices should you be using? Below are the TOP 12 Best Practices to institute in your company.

*This list focuses on IIS and web-related security. It is in approximate order of

Importance and technical depth, which was tough to balance.


  1. Upgrade NT or 2000 to the latest service pack and examine the security bulletins and related patches.
  2. Microsoft TechNet provides a Security Bulletin Search, the ability to sign up for future security bulletins as well as the ability to search for the patches you need based on the Product and Service Pack a company is running. The following link gives more complete details:

  3. Review Microsoft's Security Checklist.
  4. This link outlines some of the steps that should be taken to secure a Windows2000 Server that is running IIS 5.0 on the Internet. It goes through 5 steps: general information, background work, IIS 5.0 Settings, and the necessary steps to install scanner/intrusion Software. The following link gives more complete details:

  5. Be sure your companies web administrators and developers are familiar with the necessary security measures.
  6. Microsoft provides a 9-page document on "Authentication and Security for Internet Developers". This article explains Windows NT security as it relates to IIS, so security-related problems trouble-shooting can be happen effectively. The article covers three forms of authentication, how they differ, several ways of controlling access to key areas on a Web Server, and the important but almost universally misunderstood concept of "delegation". Understanding delegation is mandatory for anyone building a data-driven Web site using IIS. Understanding how Windows NT handles different users will save potentially days, or even weeks of troubleshooting. The following link gives more complete details:

  7. Vary the start page
  8. Default.htm, default.asp, and so forth are prime targets. Pnc_start.asp is a great example. That stands for "private naming convention start asp." Of course, I just made that up. That's the point. The Code Red attack replaced the predictable files (prime targets), but completely missed the varied names.

  9. Move INETPUB to a drive different from non-web-related files (like system commands).
  10. Preferably, this drive would include only INETPUB and related files. System files, logs, and data files (databases, etc.) should not be on the same drive, even if they are on the same machine. The end game here is that Code Red is a "malformed URL" attack, which uses a tactic confuse the web server that is very much dependent on the critical and dangerous files being in a predictable location. Moving them confuses the attacker right back.

  11. Survey the web sites and applications configured in IIS for dangerous directory mappings.
  12. Those that map to shares on other computers or paths outside the web server realm might need special attention (for instance, many might map to paths under \WINNT\SYSTEM32, which should be very carefully secured).

  13. Thoroughly investigate the .cmd .bat .exe and .dll files that are within the reach of the web server.
  14. Include the directories per the previous item. Consider the misuse of these files. For instance, perl.exe is routinely placed in reach of the web server so scripts can be run. However, perl.exe can be used to run arbitrary commands as well, so this setup works but is not at all secure. Code Red copied a command processor (cmd.exe) from its normal location to a spot within the reach of the web server, which it did to ensure easier future attacks. It copied it as "root.exe" which should have raised red flags just because it was a .exe file within the reach of the web server. For situations like perl.exe, application mappings are a better alternative. (See the next item)

  15. Check the file type / application mappings in IIS
  16. Under the server or application's Properties, Home Directory, Configuration, this will show which other file extensions will cause IIS to run another program to process the file.

  17. In MTS (NT) or Component Services (2000), investigate the Identity of IIS packages
  18. The names of these Packages/COM+ Applications start with IIS. Specifically note the information in their Properties page, on their "Identity" tab. Much emphasis is given to the IUSR_<computername> account, which is the identity assumed by all anonymous connections. Web sites that are not anonymous assume the identity of the user that logs in, which you would assume, is the basis for security in those cases. However, any site, anonymous or not, that uses a COM package (which is the majority of the major ones, since this is Microsoft's prime web architecture) can be configured to run the objects under a specific user context. Refer to Microsoft's knowledge base articles if you have COM objects that are used, but don't seem to be in a package (as they actually are, you just need to identify which one). The user contexts specified under "Identity" are many times off everyone's radarscope.

  19. Be certain the file system on which the web server resides is NTFS. Set the NTFS permissions accordingly.
  20. Use the previous items as a discovery process that will provide a better understanding of the identities involved in web transactions and where they need access.

  21. If there are critical Web servers that are visited only by a hyperlink, investigate varying the SSL and non-SSL port.
  22. For instance, if the users link to (which no one ever types directly), 82/appstart.asp will probably work fine. This is another tactic that will thwart blanket attacks.

  23. Where possible, set a server-wide or site-wide policy for SSL and authentication to its most restrictive.

For instance, some servers’ host sites that require users to log in to do anything, yet they are still configured to accept anonymous connections via many paths. Turning this off at the server level will require a username and password for ANY request of the server. The same is true for SSL. Many servers accept the first non-SSL request (http) only to immediately redirect to the secure version of the site (https). Investigate your web application environment; in many cases these practices can be followed. The end game here is that blanket attacks will not attempt to connect via SSL and will certainly be unable to present a request if everything requires credentials. The non-SSL, anonymous requests, when fielded by the web server, is a playground. Unfortunately, this item is much more difficult for public sites, but the concept can still be applied.


Seventeen years ago, Vincent J. DiPippo, FOCUS24’s Executive Vice President of Technology and infrastructure produced his first commercial software product at fourteen years old.

In January of 1997, Mr. DiPippo joined SYTEX Systems Corporation, (now FOCUS24), as director of Technology. As the leader of SYTEX’s technical resources, Mr. DiPippo established himself with the company and its clients as a definitive resource for network and systems expertise. Mr. DiPippo founded relationships with Computer Associates, Silicon Graphics, International Business Machines, Cisco Systems, 3Com, and Microsoft. Mr. DiPippo is a 3Com Wizard, a Certified Silicon Graphics Unix Engineer, a Microsoft Certified Systems Engineer, and a Certified Unicenter Engineer.

Earlier as a consultant, Mr. DiPippo developed IAN, the Integrated Alarm Network, which monitors and organizes alarm telemetry received from fire alarm monitoring equipment. IAN is currently in use in municipalities such as Cumberland, RI.

In 1994, Mr. DiPippo accepted a position with RESPONSE Healthcare Information Management (East Greenwich, RI). There, he served as the principle software engineer for The Starting Line: System for Outcomes Measurement, an outcomes data collection and measurement. A system based on the analysis algorithms developed at the New England Medical Center and documented in the Journal of the American Medical Association and the New England Journal of Medicine. At RESPONSE, Mr. DiPippo was well recognized as the most efficient, effective, and creative engineer in the company and was tasked with the internal training of software engineers. RESPONSE later received venture capital investments and was then purchased by HCIA. Mr. DiPippo was called upon frequently to discuss the technology, philosophy, and engineering behind The Starting Line, a key factor in the venture capital and acquisition decisions.


Source: Vin Dipippo, Executive Vice President of Technology and Infrastructure at FOCUS24
Agency Contact: Shannon Beth Harrington North Star Marketing & Promotion
Phone: 401.294.0133
Fax: 401.294.9282