Microsoft ISA Server 2006

A web site proxy such as Microsoft ISA Server enables a secure location at which to validate and authenticate inbound traffic prior to forwarding it to its internal destination. By isolating each network involved in the ISA Server path, each to its own specific use, maximum separation for each network path is maintained. Physical separation of networks and associated configurations makes it possible to shield inside network details from outside user access. By isolating the outside facing network from inside and DMZ networks onto specific network interfaces, specific rules can be created for the published servers or applications. While it is possible to publish a web site such as OWA on a single interface ISA server, it leaves no ability to separate user traffic from privileged maintenance traffic or network services traffic such as authentication or DNS traffic. Failure to separate web protocol user traffic from other traffic increases risk that inbound requests may not be adequately scanned, or that may result in unintended information disclosure. ISA Server AdministratorDCBP-1

Logging provides a history of events performed, and can also provide evidence of tampering or attack. Failure to create and preserve logs adds to the risk that suspicious events may go unnoticed, or increase the potential that insufficient history will be available to investigate them. This setting ensures that for each firewall rule, logging will record actions when the rule is used. Administrators, in reviewing these activities, will have data to manage volume, track usage, and detect potential attack scenarios. ISA Server AdministratorECAR-1

Firewall rules support a number of ways to refer to target devices that are subject to their protection. One way is to use a server or web site name that is user friendly. It offers the flexibility of being constant regardless of the IP address assigned, because DNS is available to resolve it. DNS traffic, however, can be captured and may offer an attacker information that could help build a more complete picture of the environment. This type of inadvertent information disclosure raises risk of compromise and should be mitigated where possible. Another method is to identify the OWA server by stating the web site’s IP address. This method enables ISA Server to skip the DNS resolution steps, any resultant network traffic, as well as any associated risk. The reduced flexibility is negligible compared to the risk mitigation, primarily because once assigned, web sites and servers rarely change addressing. ISA Server AdministratorECSC-1

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting enables an automated log entry to be sent to Microsoft giving general details about the nature and location of the error. Microsoft, in turn, uses this information to improve the robustness of their product. While this type of debugging information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of problems in the ISA server. At the very least, it could alert them to (possibly) advantageous timing to mount an attack. At worst, it may provide them with information as to which aspects of ISA are causing problems and might be vulnerable (or at least sensitive) to attack. Using this feature, system errors in ISA could result in outbound traffic that may be identified by an eavesdropper. For this reason, the “Report errors to Microsoft” feature must be disabled at all times. ISA Server AdministratorECSC-1

It is not typical for ISA Server addressing to be assigned or managed using DHCP servers. Nor is it an accepted industry practice for an ISA server to host DHCP services. In environments where server addresses are assigned with static network addresses, DHCP clients and services must be disabled. Failure to control incidence of network services traffic such as DHCP may cause multiple vulnerability issues, such as addressing information disclosure, or denial of service (DOS) due to rogue DHCP transactions. ISA Server AdministratorECSC-1

For an ISA server in the role of OWA proxy, Active Directory traffic must be allowed because the ISA firewall must be configured to require AD authentication in that scenario. Authentication methods not in use (RADIUS, RSASecurID) must be disabled in the ISA System Policy. Alternate authentication traffic, even if directed at the ISA server in error, raises risk that the server could react to it, unnecessarily expending resources. By disabling them, these protocols will not traverse the ISA server, even if an unauthorized process initiates them. ISA Server AdministratorECTM-1

