General Stealth Feature Overview
3.4. COIs and Endpoint Security
Stealth enables multiple “secure communities” to share the same network without fear of another group accessing their data or their workstations and servers. These are referred to as Communities of Interest (COIs).
3.4.1. COI Overview
COIs enable secure, logical separation of network users and data instead of configuring multiple physical networks. The result is a much simpler network infrastructure, increased agility to react to new requirements, and enhanced security of your network data. COIs are created using the Enterprise Manager interface and then encrypted and stored in the associated database for Enterprise Manager. You can create as many COIs as are required to secure your environment.
COIs enable different COI data to share the same network. For example, when a user is working in a Top Secret security level, all traffic could be encrypted using a “Top Secret”
COI. If the user wants to change to the “Secret” security level, he or she logs off, and the endpoint closes all tunnels established with the Top Secret COI. When the user logs on using the Secret security level user name and password, the endpoint establishes tunnels as necessary with the Secret COI.
As this example demonstrates, the COI is associated with a user, not with a physical system. The COI is configured on the endpoint when a particular user logs on. The user authorization determines the set of COIs assigned within the enclave.
When you create COIs, you designate them as either Workgroup COIs or Service COIs.
Workgroup COIs are used for general communication between endpoints. See the following topic,3.4.2 Service COIs and Service Roles,for more information about Service COIs.
3.4.2. Service COIs and Service Roles
Service COIs are used by an endpoint to access the Authorization Service and retrieve the endpoint credentials. After you create one or more Service COIs, you can add those COIs to a role that you designate as a Service Role.
The endpoints associated with the configuration communicate with the Authorization Service using the Service Role and its associated Service COI or COIs. The Service Role cannot be associated with any accounts (that is, you cannot add any users to that Service Role).
To create an endpoint package, your configuration must include a Service Role, and that Service Role must include at least one COI. In addition, you must add the same COI that is associated with the Service Role to the role associated with the Management Server user so that endpoints can be authorized.
Note: Any COI that is not included in a Service Role and is used for regular communication between endpoints is known as a Workgroup COI.
When you create a role, you specify which configuration it should be included in. You must create one Service Role for each configuration that you want to use to create an endpoint package. However, you do not have to create additional Service COIs (unless required for your environment), because multiple Service Roles can share the same Service COI or COIs.
3.4.3. COI Guidelines to Enable Communication Between the Authorization Service and Endpoints
Use the following guidelines when creating COIs to enable communication between the Authorization Service and endpoints:
• Any Authorization Service in the environment must share a Service COI with the endpoints it is authorizing. This enables the endpoints to be authorized and obtain their COIs. In addition, the Authorization Service must share a Workgroup COI with the endpoints it authorized for licensing and logging purposes, so that the Authorization Service can monitor activity and ensure that the endpoint is still active.
• The Service COI for the Management Server must also be a COI in a non-Service Role. That is, if you create ServiceRole and ServiceCOI, and you create AuthRole, then ServiceCOI must be saved in both ServiceRole and AuthRole.
• For the Service COI in the Service Role, you should create a filter that enables access only to the IP address of the Management Server to restrict communication to the port used for authorization access (the AuthGroup URL port). Do not apply this filter to the Service COI in the AuthRole; doing so prevents the Authorization Service from communicating with endpoints.
• COIs are processed in the order in which they are listed, so you might want to sort them in a specific order. For example, an endpoint in the Finance department might include a COI named FinanceCOI and a COI to maintain communication with the Authorization Service named AuthCOI. In that case, you probably want to sort the FinanceCOI above the AuthCOI, because the communication between endpoints uses the FinanceCOI, which means that it will be used most frequently. COIs are processed about ten at a time (varying slightly, based on the configuration), and so the order of COIs is especially important for any endpoint that includes ten or more COIs.
3.4.4. Stealth Endpoint Processing
Stealth processing uses the SCIP/IPsec protocol and involves authorization and session processing phases. These phases occur automatically and seamlessly in a Stealth environment managed by the Enterprise Manager, as follows:
• Authorization Phase
Once authenticated by the local identity management system, the user logged onto the endpoint is assigned COI access and policies during the authorization phase of processing. The Stealth tuples contain a set of certificates representing the COIs for which the user is authorized, plus an authorization token that can be used during the tunnel initiation to negotiate COI usage.
Enterprise Manager generates an install or runtime XML file for the endpoint software, which contains the information necessary to initiate and maintain a successful session; it also identifies the set of Authorization Services to which the endpoint can possibly connect and the order in which the connection should be attempted. The endpoint sequentially iterates among identified Authorization Services until a session is established. If the attempt to connect for a session fails (you receive a “no HTTP response received” message or the XML response indicates an error), then the endpoint retries three times before stopping the attempt to connect with that Authorization Service.
Enterprise Manager uses the signing certificate to protect the integrity of the settings.xml and crypto.xml files, which are included in the endpoint software package. The endpoint uses the corresponding root and intermediate certificates to validate these XML files before enabling Stealth.
Note: While the system is trying to connect with an Authorization Service, it remains in Service mode. See the remainder of this topic for more information on Service mode.
Because of a persistent connection between the endpoint and the Authorization Service, the following capabilities are possible:
- During the connection, the endpoint consumes a license. If the endpoint detects that the connection is down, it enters a grace period of approximately one hour. If the grace period expires, the endpoint closes its tunnels, enters Service mode and attempts to find another connection to an Authorization Service.
- During the connection, the endpoint sends audit information (for example, log ons, log offs, number of tunnels open or closed or failed, configuration changes) to the Authorization Service. The Authorization Service can then, optionally, send the audit information to a Syslog server or integrate it into some other Security Incident and Event Management (SIEM) system, as needed.
- The Authorization Service provides real-time monitoring of the endpoint through the Enterprise Manager interface. The portal administrator can initiate control functions (such as tunnel termination or reset) using this interface.
- Additional optional functions are available, including endpoint software and configuration changes. That is, the Authorization Service can use the connection to alert the endpoint of significant events. The endpoint can take action,
depending on the event. For example, the Authorization Service might alert the endpoint that it has been re-provisioned. In that case, the endpoint can reauthorize with the new provisioning file.
On log on notification, the endpoint generates a public or private key pair that is unique to that particular log on session. The endpoint sends the public key plus identification and authorization information to the Authorization Service. It determines the COI memberships of the user and returns specific information about the user’s credentials.
• Session Phase
Once authorized, the endpoint can open data transfer tunnels to other endpoints. The activity of opening tunnels by an authorized endpoint constitutes a session. All traffic between the endpoints with a data transfer tunnel operating is protected (subject to filtering processing).
Note: The use of tunnels (and potentially using explicit COIs for those tunnels) is controlled by the filtering policies distributed to the endpoints by the Authorization Service. Filters are critical to proper operation of Stealth. See3.5 Filteringfor more information.
- Session Initiation
When an endpoint opens a tunnel to another endpoint, it sends the authorization token that it received during the authorization phase. When the target endpoint receives the authorization token, it attempts to validate the signatures against its list of available COI certificates received from the Authorization Service during the authorization phase.
If no match is found, then the endpoint does not honor the request. If a match is found, then the target endpoint responds positively to the initiating endpoint.
After the endpoint is authorized and successfully starts communication with the environment, it acquires its license and receives its Workgroup COIs and any associated filters from the Authorization Service.
Both sides log the successful initiation of a tunnel, including the identification of the users.
- Session Termination
When the Stealth software is installed on an endpoint, a minimal set of
infrastructure information is also included that provides registration information to the Authorization Service. Using policies established during session initiation, the tunnels are created and terminated as needed.
If the Authorization Service detects that the connection is down for approximately 10 minutes, then the Authorization Service assumes the endpoint is offline and removes its session information and reclaims its license. If the endpoint
reconnects after this happens, then it is re-provisioned and its tunnels are closed and restarted.
In addition, the endpoint operating mode changes from Workgroup mode (which enables the endpoint to communicate with other endpoints that share COIs) to Service mode (using the Service Role). In Service mode, the endpoint attempts to retrieve its workgroup COI information from an Authorization Service using its
3.4.5. SCIP/IPsec Session Source IP Address
Stealth does not arbitrarily choose the source IP address for the SCIP/IPsec sessions.
Instead, the source and destination IP addresses are established by the IP address of the frame that triggered the creation of the SCIP/IPsec session.
The source IP address of an outbound frame can be determined by an application, or it can be determined by the IPv4 stack when the application does not explicitly set the source IP address. Note that when there are multiple IP addresses per NIC in a configuration, the source IP address of an outbound frame may not necessarily be the primary (or first) IP address configured on the NIC.
3.5. Filtering
Notes:
• Using ambiguous filters or filter rules can lead to unpredictable results. (An ambiguous filter is one whose rules overlap or contradict one another.) For example, you should not create a filter that both allows and denies the same TCP port (such as Allow IP range=<IP address>, TCP Port=* Except=20, TCP Port=20). In another example, you should not create a filter where there is overlap between the exception list and the allowed ports (such as Allow IP range=<IP address>, TCP Port=10-20:20-30 Except=20:24-27, TCP Port=*:25-28).
• You cannot filter UDP ports that are used for Stealth communications. See 6.4 Updating Firewall Settingsfor more information about the ports and protocols used by Stealth.
After you configure COIs and roles, you can configure filters to refine the networking endpoint traffic that is allowed or denied using that COI or for that role. You can apply filters and qualifiers to individual IPv4 addresses or to address ranges.
To configure filters, you can specify the following:
• Filter Qualifier – A filter qualifier specifies a list of IP address exceptions and the port or protocol ranges allowed for a qualified filter.
• Filter List – A filter list is a list of qualified filters (IPv4addresses or ranges, with optional qualifiers), a list of filter lists, or a mix of qualified filters and filter lists.
• Filter Set – A filter set is a group of filter lists, with each list configured in a certain order and each set defined as either Allow or Deny. (The order of filter lists in the filter set determines the order in which the filter lists are processed.)
You apply filter sets to COIs and roles.
Note: You can apply only one filter set to each role as a clear text filter, and you can apply only one filter set to each COI (that is used in each role) as a Stealth filter. You
can apply different filter sets to different roles as clear text filters, and if a COI is used in multiple roles, you can apply different filter sets as Stealth filters to the COI in each role where it is used.
However, if the same user or group is assigned to multiple roles, you must apply the same filter set as a clear text filter to each role. (If you apply different filter sets, and if those filters conflict, this can result in unpredictable behavior as to which clear text filter is applied.)
3.5.1. Filters Applied to COIs or Roles
Filter sets work differently, depending on whether they are applied to COIs or roles, as follows:
• Stealth filters are filter sets that are applied to COIs. You use Stealth filters to control Stealth-enabled network traffic, allowing or denying information passed between Stealth endpoints that share COIs.
You can apply only one filter set to a COI (that is used in each role).
Note: If a COI is used in multiple roles, you can apply different filter sets to the COI in each role where it is used; however, it is a best practice to always apply the same filter set to the COI, regardless of which roles it is used in.
You can add as many filter lists to a filter set of one type (either Allow or Deny) as are required.
• Clear text filters are filter sets that are applied to roles. You use clear text filters to control clear text network traffic, allowing or denying information passed between Stealth endpoints and non-Stealth-enabled (clear text) components.
You can apply only one filter set to a role.
You might need to apply filter sets to roles if you have infrastructure servers that are not running Stealth endpoint software, but that your Stealth endpoints need to
communicate with. For example, if you have an Active Directory (AD) server that is not running Stealth endpoint software, create a filter set that includes a filter list with the IP address of that AD server, and apply it to the roles that include users who must be allowed to communicate with the AD server. In this case, the clear text filter enables network traffic to pass between the Stealth-enabled endpoint and the AD server using the specified IP address.
You can add as many IP addresses to the filter lists (which are included in one filter set) as are required to ensure that the users in the role can communicate with the infrastructure servers that are not running Stealth endpoint software.
3.5.2. Allow and Deny Filters
Filter sets are categorized as Allow or Deny filters, and you can apply either Allow filter sets or Deny filter sets to a COI or role. Filter sets applied to roles are checked before filter sets applied to COIs.
• Allow Filter
When you apply an Allow filter set to a COI, (Stealth filter), you specify rules for filtering the network traffic to be allowed. Messages that meet the filter criteria are transmitted using a Stealth tunnel. If the filter criteria are not met, then the data is discarded.
When you apply an Allow filter set to a role (clear text filter), you specify rules for filtering the network traffic to be allowed. Messages that meet the filter criteria are transmitted to or from the clear text network. If the filter criteria are not met, then the data is transmitted using a Stealth tunnel. No frames are discarded.
• Deny Filter
When you apply a Deny filter set to a COI (Stealth filter), you specify rules to filter network traffic to be denied. Messages that meet the filter criteria are discarded. All other traffic is sent using a Stealth tunnel.
When you apply a Deny filter set to a role (clear text filter), you specify rules to filter network traffic to be denied. Messages that meet the filter criteria (that match the deny filter) are transmitted using a Stealth tunnel. All others are transmitted to or from the clear text network.
Caution
An Allow filter set has a default behavior of deny; that is, any condition that does not match the allow filter is denied by default. In the same way, a Deny filter set has a default behavior of allow, so that any condition that does not match the deny filter is allowed.
A filter match is made in the context of the message direction. From the endpoint perspective, the filter is applied against the IP address source of the incoming messages and against the IP destination of outgoing messages.
3.5.3. Local and Remote Port Filtering
Stealth uses Local and Remote port filtering, which means that filters are managed for both the source and destination ports. You use Local and Remote port filtering for both Stealth filters (which are applied to COIs) and clear text filters (which are applied to roles).
Local and Remote port filtering works as follows:
• Local
- Outbound – Source port
- Inbound – Destination port
• Remote
- Outbound – Destination port - Inbound – Source port
You enter Local and Remote port filters like the following:
• Include/Exclude: Select whether to Include or Exclude the ports.
• Protocol: Enter a wildcard (*), TCP, UDP, or a value between 1 and 254.
• Local Port: Enter a wildcard (*), a single port between 1 and 65535, or a range of ports (separated by a hyphen).
• Remote Port: Enter a wildcard (*), a single port between 1 and 65535, or a range of ports (separated by a hyphen).
• Excepts: Create exceptions within a valid port range.
When you enter a local and remote port (or range) in one filter, it is treated as an and condition (that is, the filter matches if both the local and remote ports match). For
example, if you create an Include filter with a local port value of 80 and a remote port value of 100-300, the filter will match if the local port is equal to 80 and the remote port is in the range between 100 and 300.
3.5.4. Filter Qualifiers
In addition to the Allow and Deny behavior, you can use filter qualifiers to specify individual protocols and ports to include or exclude from a filter. A filter qualifier specifies a list of IP address exceptions and the port or protocol ranges allowed for a qualified filter.
The qualifiers you enter depend on the type of Local and Remote port filters you entered.
That is, if you enter a wildcard value for both the local and remote port, then you can enter any of the following:
• A qualifier for the local port and the remote port
• A qualifier for the local port only
• A qualifier for the local port only