[InterSect Alliance]  

[InterSect Alliance]

[About Us]
[Services]
[Values]
[Staff]
[Projects]
[News]
[Contact]

INTERNET INFORMATION SERVER 4.0 SECURITY
Graded Security Configuration Document

Developed by Leigh Purdie and George Cora
Version 1.2
Version Date 28 March 2001
www.intersectalliance.com


This document provides a series of recommendations on the choices or grades of security installation that are possible, using Internet Information Server version 4 on Windows NT. This document is designed to work hand in hand with the Windows NT security configuration document, also available from the InterSect Alliance web site. Some of the settings may be dependant on the patch level and service pack version in use, and therefore differencies may exist between this document and the actual registry settings and values on your machine. Users are encouraged to notify Intersect Alliance of any errors or omissions.

The security configuration parameters that are graded according to arbitrary levels of PREMIUM , STANDARD or BASIC. These ratings are relative and should not be read in absolute terms. A number of security grades refer to a "risk assessment". It is strongly recommended that a security risk assessment be used to ensure that the most appropriate grade is chosen for a given production environment.

DISCLAIMER

CAUTION: The information contained in this document aims to provide assistance by identifying the security grades for the Internet Information Server. Implementing some of these suggestions may potentially break or disrupt performance on systems on which the modifications are made. The suggestions listed on this page may not be suitable for your environment. It is therefore recommended that you test all changes on a non-production system before applying them to a production environment. All modifications are made at your own risk. InterSect Alliance is not responsible for any damage that may result from applying these recommendations conatined in this document.


Table of Contents

1.0    Windows NT Installation Requirements


1.2    Security Alerts and Updates
1.3    Domain Membership and Trust
1.4    ODBC/OLE-DB Data Sources and Drivers
1.5    Minimal Internet Services


2.0    IIS Base Installation

2.1    Extra Root Certificates


3.0    Security Services

3.1    Components of a PKI
3.2    Practical Uses of a PKI in Electronic Business
3.3    Identification and Authentication
3.4    Privacy and Encryption, and Information Integrity

3.4.3    Server Encryption with Password Authentication
3.4.4    Client Certificates


1.0    Windows NT Installation Requirements

Follow the Windows NT security configuration document at a level as indicated by your security risk assessment. As a general guide, internal systems protected by a firewall, can generally be configured at the standard level, while systems on a demilitarized zone (DMZ) connected to the Internet or other public networks, are likely to require 'Premium'settings.

The following exceptions and additions to the Windows NT recommended security configuration document should also be applied:
 

1.1    Service Pack & Upgrades

The latest IIS service packs should be downloaded and installed for any new IIS installation. To date, IIS service packs have been included within the Windows NT service pack installation. As such, follow the directions within the Windows NT recommended security configuration relating to server upgrades.
Server upgrades over and above those provided by the service packs can be found from the following URL: http://www.microsoft.com/NTServer/all/downloads.asp
 
1.2    Security Alerts and Updates
The Microsoft security alerts will provide IIS and system administrators some indication as to the criticality of bugs in the IIS server, or underlying NT infrastructure, that significantly affect the security of the system. Access to the security alerts is via email, and users can subscribe by going to the following URL: http://www.microsoft.com/technet/security/notify.asp , and following the directions included therein.

Security Alerts
Premium
Subscribe to Microsoft Security Alerts
Standard
Subscribe to Microsoft Security Alerts if identified as a requirement in the security plan.
Basic
  
Table 1.2 Security Alerts and Updates
1.3    Domain Membership and Trust
Configuring a server that provides services to public networks as a primary or backup domain controller can introduce additional risk to any servers or workstations that trust the PDC/BDC infrastructure. In general, a server that makes services available to public networks like the Internet should not be configured as a PDC/BDC.

Domain Membership
Premium
Servers that supply services to public networks should not be configured as PDC or BDC
Standard
Servers that supply services to the internal organisational network may be configured as PDC or BDC subject to security plan recommendations.
Basic
  