Physical security measures for computer environments are necessary to control risk from theft or sabotage. Site security for computer environments increases its success factor proportionately as it reduces or controls the number of people admitted to the environment. Also, large deployment sites such as data centers host hundreds or thousands of computers in secured environments. For administrators, physical access to individual computers is usually impractical. Remote Management utilities are convenient ways for administrators to support physically secured servers, for example, those in raised floor environments. By giving network-based access to physically unreachable machines, administrators may work from a single location, such as a desktop, provided they have a network path to each target machine in their charge. As convenient as remote management can be for administrators, the same would also be true for an attacker able to reach the same servers. For that reason, remote administration client computers must be specified as precisely as possible, to ensure the smallest possible risk exposure to an attack. By default, the ISA Server safeguards itself by disabling all remote administration traffic. However, when needed, ISA policies may be configured to granularly admit remote management traffic such as MMC, Terminal Server, or Web Management. ISA2-027 ISA Sites using remote administration for ISA computers must configure as tightly as possible the source of remote administration traffic. Sites using isolated services networks may have them sufficiently secured to use a strategy of allowing the entire services network as the source, however, if it is possible to configure to one or more specific computers, such as a terminal server to gain access to the services network, that is preferred to specifying a wider scope of potential addresses. Start >> Programs >> ISA Server Management >> Microsoft Internet Security and Acceleration Server 2006 >> Arrays >> >> Firewall Policy >> "Tasks" tab Click the link for Edit System Policy. In the “Configuration Groups” list, identify Remote Management. Choose the desired service from the list (Microsoft Management Console (MMC), Terminal Server, and Web Management), and perform the following: On the “General” tab, select the “Enable this configuration group” checkbox. On the “From” tab, click the "Add" button, identify or define the network or computes supporting remote management, and select the required entity. Criteria: If the IAO approval for remote administration is documented in the System Security Plan, then the configuration must match that criteria, and also meet the following stated criteria: The “Enable this configuration group” checkbox must be checked for a specific remote management service, and the “From” tab must list authorized source locations. If this criteria is met, this is not a finding. ISA Server AdministratorECTM-1

PING is a useful diagnostic utility, enabling the sender to detect the server’s liveness on the network. Other diagnostic utilities have embedded ICMP-based commands that are also useful, for example TRACERT or PINGPATH, which produces a report showing the path from the source computer to the destination computer one router hop at a time. Responding to PING when initiated from an authorized source, such as from a Remote Administration computer, adds to the diagnostic value as part of a larger set of monitoring and diagnostics techniques. The same would be true if initiated by an attacker, a scenario that does not benefit anyone except the attacker. It is for this reason that routers and other network devices also do not have PING responses enabled. Failure to prevent PING responses add risk that an attacker could derive several pieces of information about any server that responds to it. Existence of the IP address, the server name, and to a lesser degree OS type and age can be deduced from the PING response. For this reason, it is a recommended industry practice to either not allow PING, or to restrict responses to only approved sources, as would be needed in the case of remote administration networks. ISA2-028 ISA Sites using remote administration for ISA computers may opt to use PING, as part of a larger set of diagnostic tools. However, PING must be configured as tightly as possible to identify the source of acceptable PING traffic. Sites using isolated services networks may have them sufficiently secured to use a strategy of allowing the entire services network as the source. However, if it is possible to configure to one or more specific computers, such as a terminal server, to gain access to the services network, that is preferred to specifying a wider scope of potential addresses. Procedure: Start >> Programs >> ISA Server Management >> Microsoft Internet Security and Acceleration Server 2006 >> Arrays (array name ) >> Firewall Policy (server name) >> "Tasks" tab Click the link for Edit System Policy. In the “Configuration Groups” list, identify Remote Management Services, and select PING. On the “General” tab, select the “Enable this configuration group” checkbox. On the “From” tab, click the Add button, identify or define the network or computers authorized to be a source of PING traffic, and select it. Criteria: If the "Enable this configuration group” checkbox is selected and the authorized networks are defined, this is not a finding. ISA Server AdministratorECTM-1

Administrators for managed computer environments often use network based monitoring tools to access and report on health and status information for computers in their care. Management hosts communicate with target servers to run utilities, extract log information, and receive alert information, should the need arise. For sites that employ Microsoft tools, products such as Microsoft Operations Manager (MOM) and Microsoft Remote Performance Monitor would access the ISA server to monitor tasks configured by the administrators. For sites that employ other products, specific rules would need to be created on the ISA server to enable the specific protocols and processes for those products. As convenient as remote management can be for administrators, the same would also apply to an attacker who was able to reach the same servers. Having remote monitoring paths to servers raises the risk that an attacker could at the very least, capture traffic and learn much about the monitored servers. Controlling monitor access and data to be as specific as possible help to reduce any potential attack profile. ISA2-029 ISA Sites using Microsoft monitoring tools for ISA computers must configure as tightly as possible the source of remote monitoring traffic. Sites using isolated services networks may have them sufficiently secured to use a strategy of allowing the entire services network as the source. However, if it is possible to configure to one or more specific computers, such as a terminal server, to gain access to the services network, that is preferred to specifying a wider scope of potential addresses. For these sites, perform the following: Start >> Programs >> ISA Server Management >> Microsoft Internet Security and Acceleration Server 2006 >> Arrays >> >> Firewall Policy >> “Tasks” tab Click the link for Edit System Policy. In the “Configuration Groups” list, identify Remote Monitoring, and select a remote monitoring tool. On the “General” tab, select the “Enable this configuration group” checkbox. On the “From” tab, click the “Add” button, identify or define the network or computers hosting the remote monitoring tool, and select it. Criteria: if the “Enable this configuration group” checkbox is selected and the monitoring network is specified, this is not a finding. ISA Server AdministratorECTM-1

ISA monitors all give the ability to send e-Mail messages if an alert threshold is triggered. Even for sites that may operate remote monitoring tools, there are some on-board monitors in the ISA application as well. These local monitors are best employed for specific ISA application features that may need timely attention by administrators. For example, if a hardware failure prevents logs being written to a remote target, the alert may need to shut down ISA services, and immediate notification of an administrator may be desired. In this case, the e-Mail option may be elected, triggering the Event Response process. If no alerts are configured to use the e-Mail option, then the SMTP policy should be disabled. Simple Message Transfer Protocol (SMTP) is the protocol used to deliver the alert messages in e-Mail format. For sites using e-Mail output for alert messages, the ISA server must be configured to allow SMTP to pass from the server to an authorized e-Mail Message Transfer Agent (MTA) server, and the e-Mail server’s domain must have an e-Mail enabled account with a mailbox to receive the messages. ISA2-030 ISA Sites using e-Mail communication for alerts must enable SMTP in the ISA System Policy and must configure as tightly as possible the destination MTA servers that are authorized to receive this traffic. NOTE: The SMTP server configured on the alert must belong to the selected configuration group. In this configuration, care must be taken to ensure that only authorized SMTP servers and e-Mail addresses receive the outbound monitoring messages. Start >> Programs >> ISA Server Management >> Microsoft Internet Security and Acceleration Server 2006 >> Arrays >> >> Firewall Policy >> “Tasks” tab Click the link for Edit System Policy. In the “Configuration Groups” list, identify Remote Monitoring, and select SMTP. On the “General” tab, select the “Enable this configuration group” checkbox. On the “To” tab, select the “Add” button, identify and configure the e-Mail server and the user account authorized to receive alert messages. Criteria: if the “Enable this configuration group” checkbox is selected and specific e-Mail servers are identified, this is not a finding. ISA Server AdministratorECTM-1

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. This setting enables an automated communication to be sent to Microsoft containing details surrounding local product usage, configurations, errors, and so forth. Microsoft, in turn, uses this information to improve the robustness of their product. While this type of information would not ordinarily contain sensitive information, it may alert eavesdroppers to the existence of the ISA server, its address and other configuration details. At the very least, it could alert them to (possibly) advantageous attack types based on running services. At worst, it may provide them with information as to which aspects of ISA are causing problems and might be vulnerable (or at least sensitive) to attack. Using this feature, ISA could emit outbound traffic that could be identified by an eavesdropper. For this reason, the “Participate in Microsoft Customer Experience Improvement Program” feature must be disabled at all times. ISA Server AdministratorECSC-1

Identification and Authentication provide the foundation for access control. Requests inbound from the Public Internet must be challenged for authentication and authorization prior to being admitted into the desired system. In the case of OWA, a web application, the DoD requires SSL connections and CAC authentication for authorized users based on certificate validation and Kerberos Active Directory credentials. It is not desirable to admit unfiltered SSL traffic into the application environment, as many malware variations have been found to be embedded inside SSL requests. Failure to terminate, examine, and filter SSL requests at the ISA server would risk passing Trojans, bots, or other malware forms into the internal networks. Additionally, certificate SSL credentials cannot be forwarded directly from the Internet to OWA, as it is unable to process them. For Kerberos Delegated AD authentication to be available, the ISA server must be a member of the same domain as the Exchange 2003 Front End server it is protecting, or belong to a trusted domain in the same forest. The ISA server is identified in Active Directory as ‘trusted’ to perform the delegation. The ISA-to-AD communication is specific to allow only the authentication steps; no other AD functions are authorized using this connection. If other methods are selected, features such as certificate based authentication or credentials delegation would not be included in the login process. ISA Server AdministratorECSC-1