Table 1.3 Domain Membership and Trust
 

1.4    ODBC/OLE-DB Data Sources and Drivers

Some sample applications install ODBC data sources for sample databases, while others may install unused ODBC/OLE-DB database drivers. It is prudent to remove any unwanted data sources and drivers using the ODBC Data Source Administrator tool.

ODBC/OLE-DB Data Sources and Drivers
Premium
  
Standard
Remove unwanted ODBC/OLE-DB data sources and drivers.
   Basic   
Table 1.4 ODBC/OLE-DB Data Sources and Drivers
 

1.5    Minimal Internet Services

As specified in the NT Security configuration document, it is generally considered good practice to reduce the number of entry points into a server. Disable unneeded services using the Service Configuration Manager.
The following services must be running to use all IIS capabilities. However, only a subset of these services will be required in a normal IIS installation.
  • Event  Log
  • License  Logging Service
  • Windows  NTLM Security Support Provider
  • Remote  Procedure Call (RPC) Service
  • Windows  NT Server or Windows NT Workstation
  • IIS  Admin Service
  • MSDTC
  • World  Wide Web Publishing Service
  • Protected  Storage
Minimal Internet Services
Premium
  
Standard
As per NT Configuration document, remove all unneeded services from the system.
Basic
  
Table 1.5 Minimal Internet Services
2.0    IIS Base Installation
 