The ISA server secures access to specific resourced inside specific networks. Protecting security configurations that describe these resources is key to preventing accidental or deliberate information disclosure. ISA Server domain configuration enables Administrators to restrict services to domain names that might be serviced by this ISA server. Failure to restrict authorized domains in the local domain table may result in the generation of DNS traffic to perform domain name lookups. The presence of DNS lookup traffic on the network segment could be captured by an attacker, resulting in information disclosure. ISA Server AdministratorECSC-1

Identification and Authentication provide the foundation for access control. When the OWA web server specifies Windows authentication, the ISA server must discover and locate domain controllers for the desired login domain. If multiple computers are available on the network, the discovery traffic on the network could be trapped and viewed by an attacker. By specifying a specific group (such as a specific domain controller network or computers) processing will bypass the discovery process and travel directly to the configured location, thus preventing potential information disclosure. ISA Server AdministratorECSC-1

Server certificates are required for many security related transactions. In fact, certain encryption and authentication steps are impossible without the information defined there. Certificate authorities (CAs) that issue certificates are responsible to not only verify a recipient’s relationship to the issuing organization, but also to declare the scope and purpose of the certificate within that relationship. The DoD requires that only certificates issued by a DoD certificate root authority be trusted for OWA access, and that certificates issued by other entities not be trusted. Failure to identify only DoD certificate root authorities as being trustworthy (to the exclusion of all other issuers) risks that certificates issued from other issuers, whose processes cannot be controlled by the DoD, might result in the acceptance of unauthorized credentials. ISA Server AdministratorECSC-1

Firewall rules are evoked if certain defined conditions are met, for example, matching criteria on traffic content, or IP address (source or destination) and determine conditions under which users are admitted to “published” web sites such as OWA. A rule that gives access to “all users” increases risk of admitting unauthenticated users, as this setting causes ISA to skip user authentication steps. Therefore, “all users” must never be selected. The “Require all users to authenticate” choice must also be avoided, as it would prevent some automated ISA Server functions operating properly. For these reasons, rules for published web sites must grant access only to “authenticated users” or a group that is a subset of “authenticated users”. ISA Server AdministratorECSC-1

One server hardening technique to guard against packet flooding attacks is to filter for fragments. Packet fragments that are created for malicious purposes are usually impossible to assemble, and can cause denial of service type outages. While it is good to prevent this type of attack, it must not be done on the ISA server, but elsewhere in the network prior to traffic reaching the ISA server. UDP fragmenting is a normal occurrence during the authentication process, especially when certificates are in use. Filtering for fragments will interfere with the authentication process and cause authentications to fail. Failing to allow fragmented UDP packets to travel to and from the ISA server risks failed authentications and would likely prevent users reaching the published applications. The result in this case would also be a type of denial of service. ISA Server AdministratorECSC-1

Network traffic often contains automated viruses and worms attempting to discover entry points into protected networks. Threats are often engineered to either gain entry and compromise computers or to simply flood connections and cause Denial of Service (DOS) to the network interface. These attacks are often brute force in nature, comprised of large volumes of packets, and can originate from either a single source or multiple sources. ISA Server is equipped with a flood mitigation feature to assist in detecting and logging such attacks, as well as blocking the traffic. This feature is enabled by default, but administrators have the ability to disable it, for example, if it is documented that this protection is configured elsewhere in the network ahead of the ISA server. However, there is no downside to having it enabled, not only for the protective measures offered, but also for the logging information collected. ISA Server AdministratorECSC-1

Several default application and web filter add-ins are installed and enabled on the ISA server application. When the ISA server is configured as an OWA proxy server, some filters are not necessary for that role. Disabled filters take no action against their protocol targets. Enabled filters do appropriate memory and CPU cycles. For a web proxy server publishing OWA, only HTTP, HTTPS (SSL) and tunneled FTP are supported protocols. For authentication using Kerberos Constrained Delegation (KCD), the Authentication Delegation filter is needed. The PPTP filter cannot be disabled; all others can be. Failure to disable unneeded filters causes server resources to be expended unnecessarily. Note: Removing the filters from the server does not improve the security profile, and may increase administrative effort if they become needed in the future, therefore, removing unneeded filters is not a necessary action. With the HTTP filter enabled, all configurable HTTP policy is enforced. Note: The HTTP filter examines inbound SSL traffic after “SSL unloading”, but before the subsequent “SSL initiation” for connection to the target web server. However, failure to enable the HTTP filter causes NONE of the HTTP evaluation to be performed, with the potential result of malware compromise due to HTTP-based content. ISA Filters can be manipulated at the Enterprise level and at the server level. Filters DISABLED at the Enterprise level can be enabled at the server level for specific servers as needed. Filters ENABLED at the Enterprise level may not be changed at the server level. Care must be taken with role based permissions for administrators to achieve the desired effect. ISA Server AdministratorECSC-1

Identification and Authentication provide the foundation for access control. The Web Listener is used by the ISA Server to receive inbound traffic on behalf of the targeted web site and manage admittance according to its configurations. Among the listener’s abilities are authentication (multiple types), filtering, and SSL connection management. This feature controls the authentication method used to connect to the OWA web listener. Authentication must be set to “Client Certificate Authentication” only for use with Common Access Card (CAC) certificates, enforcing two-factor authentication. When forwarded to the OWA server, the credentials will re-authenticate, but not require that the user key them in again. Internal server names and addresses are protected, because only the ISA server needs to know them. Also, the interruption helps protect against SSL based attacks that can be hidden inside encrypted SSL connections. ISA Server AdministratorECSC-1

Web publishing rules serve the purpose of screening inbound requests targeting a specific application. While it is technically possible to select multiple applications for the same rule, it is not recommended. For example, in Exchange 2003, it is possible to select multiple Exchange applications (OWA, Outlook over HTTPS, Outlook Mobile Access) for a given listener. This is not recommended, and for Exchange 2007 this ability has been changed to the single application isolation model. Failure to isolate applications in this way enables users to access multiple applications without having to separately authenticate to each. The selection of OWA gives the user access to only three web paths: Public, Exchange, and Exchweb. ISA Server AdministratorECSC-1

Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. ISA Server 2006 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion. Low disk space condition can be reached when logs overrun their intended space either due to attack or poor operations procedures. When a low disk space condition exists, there is risk that the ISA server can produce unanticipated actions, or cease to function, with the end result being an abrupt denial of service condition. By configuring the failsafe monitor, notification can go out to administrators that a low disk space condition exists, but also initiate failsafe procedures on the ISA server. For example, inbound traffic is now ignored, while outbound traffic continues. Further actions can be specified on the lock down policy rule to continue the orderly stoppage of ISA services until administrative action can be taken. ISA Server AdministratorECSC-1

In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to an ISA server firewall that leads to unauthorized administrative access to the host system can most likely lead to other compromises, such as access to applications co-resident with the ISA system or security changes using now-available security configurations. ISA services must be installed to a discrete set of directories, on a partition that does not host other applications or the Operating System. If other applications must share that environment, it should only occur if necessary to the operation of the ISA application. ISA must never be installed on a Domain Controller / Directory Services server. ISA Server AdministratorDCPA-1

In the same way that added security layers can provide a cumulative positive effect on security posture, multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to an ISA server firewall that leads to unauthorized administrative access to the host system can most likely lead to other compromises, such as access to applications protected by the ISA system. ISA firewall services interact with a discrete configuration server. By default, the configuration database, ADAM instance, and server install to the same server, unless directed elsewhere. In larger environments it is desirable to install multiple ISA servers (referred to as an ‘array’), and have them share the load for inbound traffic. In order to operate effectively, each server must share configuration values. The configuration storage server enables each ISA server in the array to share a common configuration at runtime. Equally valuable, is that the configuration data components are not destroyed or disclosed if the ISA server experiences hardware failure or is removed from the array. The ISA server will continue to function after losing connection with the configuration storage server; however, no configuration changes will be possible until it is reconnected. ISA Server AdministratorDCPA-1