2.1    Extra Root Certificates
The IIS server implicitly trusts any certificates generated by root certificate authorities (CA's) that have been installed in the IIS CA list. If there are CA certificates installed that are not 'trusted, then it is recommended that they be removed. The process of removing CA certificates depends on the version of IIS, IE and Windows NT.
a. IIS4 + IE4 + Windows NT 4 + SP4 or better
In this scenario, all root CA certificates are handled by schannel.dll, which stores its data in the registry. There will be a series of registry keys under the following "CertificationAuthorities" key, one for each preinstalled CA. Each CA key has an "Enabled" entry under it, set to 0x1 if the CA is trusted and 0x0 if the CA is not trusted.
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Control\Security\Providers\SCHANNEL\
Name: CertificationAuthorities
Type: REG_DWORD
Value: 0
Note: Do not delete these registry entries, as Schannel will notice that they're missing and recreate them.


b. IIS4 + IE5 + Windows NT 4 + SP4 or better

For this scenario, perform the steps noted above and modify trusted root certificates in IE5:
- Open IE5


- Select Tools | Internet Options
- Click on the Content tab
- Click on the Certificates button
- Click on the Trusted Root Certification Authorities tab
- Remove any untrusted root certificates

Stop and start IIS:
- net stop iisadmin /y
- net start w3svc
Ancilliary Root Certificates
Premium
  
Standard
Remove all certification authorities for which you do not intend to install certificates.
Basic
  
Table 2.1 Extra Root Certificates

2.2    HTW Mapping

The .htw extension enables a series of functions on the IIS server, such as the webhits.dllpage counter. Unfortunately, many of these functions contain known exploitable vulnerabilities that allow users to browse protected source code for ASP scripts, amongst others.


To unmap the '.htw' extension for all functions, use the IIS Management Console.

HTW Mapping
Premium
  
Standard
 Remove mapping for .htw functions using the IIS Management Console.
Basic
  
Table 2.2 HTW Mapping

2.3    IIS Password Capability

The existence of the IISADMPWD virtual directory generally implies the ability to reset Windows NT passwords. This capability and should not generally be used when alternatives are available.

IIS Password Reset
Premium
  
Standard
Remove the capability to change NT passwords via IIS
Basic
  
Table 2.3 IIS Password Capability

2.4    Unused Script Mappings

Unused script mappings should generally be removed. If the server does not require some or all script capabilities (eg: .ASP, .SHTML), then remove them from the IIS Management Console. Remove the mappings by opening Internet Services Manager then right-clicking the Web server | Properties | Master Properties | WWW Service | Edit | HomeDirectory | Configuration and remove these references:
 
If you don't use 
Remove this entry 
Web-based Password Reset 
.htr 
Internet Database Connector (new Web sites don't use this, they use ADO from Active Server Pages)
.idc 
Server-side includes 
.shtm, .stm, .shtml 
Unused Script Mapping
Premium
  
Standard
 Remove unused script mappings
Basic
  
Table 2.4 Unused Script Mappings

2.5    Remote Data Services

The IIS RDS capability contains known vulnerabilities. When incorrectly configured, RDS can make a server vulnerable to denial of service and arbitrary code execution attacks.
It should either be removed or restricted using ACLs. IIS logs will reveal if users have attempted to exploit this feature  the log will take the format:
1999-10-24 20:38:12 - POST /msadc/msadcs.dll ...
Remote Data Services
Premium
  
Standard
Disable Remote Data Services
Basic
Restrict RDS to authenticated and authorised administrators ONLY
Table 2.5 Remote Data Services

2.6    Parent Paths

ParentPaths allows the ''..'' function in file or directory access functions within application code. Beware that if programmers have used ''..'' in their scripts, disabling this capability may cause problems. To disable this option go to the root of the Web site in question, right click select Properties | Home Directory | Configuration | App Options and uncheck Enable Parent Paths.

Parent Paths
Premium
  
Standard
Disable Parent Paths
Basic
  
Table 2.6 Parent Paths

2.7    Command shell execution

The #exec facility can be used to call arbitrary commands from within a HTML document. IIS disables this function by default, but it can be verified by checking that the following key is set to zero, or has been removed completely:
Hive: HKEY_LOCAL_MACHINE\SYSTEM
Key: CurrentControlSet\Services\W3SVC\Parameters\
Name: SSIEnableCmdDirective
Type: REG_DWORD
Value: 0
Command Shell
Premium
  
Standard
Verify that Command shell execution is disabled.
Basic
  
Table 2.7 Command shell execution

2.8    Directory Permissions

Unless it is intended to run either a FTP or SMTP mail server on the same machine as the IIS server, there are two directories which may need to have access controls set over and above the default settings:
  • c:\inetpub\ftproot (FTP server)
  • c:\inetpub\mailroot (SMTP server)
Both directories are set for Everyone (Full Control). In general, there are two major options available from a security perspective:
  • Lock down the access controls to remove access to these directories.
    • This will remove, or restrict, the capability to use the ftp and mail functionality.
  • Create a separate logical servers to handle the FTP / SMTP functions.
    • This will put some level of logical separation between the FTP/SMTP and HTTP servers.
Directory Permissions
Premium
Logically separate FTP / SMTP and IIS servers.
Standard
Lock down permissions on the identified directories unless such security impacts upon the functionality of the intended system.
Basic
  
Table 2.8 Directory Permissions

2.9    Certificate Server ASP Enrolment

By default the installed ASP pages for Certificate Server are not secured. Either remove the pages or set very limited ACLs on the pages. Certificate Server ASP pages are located in the %systemroot%/certsrv directory.

Certificate Server Enrolment
Premium
  
Standard
Set the Certificate Server ASP ACLs to:
  • Administrators (Full Control) 
  • Certificate Issuers (Full Control) 
  • SYSTEM (Full Control) 
Once the ACLs have been applied, add trusted certificate operators to the Certificate Issuers group if appropriate.
Basic
  
Table 2.9 Certificate Server ASP Enrolment

2.10    Sample Applications

The sample applications contain known exploitable bugs, and should not be installed on a production system. This includes documentation (the SDK docs include sample code), the Exploration Air sample site and others. Here are the default locations for some of the samples.
 
Technology 
Location 
IIS 
c:\inetpub\iissamples 
IIS SDK 
c:\inetpub\iissamples\sdk 
Admin Scripts 
c:\inetpub\AdminScripts 
Data access 
c:\Program Files\Common Files\System\msadc\Samples 
Sample Applications
Premium
  
Standard
Remove all sample applications.
Basic
  
Table 2.10 Sample Applications

2.11    COM Components

As identified in the NT recommended security configuration document, disable or remove all unneeded COM components. Many COM components are not required for particular installs of IIS, and should be removed. Most notably consider disabling the File System Object component, however, this will also remove the Dictionary object. (Be aware that some programs may require components. For example, Site Server 3.0 uses the File System Object.)


The following will disable the File System Object: regsvr32 scrrun.dll /

COM Components
Premium
  
Standard
Remove unneeded COM components.
Basic
  
Table 2.11 COM Components

2.12    Log File Access Controls

Access to the IIS log files could allow a potential attacker to determine information relating to the installation and configuration of the IIS server. Appropriate IIS log file access controls should be implemented if appropriate. The log files are generally located at: %systemroot%\system32\LogFiles

Log File Access Controls
Premium
  
Standard
Set access controls on the Log directory as follows:
  • Administrators (Full Control)
  • System (Full Control)
  • Creator/Owner (Full Control) 
Basic
  
Table 2.12 Log File Access Controls

2.13    Content-Location

The content-location header contains an IP address that may expose internal IP addresses that may be hidden or masked behind the organisational firewall / gateway if network address translation is used.

Content-Location
Premium
  
Standard
Remove IP addresses from the content-location field within the IIS management console.
Basic
  
Table 2.13 Content-Location
3.0    Security Services
The basic protocols that allow the Internet and its users to share information do not provide security functionality sufficient to conduct electronic business transactions without additional security controls. Security services must be provided in addition to the base grade "communications" services. The basic security services include:
Authentication
Authentication is the process of verifying that the parties involved in a business transaction are "who they are claiming to be". Obviously, each party's claims to an identity can only be verified by an independent and trusted third party. Any 'token' used in the authentication process that is trusted by both parties must be very difficult or impossible to reproduce. Once verified, authentication information can then be used to allow or deny individual or group access to particular resources.

Digital Signatures
Digital signatures are, in principle, very closely aligned with the 'real' signatures that are commonly encountered on traditional paper documents. However, a digital signature IS NOT a scanned image of a real signature. It is in fact, a large number, which mathematically represents the attached document, and provides cryptographic authentication of the signatory. Further discussions on how digital signatures function are outside the scope of this document. Nevertheless, digital signatures allow for an end user to verify that a document or any other piece of information has been sent by a particular user AND has not been altered between signing the document and delivery.

Encryption
The confidentiality of data transmitted via the Internet cannot be assured. Appropriate encryption technology significantly reduces the risk to data confidentiality. Encryption is the process of rendering traffic unreadable by using a data scrambling process that can only be reversed by using a secure token or key, chosen to be highly difficult to guess or determine. Encryption using a PKI can therefore provide an encrypted pipe or tunnel between two parties across an untrusted (or public) network, or can provide a method to encrypt information that can only be decrypted by a handful of agreed recipients.

Authentication token management
A critical component of providing the above services is the appropriate management of the tokens used to authenticate parties involved in the electronic business transaction. A Public Key Infrastructure generally provides a central location for users to access other users' authentication information in order to facilitate secure transmissions. By having a central trusted management point, some level of control over the validity of the authentication tokens can be maintained. If a situation occurs where there is a requirement to notify and revoke users in event of a compromise, the central management point will be able to facilitate this process.


3.1    Components of a PKI
The above functions of a PKI rely on different components that are discussed below. These components may or may not be required, and this will depend on how the PKI is employed. The key components of a PKI are discussed below.

Public/Private Key Pair.
These two keys are in fact large numbers that are mathematically linked. The public key can (and usually is) published openly, whereas a private key is held in strict secrecy by the owner of the key pair. Information encrypted with any one of the keys, can only be decrypted using the other key. A private key is used to decrypt information intended for the owner of the public key, but is also used to digitally sign documents. A private key is usually stored securely on a smartcard or within a user's home directory, and usually requires a password, PIN or passphrase to access.

Digital Certificate.
As mentioned in the previous paragraph, a public key is usually published openly, so that all relevant users may send the recipient encrypted information, and/or verify receipt of sensitive documents. A digital certificate is essentially a package of information which contains the user's identify, their public key, and most importantly, a verification from a trusted third party that the user as listed on the certificate has been validated as the actual person, server, organisation or entity. Note that a digital certificate can, and usually is, issued to organisations, or servers, as well as people. Digital certificates have a recommended expiry date, which should be checked by the application that uses the certificates. The date is set by the certification authority (see below), once the certificate is issued.

Certification Authority (CA)
The CA is the component that generates the public and private key pairs, and binds this pair to the entity (eg; user) that will appear on the certificate. Once the CA binds the key pair to the entity, the CA then 'stamps' the certificate with it's own digital signature, which ensures that the generated certificate cannot be tampered or altered in any way without being detected. The CA should be strictly controlled and maintained by a trusted entity, and in cases where a large number of certificates will be issued, it is usually recommended that the parent agency control and operate the CA.

Registration Authority (RA).
A RA is the collection of processes and methods used to validate the identity of the individuals or entities, before a certificate is bound to the entity. The function of the RA, therefore, is to ensure that the authenticity of the entity, so that the CA can then undertake the follow-up work and bind an entity with a certificate. A real-world example of an RA function is a certified Justice of the Peace. They can verify the authenticity of a document copy, which means that various government departments do not need to perform the same function.

Directory Server.
If there is a requirement for client authentication, or 'user to user' encryption facilities (eg: secure electronic mail), there needs to be a central location that makes a potential recipient's public keys available to information senders. This directory server also facilitates a central certificate management and revocation capability. A certificate issued to a user is usually granted for a set period of time; usually between 1 and 3 years, depending on the application. If a user certificate is compromised (ie; the private 'signing' key is lost or stolen), a user leaves the organisation and is no longer authorised to hold the certificate, or the issuing CA is compromised in some way, then the trust placed in the affected certificates will need to be revoked. The list of revoked certificates is placed on a Certificate Revocation List (CRL) on the central directory server, so that other entities that need to trust the CA or agency, are aware of those certificates that should no longer be trusted.


3.2    Practical Uses of a PKI in Electronic Business

The information below details three potential Public Key Infrastructure implementation models. These models provide a general overview of an application, the technical infrastructure of a PKI to support the model, and examples of how each of the models could be adapted to fulfil an electronic business requirement.

Protecting the confidentiality of information between a user and a web site.
In this model, a user will wish to interact with a web site, whilst ensuring that the traffic between the user and the web site remains secured against unauthorised access by a third party. In this instance, it is not important that a user be authenticated, or that the integrity of the information be maintained. However, communication between the user and web site should remain confidential. In this model, the most suitable solution involves the use of 'server side certificates', and an encrypted 'tunnel' between the user and the web site. The encrypted tunnel is established using an established, and popular protocol, namely the Secure Sockets Layer (SSL). The small quantities of 'server side certificates' are likely to be acquired from a commercial vendor. This model is currently in use in a number of electronic business solutions including:
  • Use of SSL to protect userid/passwords for web based mail applications (eg Hotmail, Bigpond). In these instances, the secure tunnel is only established for the duration of the login process (watch for the locked padlock icon at the bottom of Internet Explorer, or the bottom left hand corner of Netscape Navigator).
  • Use of SSL to protect Internet Banking (eg; Commonwealth Bank Netbank, St George Bank, Colonial Mutual, etc). Unlike the above application, all transactions are protected even though a userid/password is used to authenticate individual users.
Protecting the integrity of information between a user and a web site, or via one way email exchange.
In this model, a user will only be concerned with the fact that information received has not been tampered or altered by unauthorised staff. The risk that a third party may be able to read or view the information will be of either little or no consequence, and will therefore not be a factor in this Ebusiness model. In this instance, the digital signature is a mathematical relationship created from both a digital certificate and the information in question. The PKI issues required to establish this model are trivial in nature for situations where a single issuer is distributing information to many recipients, but significantly more involved in situations where multiple senders distribute information to one or more recipients. This model is currently in use in a number of Ebusiness solutions including:
  • Use of digital signatures by the Computer Emergency Response Team (CERT www.cert.org) for software security and viral alerts.
  • Use of digital signatures to ensure the authenticity of software security patches by vendors such as CISCO.
Authenticating users, and protecting the confidentiality of their transactions (via email or web, or other applications).
In this model, the infrastructure and management required to authenticate all parties involved in electronic business transactions can be onerous, depending on the number of users that need to be authenticated. However, once the infrastructure and management practices have been established, users can not only be authenticated with a high degree of confidence, but the digital certificates can also be used to facilitate digital signatures (which are legally binding) and implement secure, encrypted tunnels for sharing information. High-risk situations such as high value funds transfer situations, bank guarantees, legal documents, transfer of sensitive documents may be solved using this Ebusiness model, and examples may include:
  • Online Tax submission.
  • Online voting.


3.3    Identification and Authentication A project that needs to release information only to specific, identified, clients will need to implement some form of client identification mechanism. Information that should only be released to limited groups of people, or individual clients (such as private medical information, name and address data, and so on), is a prime indicator of the need for some form of identification and authentication technology.

IIS supports several forms of user identification and authentication, of varying security strength. The following paragraphs list the authentication schemes supported by IIS in increasing levels of trust.
Anonymous
No authentication is requested from the user. This is the default setting for normal web pages.
IP Level
Some servers within the organisation may benefit from basic IP Address/DNS Address authentication. This option should be set subject to a risk assessment analysis based on customer requirements. Use the IIS Management Console to set the restrictions as appropriate. Note that DNS lookups allow additional flexibility in the case of IP Address changes, but a DNS lookup can potentially slow the performance of the IIS server.
Basic
UserID and Password is requested from the user, and verified against Windows NT account information.
Windows NT Challenge/Response
Assuming that the user is working from a Windows NT client on the same domain as the IIS Server, an NTLM authentication exchange takes place without the user needing to specifically type in their user-ID and password.
Client Certificates
The addition of client certificates implies a significant leap in the complexity of both installation and ongoing management. Certificate generation, the maintenance of directory entries, the preparation of certificate revocation lists, and many other factors contribute to the complexity of this approach. However, SIGNIFICANT value can be derived from a functional, well-managed, implementation  particularly in distributed or heterogeneous environments.
Identification and Authentication
Premium
  
Standard
Authentication requirements should be based on a risk assessment produced as part of the system security plan.
Basic
  
Table 3.3 Identification and Authentication


3.4    Privacy and Encryption, and Information Integrity
Due to the way data is transmitted over public computer networks, there is a risk that information can be intercepted by untrusted third parties. By default, computer networks do not provide any data confidentiality mechanisms, and will dynamically re-route data based on the fastest or most stable path available. As such, a user of the network has no real guarantee that no-one is listening to their data, or that information will always flow over the paths that are considered more trusted.
There are several ways to reduce the risk of information being intercepted and misused by a third party. The common factor for each option is the establishment of a 'secure' and trusted pathway between the client and the web site. This pathway may be physical, such as network infrastructure between the client and the web site that is owned and operated by the owner of the web site, or virtual, in the case of encrypted information tunnels over public networks like the Internet.
When there needs to be some level of assurance that information passed between the host organisation and the client has not been altered in transit, some information integrity controls may also be required.

Very basic levels of information integrity are already available in most network protocols. Information that has been accidentally corrupted in transit between the client and the department is detected using a 'checksum' mechanism. The corrupted information will usually be discarded, and a 'retransmit' is requested. However, there is nothing to stop someone who knows enough about the network protocol to fake information with the correct checksum. As such, in order to disregard messages from unauthorised users, information integrity is usually linked inextricably with the requirement for appropriate identification and authentication.
 

3.4.1    Dedicated Terminals using Private Communications Lines

Although perhaps not a viable option in situations where there are a large number of geographically separate clients, the concept of an owned or 'leased' encrypted, communications infrastructure may be appropriate in some situations. This option would conceptually be like running an extremely long cable between the organisation supplying the data, and the client.

Private communications lines provide privacy, client identification and information integrity commensurate with the physical security of the communications infrastructure. If the organisation can be reasonably certain that only a limited subset of people have access to the physical infrastructure associated with one particular communications link, then the applications can be instructed to take this into account when releasing information down that particular communications path.

It should be noted that some applications may not have the capability to restrict/allow access based on source 'IP address.
 

3.4.2    Server Certificates / SSL
The infrastructure that supports the World Wide Web has grown under the influence of international electronic commerce, which allows any Internet (or Intranet) web site to facilitate encrypted connections to clients who utilise their service, without significant effort on the part of the client. Many electronic commerce sites use web encryption to protect credit card information for online purchases, for example.

In situations where the organisation wishes to request information from a client that may be considered private or confidential, but has no need to comprehensively identify or authenticate the client user, the use of a web based form or application that uses web encryption, may be an appropriate solution. The application can potentially receive data from ,and submit data to, the organisational data storage areas to enable a more efficient service.

There are many advntages to using a web server encryption process;

  • The security components are very simple to implement, and come at extremely low cost.
  • Privacy and information integrity is maintained by infrastructure set up by the organisation. To the client, the process of encryption is transparent. A client who is already online usually will not require extra software, or need to perform configuration changes.
Secure Sockets Layer (SSL) is used to establish an encrypted tunnel between user and the web server. Without the addition of client-level certificates, SSL does not provide any user-level authentication. Be aware that SSL will noticeably affect transaction speed, particularly during initial the SSL establishment process, and the requirement should be evaluated with this in mind.

To set up SSL on the Web server (NOTE: A valid Server side certificate is required!!)

  1. In the Internet Information Services snap-in, select the Web site that you want to protect with SSL and open its property sheets. On the Web Site property sheet, under Web Site Identification select Advanced.
  2. In the Advanced Multiple Web Site Configuration dialog box, under Multiple SSL identities of this Web Site,  make sure that the Web site IP address is assigned to port 443, the default port for secure communications.
  3. There can be multiple SSL ports per Web site. To configure more SSL ports, click Add under Multiple SSL identities of this Web Site.
  4. On the Directory Security or File Security property sheet, under Secure Communications, click Edit.
  5. On the Secure Communications dialog box, configure your Web server to require a secure channel. If you require 128-bit key encryption, make sure your users' Web browsers support 128-bit encryption.

    6. Under Secure Communications , click Edit. There is the option of enabling your Web server's SSL client certificate authentication and mapping features.
Encryption
Premium
  
Standard
Encryption requirements should be based on a risk assessment produced as part of the system security plan.
Basic
  
Table 3.4 Privacy and Encryption

3.4.3    Server Encryption with Password Authentication
This option combines the privacy features of the web encryption option discussed above, with a basic level of user authentication. The technology itself is almost identical to that used by major banks to protect funds for clients that use online banking facilities.

For the host organisation, the identification facilities would be appropriate for protecting sensitive information, short of significant financial transactions. Additional identification and authentication (such as a full client public key infrastructure) may be required for transactions involving a significant commitment of organisational resources or money, although this is at the discretion of the business unit in consultation with organisations management and IT Security.
 

3.4.4    Client Certificates

Full client identification and encryption is facilitated by a public key infrastructure (PKI). PKIs, with various supporting mechanisms, are used in a wide range of business applications.

A PKI is often used in organisations that wish to access the significant benefits of using web technology, whilst still retaining a high degree of identification, authentication and confidentiality. PKI is an essential component for many systems used to protect electronic financial transactions running into millions of dollars.

A PKI supplies the organisation, and the client, with an excellent solution to identification, authentication, confidentiality and integrity requirements, but can be costly in terms of initial and recurring financial outlay, and ongoing management and staff resources.

The implementation expense is highly variable, depending on whether the organisation wishes to outsource the 'certificate' generation process or not. In house generation of certificates is extremely inexpensive, but can potentially involve significant ongoing management.

It should be noted that despite the common conception that certificates of any form imply an increase in ambient security, the inconsidered use of software certificates that are not themselves password protected, may potentially be LESS secure than an well chosen, SSL-protected, userid/password combination.

Although the risk of password related attacks are reduced, the dangers associated with trojan software are potentially increased. The use of client certificates migrates the authentication functionality away from the server system, back to the client computer. The trust placed in the client certificate should be commensurate with the trust you assign to the client, and the clients computer system.

4.0    Access Limitation
 
4.1    File Access Control
Virtual directory permissions in the web application space should be set according to the system risk assessment, and the system security plan. Access control requirements are generally application dependent, but the following rules-of-thumb apply:
 
File Type 
ACL 
CGI etc .EXE, .DLL, .CMD, .PL
Script Files .ASP etc
Include Files .INC, .SHTML, .SHTM
Everyone (X) 
Administrators (Full Control) 
System (Full Control)
Static Content .HTML, .GIF, .JPEG
Everyone (R) 
Administrators (Full Control) 
System (Full Control)
Rather than setting ACLs on each file, it is much more efficient setting new directories for each type of file and setting ACLs on the directory; and therefore allow the ACLs to inherit to the files. For example a directory structure may look like this:
c:\inetpub\wwwroot\myserver\static (.html)
c:\inetpub\wwwroot\myserver\include (.inc)
c:\inetpub\wwwroot\myserver\script (.asp)
c:\inetpub\wwwroot\myserver\executable (.dll)
c:\inetpub\wwwroot\myserver\images (.gif, .jpeg)
File Access Control
Premium
  
Standard
Determine appropriate file access control settings based on the system security plan, and risk assessment. Permissions should be generally set based on the 'least privilege' principal.
Basic
  
Table 4.1 File Access Control

4.2    Executable Content Review

Bugs in active server content are one of the most often exploited system vulnerabilities on the Internet.
Executable content, particularly for servers that are made available to users on public networks, should be critically examined for potential security problems and vulnerabilities. In particular, the peer review portion of your organisations quality assurance or change control procedures should be followed implicitly, with consideration given to having a third reviewer from the security cell examine the code.
Code for which the source is not available may be evaluated in the context of a risk assessment.
Any content that accepts input from the user, or is otherwise under user control can be potentially misused to perform actions that may contravene the site security policy, and may lead to server or information compromise.
File Access Control
Premium
In addition to the normal organisational quality assurance and change control procedures, ensure that executable content is reviewed for security vulnerabilities by an experienced and qualified IT professional who is aware of the various ways in which code may be exploited.
Standard
Code should be subject to the normal peer review process and quality assurance procedures used within the organisation.
Basic
  
Table 4.2 Executable Content Review

4.3    Content Export

Verify that the Index Server is not indexing any documents that you wish to keep secure. In particular, verify that the Index Server does NOT traverse those directories in which you store executable source code content such as ASP files.
Content Export
Premium
  
Standard
Site indexing processes should be limited to those directories that contain information that is not subject to access controls, or need to know principals.
Basic
  
Table 4.3 Content Export

5.0    Auditing

Auditing and Logging facilities are an important part of verifying the security and integrity of the IIS server. W3C logging format is preferred. To enable W3C Logging, load the IIS Management Console | Right-click on site in question | Properties | Web Site | Enable Logging (W3C Extended Log), then set the following properties:
  • Date
  • Time
  • Client IP Address
  • User Name (only if any form of authentication is used)
  • Method
  • URI Stem
  • HTTP Status
  • Bytes Sent
Auditing
Premium
  
Standard
Enable W3C auditing for IIS servers.
Basic
  
Table 5.0 Auditing