Logging provides a history of events performed, and can also provide evidence of tampering or attack. Failure to place log and audit data on a separate partition, under a separate security context adds to risk that an exploit mechanism might reach and modify log contents. Careful placement of logs reduces the risk that suspicious events may go unnoticed, and reduces the potential that insufficient history will be available to investigate them. ISA Server offers three log format choices: Microsoft Desktop Engine (MSDE), SQL, and file format. MSDE (a version of SQL Server) and file format require that a path on the current server be identified. SQL enables log data to be sent to a SQL server at a separate location, with the option of going encrypted and authenticating with a windows user account. File format needs may vary by site, however, they are best protected by being stored separately from the ISA services data. ISA Server AdministratorDCPA-1

PPSM Standard defined ports and protocols must be used for ISA services. The standard port for HTTP connections is 80 and the standard port for SSL connections is 443. OCSP also uses port 80, as it is web based and returns the certificate status to the ISA server. Changing the ports to non-standard values provides only temporary and limited protection against automated attacks since these attacks will not likely connect to the custom port. However, a determined attacker may still be able to determine which ports are used by performing a comprehensive port scan. Negative impacts to using nonstandard ports include complexity for the system administrator, custom configurations for connecting clients, risk of port conflict with other applications, and risk of incompatibility with standard port monitoring applications. ISA Server AdministratorDCPP-1

The INFOCON system provides a framework within which the Commander USSTRATCOM Regional Commanders, Service Chiefs, base/post/camp/station/vessel Commanders, or Agency Directors can increase the measurable readiness of their networks to match operational priorities. The readiness strategy provides the ability to continuously maintain and sustain one’s own information systems and networks throughout their schedule of deployments, exercises and operational readiness life cycle independent of network attacks or threats. The system provides a framework of prescribed actions and cycles necessary for reestablishing the confidence level and security of information systems for the commander and thereby supporting the entire Global Information Grid (GIG) (SD 527-1 Purpose). The ISA software files and directories as well as the files and directories of dependent applications are vulnerable to unauthorized changes if not adequately protected. An unauthorized change could affect the integrity or availability of ISA services overall. For this reason, all application software installations must monitor for change against a software baseline that is preserved when installed, and updated periodically as patches or upgrades are installed. Automated and manual schedules for software change monitoring must be compliant with SD527-1 frequencies. Information Assurance OfficerDCSL-1

ISA 2006 software, as with other application software installed on a host system, must be included in a system baseline record and periodically reviewed, otherwise unauthorized changes to the software may not be discovered. This effort is a vital step to securing the host and the applications, as it is the only method that may provide the ability to detect and recover from otherwise undetected changes, such as those that result from worm or bot intrusions. The ISA 2006 software and configuration baseline is created and maintained for comparison during scanning efforts. Operational procedures must include baseline updates as part of configuration management tasks that change the software and configuration. ISA Server AdministratorDCSW-1

Server certificates are required for many forms of secure communication. Certificates must be manually installed on each server where “secure connections” or “encrypted connections” are required. A single certificate may be shared among multiple services, or multiple certificates may be installed, with each supporting a separate service association. For ISA servers in the “OWA Application Proxy” role, a copy of the DoD OWA SSL certificate must be installed for use by the OWA listener. Without it, a secure, encrypted connection to the OWA web site is not possible. ISA Server AdministratorIAKM-1

Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. ISA 2006 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion. For this reason, alert definitions that detect that Kerberos Credential authentications are failing must log the information so that it can be reported. ISA Server AdministratorECAT-1

ISA system availability depends in part on best practices strategies for setting tuning configurations. The health and continuity of the ISA application depends upon its having sufficient disk space to function. Failure to ensure enough free disk space adds to the risk that ISA services will perform erratically or shut down abnormally, rendering the ISA firewall service unavailable. For this reason, alert definitions that detect less than the threshold for free disk space available must be configured to perform orderly shutdown of the ISA service and render all traffic inadmissible until free disk space is once again available. ISA Server AdministratorECAT-1

Monitors are automated “process watchers” that respond to performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. ISA 2006 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion. In the case of ISA Server 2006, logged events are critical not only to the server administrative effort, but also to the Event Respose effort. Log contents provide the basis for many types of event reporting. Failure to save log data, no matter what the reason, risks that attack events may be undetected or unrecorded. For this reason, alert definitions that detect the inability to create log data must be configured to perform orderly shutdown of the ISA service and render all traffic inadmissible until log data can once again be saved. ISA Server AdministratorECAT-1

Monitors are automated “process watchers” that respond to performance or threshold changes, and can be useful in detecting outages and alerting administrators where attention is needed. ISA 2006 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion. In the case of ISA server, logged events are critical not only to the server administrative effort, but equally to the Event Response effort. Log contents provide the basis for many types of event reporting. Failure to write log data due to it allocated disk space being exceeded risks that attack events may be undetected or unrecorded. Inability to write logs will cause the ISA service to stop abnormally. For this reason, alert definitions that detect the inability to write logs due to storage failure must be configured to perform orderly shutdown of the ISA service and render all traffic inadmissable until log data can once again be saved. ISA Server AdministratorECAT-1

All servers and applications that accept certificate authentication must also require Certificate Revocation List (CRL) validation. The CRL is a repository comprised of data from (usually) many contributing sources of CRL. Certificate identifiers may arrive at the CRL for a number of reasons, for example, when an employee leaves employment, or certificates expire, or if certificate keys become compromised and are reissued. The technical process for certificate validation includes initiating a transaction to the CRL repository, requesting certificate status by identifying CRL entries, if present. Outbound requests use port 80 to converse with the CRL. Failure to restrict outbound port 80 traffic to the CRL location risks that an attacker could use port 80 to travel to uncontrolled destinations to launch other attacks or participate as an internal bot conversing with external Internet entities. The system policy must be edited to specify the CRL repository location. ISA2-026 ISA Sites using an OCSP client rather than CLR download to validate certificates will have obtained and installed an OCSP client application such as Tumbleweed Desktop Validator. The OCSP client must be resident on the ISA 2006 Server and configured to interact with a valid certificate revocation data repository. Procedure: Interview the ISA Server Administrator. Access the ISA Server and verify that presence of an OCSP client application on the server. Verify also, that the configuration identifies the certificate status data repository, and that the service is active. Criteria: If an OCSP client is installed on the ISA server, is active, and configured to a valid certificate status data repository, then this is not a finding. ISA Server AdministratorECSC-1

The ISA Listener daemon determines the nature and conditions under which it will allow a user connection to be authenticated. In the case of OWA e-Mail resources, the DoD requires that CAC authentication be used, and that all connections be encrypted. For this reason, the OWA Web Listener must be configured to require that all connections be secured and encrypted using SSL. Upon arrival at the ISA server, the connection will offload the SSL encryption, and certificate based credentials will begin the authentication process. Once authenticated, the user’s request will be repackaged into a second SSL connection that traverses the span from the ISA server to the OWA web server. This technique is referred to as SSL Bridging, which prevents SSL-embedded attacks from reaching the targeted internal web server without interruption. Internal server names and addresses are protected, because only the ISA server needs to know them. Also, the interruption helps protect against SSL based attacks that can be hidden inside encrypted SSL connections. ISA Server AdministratorECSC-1

Unrestricted access or access unnecessary for operation can lead to a compromise of the ISA application or disclosure of information that may lead to a successful attack or compromise of the configuration data. Microsoft ISA configuration data is hosted in multiple application infrastructure components, however, a single Firewall Administrator must be able to set and review configurations as needed for the environment. Administrative roles may be assigned at either the enterprise level, for more global control, or at the array level for more local control. By default, ISA in a domain grants membership in the ISA Server Enterprise Administrator role to the Exchange server’s Administrator account, and the local BUILTIN Administrators group for the ISA server. Other refinements are available and should be used for tasks such as local administration, monitoring, and auditing. Failure to control access to ISA configuration data adds risks information disclosure for such items as internal network addressing, application server names, web site locations, and so forth. For ISA to effectively protect to internal assets, access control must be carefully designed and implemented. Only ISA Server Administrator security groups should enable user access to ISA server configurations. Information Assurance OfficerECLP-1

IPv6 is defined with many more security and interoperability behaviors than IPv4, including IPSEC and the promise of enhanced addressing space for growing networks. However, IPv6 has not enjoyed widespread implementation, and protocol-specific products such as ISA 2006 were not designed to inspect IPv6 characteristics. IPv6 is not “understood” by the ISA server’s firewall features. ISA will not recognize IPv6 traffic, and will process it (pass it through) without authentication or filtering. An attacker using IPv6 protocol would find an unobstructed path through an ISA 2006 server undetected, because the ISA 2006 application is not IPv6 aware. Therefore, IPv6 should not be installed on any network Interfaces for use by the ISA server. ISA Server AdministratorECSC-1

ISA server firewall implementation models, when deployed in commercial environments, typically have multiple interfaces and network attachments. Traffic inbound arrives at the interface labeled “external” in the ISA server. Protected servers and applications are reached via networks labeled “internal” or have other labels, as created by administrators. For example, there may be a management network restricted to technical support staff, or service segments dedicated to DNS, DHCP, etc. Multiple protocols are included with the Windows 2003 OS, and others may be obtained. For example, Apple talk and NWLINK are available for easy install, primarily to interface with other OS environments, such as Apple or Unix respectively. Unneeded protocols offer attackers open ports through which to attempt attacks. Inbound requests for an ISA server protecting OWA will be detected by a listener that will only accept SSL connections. Because this interface is dedicated to this task, protocols other than TCPIP are not needed on the ‘external’ interface. Failure to restrict protocol choices to only those needed by the application increases risk that an attacker could gain entry using alternate protocols and be undetected. ISA Server AdministratorECIC-1

Unneeded, but running, services offer attackers an enhanced attack profile, and attackers often watch to discover open ports with running services. By disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result. Web servers that host fixed pages for user access do benefit from the functionality of a cache server, in that accessed pages can be kept for future access by the same user or alternate users of that web site. In the case of the OWA web site, where the content is user-specific e-Mail messages, cached copies could be stored, but would not likely be used again by a user. Cached data, both in memory and on disk, has historically been the target of attacks. Given the potentially sensitive nature of e-Mail data, and given that each session’s content quickly becomes obsolete, the use of caching appears to invite more risk than benefit. With the cache feature turned off, the ISA server may require additional physical memory to achieve acceptable performance, but no residual cache data will be resident on the server for an attacker to access. ISA Server AdministratorECSC-1

Unneeded, but running, services offer attackers an enhanced attack profile, and attackers often watch to discover open ports with running services. By disabling unneeded services, the associated open ports become unresponsive to outside queries, and servers become more secure as a result. ISA servers operating in the OWA proxy server role do not operate in the VPN model, and therefore do not require the VPN option to be active. ISA Server AdministratorECSC-1

Applications introduce some of the most common database attack avenues, and can provide a pathway for an unlimited number of malicious users to access sensitive data. An account responsible for Service execution, if compromised, may subject the data to unauthorized exposure if it is granted more privileges than necessary. Typically, service accounts must run only their designated services, and must not be shared with other applications or people. Audit Log Monitoring can then assume an ‘expected’ set of activities for each service account, and administrators can more readily recognize events that are unexpected. A discrete history of account activity is valuable if an attack of the host system needs to be investigated. If accounts are shared among multiple services or people, it increases the risk that firewall Administrators will not have an accurate history for investigation and troubleshooting purposes. In the case of Microsoft ISA Server 2006, attempting to run ISA services on an alternate service account (rather than the default SYSTEM account) is not a supported Microsoft configuration. Due to the nature of the ISA services access required within the server and the network, ISA services must run under the Microsoft Windows SYSTEM account. ISA Server AdministratorECLP-1

Log files help establish a history of activities, and can be useful in detecting attack attempts or determining tuning adjustments to improve availability. Audit log content must always be considered sensitive, and in need of protection. Audit data available for modification by a malicious user can be altered to conceal malicious activity. Audit data might also provide a means for the malicious user to plan unauthorized activities that exploit weaknesses. Only authorized auditors and the database audit functions should be granted access to database audit data. ISA Server AdministratorECTP-1

Monitors are automated “process watchers” that respond to thresholds or performance changes, and can be useful in detecting outages and alerting administrators where attention is needed. ISA 2006 built-in monitors enable the administrator to generate alerts if thresholds are reached, better enabling them to react in a timely fashion. For this reason, alert definitions that detected attempts at using an invalid certificate must log the information so that it can be reported. ISA Server AdministratorECAT-1