This section identifies and references the Centralized Data Center (CDC) scenario to illustrate how the security design process was used to mitigate the risks of data compromise. Architecture DesignThe following section illustrates the process followed for the CDC scenario. To obtain the complete picture of the design process, it is important to have an understanding of the documentation provided in the Planning Guide, specifically the Lab Implementation of Windows Server System Reference Architecture document. The result of this process was a complete security zone design that was used to plan the complete CDC scenario infrastructure as built and tested in the test labs. Technical RequirementsThe security team wanted to minimize the risk of attack to the infrastructure and its resources. To help achieve this, the following requirements were identified: | • | All services must be highly available. | | • | Network services must be secure end-to-end, including communications that traverse the Internet. | | • | All network communications that are not explicitly allowed must be denied. | | • | All services must use a central authentication mechanism. | | • | All applications must be authenticated and auditable. | | • | Centralized management capability. | | • | Service health monitoring to prevent costly downtime. | | • | Data integrity must be guaranteed as uncompromised end-to-end. |
These requirements were set and agreed upon by all members of the design team at the beginning of the design process. Desired OutcomeThe desired outcome for the CDC design process was to create an infrastructure that meets the technical requirements of an organization and adheres to the security requirements of the Architecture Blueprints. Once the requirements and desired outcome had been defined, the SRMD process was started. This process was used to assess and attempt to value the security requirements of the various tiers and data types within the proposed infrastructure. ProcessThe SRMD process was used to illustrate the design and implementation of the Wingtip Toys example. For the CDC design process, only the most relevant procedures of SRMD were applied. This approach was taken because the WSSRA implementation is a lab instantiation of the overall WSSRA architecture; therefore, mitigation of every risk present in the environment would be of little practical value. The security team mainly focused their efforts on the following aspects: | • | Network security, primarily for external penetration attacks. | | • | Active Directory service policies. | | • | Host-hardening and IPSec policies, which are currently out-of-scope for this release. |
Service-specific details are available in the "Security" section in each of the Service Blueprints. The following sections illustrate how security was implemented in the CDC design. Asset Assessment and ValuationThe “Asset Assessment and Valuation,” “Data Classification,” and “Tier Classification” lists identified in the “Enterprise Design” section in this blueprint were used directly in the CDC design process. Tier Identification ListThe following table lists the tiers identified for deployment in the CDC design scenario. Firewall (public) | Enforces security policies to protect assets that are available to untrusted public users. | Primary | This tier is a core part of the corporate security enforcement mechanism. While it publishes publicly accessible data to non-trusted clients, it contains highly restricted configuration data. | Firewall (semi-trusted) | Enforces security policies to protect assets that are available to semi-trusted users, such as employees. | Primary | This tier is a core part of the corporate security enforcement mechanism. While it publishes publicly accessible data to semi-trusted clients, it contains highly restricted configuration data. | Firewall (trusted) | Enforces security policies to protect assets that are available to trusted internal users. | Primary | This tier is a core part of the corporate security enforcement mechanism. While it publishes privately accessible data to semi-trusted or trusted clients, it contains highly restricted configuration data. | External Proxy/Cache | Allows internal authenticated users or internal proxied access to the Internet. | Support | This tier is a secondary part of the corporate security enforcement mechanism. While it publishes publicly accessible data to semi-trusted or trusted clients, it contains highly restricted configuration data. This tier was consolidated with the Firewall (semi-trusted) tier. | Remote Access | Allows external authenticated users to access corporate networked services. | Primary | This tier provides a mechanism for users to connect securely to corporate services from remote locations. This service extends the core network service to encompass remote clients and facilities. | Perimeter Application | Provides business logic to Web services available to the public. | Support | This tier enhances Web service availability and scalability and adds additional Web services functionality. | Perimeter Web | Provides Web services to the public. | Isolated | While the data here is intended to be publicly accessible, its unauthorized modification could affect the organization’s reputation. | Perimeter DNS | Provides DNS services to advertise and resolve publicly available namespaces. | Primary | While the data here is intended to be publicly accessible, its unauthorized modification could affect the organization’s reputation. In addition, it could create confusion for end users if the DNS cache were "poisoned" to redirect visitors to a Web site other than Contoso, which could have long-lasting negative repercussions. | Perimeter Directory | Provides Active Directory service to centralize security policy enforcement and management access. | Support | This tier provides a mechanism for managing, deploying, and centralizing security policies across tiered services in the perimeter network. No user accounts (other than a few for administrative purposes) are contained within this directory. | Perimeter Backup | Repository to facilitate data and configuration backup to the internal backup service. | Support | Rather than pulling data from each server or tier in the perimeter directly to the internal backup system, this tier aggregates the backup function for simplification of security policies. | Perimeter Management | Provides centralized management of perimeter tiers. | Primary | This tier provides for perimeter tier management. It has access to all other internal tiers so unauthorized modification of data or unauthorized users gaining access to this tier could have an adverse impact within the organization. | Network Switching and Routing | Enables internal connectivity and enforces security policies to protect assets that are available to the trusted internal user. | Primary | This tier is a core part of the corporate security enforcement mechanism. While it publishes publicly accessible data to untrusted clients, it contains highly restricted configuration data. | Internal SQL | Provides storage availability for data records of all applications. | Primary | This tier contains information that is accessible to internal applications. Unauthorized modification of data could have an adverse impact on the organization. | SQL | Provides storage availability for data records of all applications. | Primary | This tier contains information that is accessible to internal and external applications. Unauthorized modification of data could have an adverse impact on the organization. | Internal Proxies and Access | Enforces security policies on users’ Internet access. | Support | This tier is a secondary part of the corporate security enforcement mechanism. While it publishes publicly accessible data to semi-trusted or trusted clients, it contains highly restricted configuration data. | Internal File and Print | Enables centralized storage of user data and administration of all print spools and printers. | Primary | This tier contains information that is accessible to all internal users of the organization. Unauthorized modification of data could have an adverse impact on the organization. | Internal Directory | Provides Windows Server 2003 Active Directory for internal usage. | Support | This tier contains information that is accessible to all internal users of the organization. Unauthorized modification of data could have an adverse impact on the organization. This directory contains internal user and computer accounts only; there are no perimeter accounts or computers in this directory. | Internal Backup | Provides a repository to facilitate data and configuration backup of all internal tiers. | Primary | This tier contains archive copies of data from all tiers. Loss of this tier could have an adverse impact on data integrity. | Internal Name Services | Provides DNS and WINS for internal usage. | Support | This tier contains information that is accessible to all internal users in the organization. Unauthorized modification of data could have an adverse impact on the organization. | Internal Application | Provides business logic to Web services available to internal users. | Support | This tier enhances Web service availability and scalability and adds additional Web services functionality. | Internal Web | Provides Web services to internal users. | Support | The data here is intended to be internally accessible. Unauthorized modification of data could have an adverse impact on the organization. | Internal Certificate | Provides certificate and PKI services to other services and internal users. | Primary | This tier contains information that is accessible to all internal users and services of the organization. Unauthorized modification of data could have an adverse impact on the organization. | Internal Management | Provides centralized management of internal tiers. | Primary | This tier provides the ability for internal tier management. This tier has access to all other internal tiers; unauthorized modification of data or unauthorized users gaining access to this tier could have an adverse impact on the organization. | Internal Deployment | Provides centralized deployment of internal tiers and hosts the server images and software libraries. | Primary | This tier provides for centralized deployment of servers in the internal tier. It has access to all other internal tiers; unauthorized modification of data or unauthorized users gaining access to this tier could have an adverse impact on the organization. | Client | Internal client access tiers. | Isolated | The client tiers in the organization contain information that is accessible only to them and the authorized administrative staff. The organization has a policy that all client tiers will maintain their data on servers within the organization rather than on the local hard drive, although user profile information is still stored locally. |
Table 18. Tier Identification List for the CDC Scenario Asset Valuation ListThe next step in the design process was to assign an asset value for each tier. To help simplify this process the CDC design team consolidated the list by aggregating similar tier functions and by taking into account the tier and data classifications; this provided a smaller, more manageable security working set. Important: To complete the financial information in the following two tables the project team had to create values that the Contoso organization would have used. Due to the fact that these values are designed to illustrate the cost of a risk to an organization that the lab instantiation would not face, the project team decided not to publish the values. The process is the important element of this blueprint and it was felt that the publication of fictitious numbers could serve to distract from the process that was followed.
For a real world implementation of a CDC type environment it is strongly recommended that the process be executed and the values completed. The tables used by the project team have been included as job aids for future implementations. It is only by completing this process can an organization gain a realistic view of the cost associated with a risk. Firewall (public) Firewall (semi-trusted) Firewall (trusted) External Proxy/Cache | Firewall (primary) | | | | | | Remote Access | Remote Access | | | | | | Perimeter Application Perimeter Web Perimeter DNS | Perimeter Web, Application, and DNS | | | | | | Perimeter Directory Perimeter Backup Perimeter Management | Perimeter Directory, Backup, and Management | | | | | | Network Switches & Routing | Network Switching and Routing | | | | | | Internal Application Internal Web | Internal Web and Application | | | | | | Internal Directory Internal Certificate Internal Name Services Internal Proxies & Access | Internal Directory, Certificate, Name, and Proxy | | | | | | Internal Backup Internal Deployment Internal Management | Internal Backup, Deployment, and Management | | | | | | Internal SQL SQL Internal File & Print | Data (SQL) and Internal File and Print | | | | | | Storage Devices and Switching | Storage Device and Switching | | | | | | Client | Out of scope | | | | | |
Table 19. Consolidated Asset Value for the CDC Scenario Asset Prioritization ListThe final table lists the CDC working set with the template for the annual overall asset value and priorities. Once these have been completed for your implementation the design team can make informed decisions on the priority and resources to allocate to each component of the working set. Firewall (primary) | | | Remote Access | | | Perimeter Web, Application, and DNS | | | Perimeter Directory, Backup, and Management | | | Network Switching and Routing | | | Internal Web and Application | | | Internal Directory, Certificate, Name, and Proxy | | | Internal Backup, Deployment, and Management | | | Data (SQL) and Internal File and Print | | | Storage Device and Switching | | |
Table 20. Asset Priority Job Aid for the CDC Scenario The security team used the values generated in this section to determine which assets to secure first and the amount of mitigation effort they wanted to expend for the identified vulnerabilities to each asset. Security Risk IdentificationThe Vulnerability Assessment, Risk Assessment, and Analysis and Remediation processes were not carried out because the implementation was only a lab instantiation of the overall WSSRA architecture. The project team recommends the SRMD provided in Chapter 3 of the Securing Microsoft Windows 2000 Server solution guide. The following sections illustrate the remaining steps of the security architecture planning process used in the CDC scenario. The WSSRA security team focused on the following aspects: InputThe following inputs were used in the security architecture planning process: | • | Security zone definitions and restrictions: Security administrators defined security zones to help plan the security policies. As described in the “Architecture Definition” section, security zones provide logical containers to which security policies and mitigation strategies can be applied. | | • | Services worksheet - service consumer information: In conjunction with the network design team, a master worksheet was developed to gather service-specific requirements that affected the network and security architectures. | | • | Directory service policies: In conjunction with the directory service designer, Active Directory security policies were defined for each of the CDC services. | | • | Industry standard network boilerplates: In conjunction with the network design team, industry standard router and switching ACL “best practice” boilerplates were created to be applied to the routing and switching network devices. Note: For more information, refer to the Network Architecture Blueprint and the Directory Service Blueprint. |
OutputFollowing were the outputs of the security architecture planning process: | • | Security zone definitions and restrictions: First, the security administrator defines zones that group policies and strategies in the best possible manner according to the data and tiers to be protected. Second, the security administrator specifies the restrictions that apply to the tiers in these zones and the intra-zone and inter-zone communications. These definitions and restrictions are also used as an input to the network design team to define the VLAN architecture and the ACLs of VLAN and selected high-risk hosts. | | • | VLAN matrix: This matrix was produced by reconciling the Security zone definitions and restrictions with the services worksheet. This matrix was used as the base for defining VLAN security. | | • | Network security matrix: This matrix was produced by reconciling the service and host required ports and protocols from the service worksheet in combination with the industry standard network boilerplates. This matrix defined the balance of the network security. | | • | Directory service policies: These policies were derived by adopting the Microsoft Security Polices as the base and construction of WSSRA overrides for service-specific issues and lockdowns not covered in the base policies. Note: For samples of these worksheets and matrices, refer to the "Appendix" section at the end of this blueprint. For network configuration and directory policy files, refer to the \NetConfigs and \Security Policies folders in the Deployment Kit. For more information, refer to the Windows Server 2003 Security Guide at:
http://www.microsoft.com/technet/security/prodtech/windowsserver2003/W2003HG/SGCH00.mspx |
Security Zone Definitions and RestrictionsThe SRMD process can be used in conjunction with the security zones defined within the organization to assist in determining the number of zones best suited for the environment. Security Zone DefinitionsIn the CDC scenario, the security administrator defined a number of zones to ensure protection of the organization's IT assets. The following figure depicts the security zones and tiers defined for the scenario. The following table lists the zones for the CDC design process. Public | None (it is the Internet) | None | Private | Border Public, Perimeter, Border Trusted, Internal, and Client | None | Border (untrusted) | None | Perimeter Firewalls (untrusted and semi-trusted) | Perimeter | Perimeter Information Services, Perimeter Name Services, Perimeter Information Infrastructure, Perimeter Proxy Service, and Perimeter Remote Access | None | Perimeter Information Services | Perimeter Web Services | Perimeter Application | Perimeter Web Services | None | Perimeter Web | Perimeter Name Services | None | Perimeter DNS | Perimeter Information Infrastructure | None | Perimeter Directory, Perimeter Backup, and Perimeter Management | Perimeter Proxy Service | None | External Proxies | Perimeter Remote Access | None | VPN | Border (trusted) | None | Internal Firewalls | Internal | Corporate | None | Corporate | Corporate Database, Corporate Infrastructure, Corporate Management, Corporate Internal Applications, and Corporate Access | None | Corporate Database | Private SQL | Read-only SQL | Private SQL | None | Internal SQL | Corporate Infrastructure | None | Internal Proxy and Access, File and Print, and Internal Directory | Corporate Management | None | Internal Backup and Internal Management | Corporate Internal Applications | Corporate Web Services | Internal Applications | Corporate Web Services | None | Internal Web | Corporate Access | None | Internal Access | Client | None | Contains LAN-based client workstations. |
Table 21. Security Zone Information for the CDC Scenario The design team used the following reasoning to justify the creation of these zones: | • | Public zone: In the CDC scenario, the Internet and its connection to the external interface of the organization's border routers are defined as the Public zone. Customers accessing the CDC Web servers and remote employees connecting to the CDC network through a VPN are parts of this zone. | | • | Private zone: This zone contained all CDC scenario connectivity tiers, application tiers, and network segments connected to the internal side of the organization's Internet-connected routers. The purpose of this zone was to separate the internal network traffic from the traffic to and from the Public zone. The boundary between the Private and Public zones was a router on which OSI model layer 3 ACLs were implemented to control inbound traffic, as sanctioned by the scenario’s enterprise security policy. The Private zone was comprised of the Border Public, Perimeter, Border Trusted, Internal, and Client zones. | • | Border Public (untrusted) zone: This zone contained tiers that perform some form of access control functionality that isolates the Public zone from the Perimeter zone. The CDC designers decided to place the border firewall tiers into a single zone to simplify management and creation of firewall rules for the inbound and outbound traffic of the Public zone. | | • | Border Trusted zone: This zone also contained tiers that perform access control functionality, but here the Internal zone was isolated from the Perimeter zone. The trusted firewall tier was placed into this zone to simplify management and creation of firewall rules for inbound and outbound traffic of the Perimeter zone. | | • | Perimeter zone: This zone contained tiers that were bounded by some form of access control functionality that isolated the Public zone from the Perimeter zone and the Perimeter zone from the Internal zone, thereby also isolating the Internal zone from the Public zone. The purpose of this zone was to facilitate the creation of security polices within the CDC design so that traffic could be filtered between the Public and Internal zones. This zone was referred as the Perimeter network (also commonly known as a “DMZ” or “screened subnet”) by the design team because it existed between the public network and the internal network and held semi-trusted information. This zone contained tiers that provided public-facing services, such as DNS, application, and Web services. Any tier in this zone had either a public IP address or a tier that provided network address translation (NAT). The services provided on the tiers in this zone were considered public because users from the Public zone had some kind of access to them. While access control tiers were implemented between the Public and Perimeter tiers, tiers in the Perimeter zone were still likely to be the first-level targets for malicious attacks. The Perimeter zone was further subdivided into the following additional zones: | • | Perimeter Information Services zone: This zone contained one tier called the Perimeter Application tier and a sub-zone for Web services. This zone existed so that access controls could be implemented to control the flow of traffic between this zone and the Public zone. While the designers considered placing the Web and Application tiers into the Perimeter zone without subdividing it further, they wanted to control traffic differently between the Public zone and the Perimeter Information Services tiers from the way it was controlled between the Public zone and the Perimeter Web tier; this allowed for more restrictive port filters to the Perimeter Web Services zone. Therefore, a zone was created for each group of tiers. | | • | Perimeter Web Services zone: This zone contained one tier called the Perimeter Web tier. This zone existed so that more granular access controls could be implemented to control the flow of traffic between this zone and the Public zone. The designers considered placing this tier into the Perimeter Information Services zone without subdividing it further; however, the designers wanted to restrict traffic to the Web tier to a greater degree than that of the Application tier. Therefore, a nested zone was required. | | • | Perimeter Name Services zone: This zone contained one tier called the Perimeter DNS tier. It was decided that the CDC scenario would host the organization’s own DNS rather than using its ISP’s DNS, which allowed for higher flexibility and self-reliance. This zone was created so that access controls could be implemented to control the flow of traffic between this zone and the Public zone. While the designers considered placing all tiers into the Perimeter zone without further subdivision, they wanted to control traffic differently between the Public zone and the Perimeter DNS tier from the way it was controlled between the Public zone and the Perimeter Web and Application tiers. Therefore, a zone was created for each group of tiers. | | • | Perimeter Information Infrastructure zone: This zone contained three tiers, all necessary to the operation and management of the perimeter services that are publicly accessible. These tiers were Perimeter Backup, Perimeter Directory, and Perimeter Management. This zone existed so that controls could be implemented to manage access to and from these infrastructure assets, and deny direct access from the Public zone. | | • | Perimeter Proxy Service zone: This zone contained one tier called the External Proxies tier. The designers decided to use a two-tier proxy architecture whereby internal clients communicated to an internal proxy service; this zone received requests from the internal proxies and retrieved the requested information from the Internet. | | • | Perimeter Remote Access zone: This zone contained one tier that provided remote access to internal resources. The tier was called VPN and was necessary to connect remote sites and users to the Internal zone. |
| | • | Client zone: This zone contained the client tiers in the organization. While the designers could have further subdivided the Client zone, there was no such technical requirement at this time. Note: Remote clients accessing the network through a VPN connection were considered part of the Client zone once they were authenticated. | | • | Internal zone: The purpose of the Internal zone was to isolate the tiers running the organization’s internal services and clients from the Public and Perimeter zones. For this release, this zone contained only the Corporate zone, but the design was created to allow this zone to be expanded to contain other data center scenarios as required. | • | Corporate: The purpose of this zone was to separate the enterprise servers from the clients. Studies show that a majority of security breaches originate internally; therefore, the CDC design team defined this zone so that it could implement access control mechanisms to control the flow of traffic between tiers in this zone and the tiers in the Client zone. In addition, this zone kept the Perimeter zone tiers separated from the other tiers in this zone. While the designers could have simply implemented access control mechanisms between the Client and Corporate zones, they wanted to achieve more granular control capabilities in implementing different types of traffic flow; therefore, the WSSRA security team divided the Corporate zone into the following additional security zones: Corporate Database: This zone contained the Corporate Database tier and the Private SQL zone. The purpose of this zone was to enable implementation of access control mechanisms between itself, the Perimeter zone, and the Client zone where queries and updates originate. The Private SQL zone was created within the Corporate Database zone to allow granular access control for sensitive internal data; this zone, in turn, contained a single tier called Internal SQL. Corporate Infrastructure: This zone contained the Internal Directory, Internal Name Services, File and Print, and Internal Proxy and Access tiers. The purpose of this zone was to enable the implementation of an access control mechanism between itself, the Client zone, and the Perimeter zone. While the designers considered implementing this mechanism between the Client and Corporate zones, a more granular level of control was required for the different types of zones contained within the Corporate zone to the Perimeter and Client zone. Corporate Management: This zone contained the tiers necessary for the management, deployment, and availability of all the systems in the Corporate zone. It encompassed the Internal Management and Internal Backup tiers. Placing these tiers into their own zone simplified the creation of their access rules. These tiers required access to all other tiers in the Corporate zone. Corporate Internal Applications: This zone contained the Internal Applications tier and a sub-zone for internal Web services. The applications running on the hosts in these tiers were required to be accessible from the tiers in the Perimeter zone. Therefore, the level of granularity in access control to these tiers required the creation of this zone to prevent external exposure of other zones in the Corporate zone. Corporate Web Services zone: This zone contained one tier called the Internal Web tier, which provides for the implementation of more granular access controls to control the flow of traffic between itself and the Perimeter zone. The designers considered placing the Internal Web tier in the Internal Applications zone without further subdivision. However, they wanted to restrict traffic to the Internal Web tier more than the traffic to the Internal Applications tier; hence, the requirement for an additional zone. Corporate Access zone: This zone contained a single tier called the Internal Access tier. As queries to this tier originate from the Perimeter Remote Access zone, the original architecture design specified this as a zone requirement. When it came to the specific implementation of the CDC deployment, the design was reviewed and the network design team consolidated this zone within the Corporate Infrastructure zone and complied with the security requirements of the scenario through the use of host-based ACLs. This design update was made as the number of hosts required in this Internal Access tier did not warrant the overhead of an entire security zone. It was consolidated into the Corporate Infrastructure zones because of the direct dependency on the servers in the Internal Directory tier. |
|
|
Security Zone RestrictionsOnce the security zones for the CDC scenario were defined, the following communication and restriction requirements were identified: | • | Tier restrictions within a zone | | • | Intra-zone tier communications | | • | Inter-zone communications |
The following sections discuss these requirements. Tier Restrictions Within a ZoneThe CDC design imposed restrictions at multiple layers to comply with the defense-in-depth approach. The following table lists the restrictions imposed on the tiers in the CDC scenario design, but does not list the restrictions imposed on the network layer; they are addressed in the following sections. For full details of these restrictions, refer to the Implementation Guides. Perimeter | Undesired TCP/UDP port access to tiers. | All components of the tiers in this zone resided in access-controlled rooms. | All tiers in this zone were deployed and maintained with the latest operating system service packs and hotfixes. | Before accessing any data on these tiers, users were authenticated by a combination of user name and password. In addition, the user name and passwords transmitted to these tiers were encrypted. | Any applications (packaged or developed in house) on these tiers were deployed and maintained with the latest service packs and hotfixes. Only those applications and services necessary for the proper functioning of the services within this zone were enabled; in addition, they adhered to Contoso application security guidelines (not included in this blueprint). All servers within this zone were members of the Windows Server 2003 Active Directory domain. Security templates were used to limit services running on these servers to only those that were necessary for the proper functioning of the operating system and to provide the functionality for which the server was implemented (for example, the DNS service on DNS servers). | Perimeter Information Services | Undesired TCP/UDP port access to tiers. Buffer overflows. Format string attacks. | | The operating system was configured to perform TCP/IP port filtering, allowing only ports 80 and 443 inbound from the Public zone. | | The Web server (Internet Information Server) was configured to service requests only through necessary methods (for example, HTTP and ASP); all others were disabled using the IIS lockdown process. | Perimeter Web Services | Undesired TCP/UDP port access to tiers. Buffer overflows. Format string attacks. | | The operating system was configured to perform IPSec port filtering; allowing only ports 80 and 443 inbound from the Public zone. | | The Web server (IIS 6.0) was configured to service requests for static content and file types only. | Perimeter Name Services | Undesired TCP/UDP port access to tiers. Unauthorized zone transfers. | | The operating system was configured to perform IPSec port filtering; allowing only protocol UDP and port 53 inbound from the Public zone. | | The DNS server was configured to only answer recursive requests for the zones for which it is the source of authority (SOA). | Internal | Undesired TCP/UDP port access to tiers. | All components of the tiers in this zone resided in access-controlled rooms. | All tiers in this zone was deployed and maintained with the latest operating system service packs and hotfixes. | Before accessing any data on these tiers, users were authenticated by a combination of user name and password. In addition, the user name and passwords transmitted to these tiers were encrypted. | Any application (packaged or developed in house) on these tiers was deployed and maintained with the latest service packs and hotfixes. Only those applications and services that were necessary for the proper functioning of the service were enabled. | Corporate | | | | | All servers within this zone were members of the Windows Server 2003 Active Directory domain. Security templates were used to limit services running on these servers to only those necessary for proper functioning of the operating system and for providing the functionality for which the server was implemented (for example, the DNS service on DNS servers). | Corporate Internal Applications | Undesired TCP/UDP port access to tiers. Buffer overflows. Format string attacks. | | | | The Web server (IIS 6.0) was configured to service requests only through necessary methods; all others were disabled through IIS lockdown. | Corporate Web Services | Undesired TCP/UDP port access to tiers. Buffer overflows. Format string attacks. | | | | The Web server (IIS 6.0) was configured to service requests for static content and file types only. |
Table 22. Tier Restrictions in the CDC Scenario The network layer is addressed in the following section on intra-zone and inter-zone communications. Intra-zone CommunicationsIn the CDC design it was decided to not restrict the intra-zone communications at the policy level. Instead, the restrictions were applied at a host level using host-based ACLs. Inter-zone CommunicationsThe following table lists the communication that was allowed between various security zones in the CDC scenario. Public | Private | Undesired TCP/UDP port access to tiers. | A device that performs the function of application-layer proxy firewall was placed at the network layer between these two zones because the risk analysis identified this area as a high priority risk. Communication between these zones is the first opportunity for an attacker to infiltrate the CDC network; therefore, the organization chose to implement a firewall. To mitigate the risk further, it chose to force the usage of a single function firewall device, which does not perform the firewall function between any other zones. In addition, it required a firewall device that could provide the application layer proxy function to mitigate the risk of attackers using Trojan software on the servers that listen on allowed ports in this zone. The application layer proxy firewall will drop traffic on allowed ports if it is not the intended type of traffic on the allowed port (for example, HTTP traffic for Web servers). Last, the device serving the firewall role also provided the NAT function. As an additional mitigation strategy, the WSSRA security team wanted to shield the organization’s internal addressing scheme from the Public zone. | Public | Perimeter Information Services | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow only over TCP ports 80 (HTTP) and 443 (HTTPS) between these zones and only in the direction specified by the source and destination zones. | Public | Perimeter Web Services | Undesired TCP/UDP port access to tiers. | Traffic is allowed to flow only over TCP ports 80 (HTTP) and 443 (HTTPS) between these zones and only in the direction specified by the source and destination zones. | Public | Perimeter Name Services | Undesired TCP/UDP port access to tiers. Unauthorized zone transfers. DNS poisoning. | Traffic was allowed to flow only over UDP port 53 (DNS) between these zones and only in the direction specified by the source and destination zones. (Note: TCP port 53 was closed to prevent zone transfers and other DNS poisoning attacks. As this tier was the source of authority for the zones, responses did not go beyond the 64-byte UDP query reply limitation.) | Public | Perimeter Remote Access | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow only over ports 500 (IPSec IKE) and protocol 50 (IPSec), 1701 (L2TP), 1723 (PPTP), and 4500 (IPSec NAT-T), and only in the direction specified by the source and destination zones. | Perimeter Remote Access | Public | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow only over ports 500 (IPSec IKE) and protocol 50 (IPSec), 1701 (L2TP), 1723 (PPTP), and 4500 (IPSec NAT-T), and only in the direction specified by the source and destination zones. | Perimeter Remote Access | Corporate Access | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow only over TCP ports 1812-1813 for RADIUS authentication requests between these zones and only in the direction specified by the source and destination zones. | Perimeter Proxy Service | Public | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow over any TCP or UDP port between these zones but only in the direction specified by the source and destination zones. | Perimeter Information Services | Perimeter Information Infrastructure | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow only over a private network between these zones and only in the direction specified by the source and destination zones. | Perimeter Information Infrastructure | Perimeter Information Services | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow only over a private network between these zones and only in the direction specified by the source and destination zones. | Perimeter Name Services | Perimeter Information Infrastructure | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow only over a private network between these zones and only in the direction specified by the source and destination zones. | Perimeter Information Infrastructure | Perimeter Name Services | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow only over a private network between these zones and only in the direction specified by the source and destination zones. | Perimeter | Internal | Undesired TCP/UDP port access to tiers. | A physically separate and dedicated stateful inspection firewall was necessary to filter all traffic flowing between these two zones bidirectional. This design provided a centralized point of security enforcement. | Corporate Infrastructure | Perimeter Name Services | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones but only in the direction specified by the source and destination zones. This design was used for DNS zone updates to the publicly accessible DNS servers. | Corporate Management | Perimeter Information Infrastructure | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones but only in the direction specified by the source and destination zones. This was used to support Terminal Services from Internal to Perimeter as well as to retrieve Perimeter backups. | Corporate Infrastructure | Perimeter Information Services | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones but only in the direction specified by the source and destination zones. This design was used to support updates of the Public Key server. | Perimeter Information Services | Corporate Database | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow over TCP port 1433 (SQLnet) between these zones but only in the direction specified by the source and destination zones. | Corporate Management | Corporate Database | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones but only in the direction specified by the source and destination zones. | Corporate Management | Corporate Internal Applications | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones but only in the direction specified by the source and destination zones. | Corporate Management | Corporate Infrastructure | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones but only in the direction specified by the source and destination zones. | Corporate Internal Applications | Corporate Database | Undesired TCP/UDP port access to tiers. | Traffic was allowed to flow over port 1433 (SQLnet) between these zones but only in the direction specified by the source and destination zones. | Corporate Internal Applications | Corporate Infrastructure | Undesired TCP/UDP port access to tiers. | All traffic was allowed to flow between these zones. | Perimeter Remote Access | Corporate Infrastructure | Undesired TCP/UDP port access to tiers. | External proxies were allowed to pass responses back on any TCP or UDP high port >1024. | Client | Corporate | Undesired TCP/UDP port access to tiers. | The CDC designers had deemed it unnecessary to filter the traffic between these zones because there are many different types of communications that would be disrupted by filtering. | Client | Corporate Database Private SQL | Undesired TCP/UDP port access to tiers. | Only authenticated users may access this data. Traffic was allowed to flow over port 1433 (SQLnet) between these zones but only in the direction specified by the source and destination zones. This design approach allowed for database queries. |
Table 23. Inter-zone Communications Information for the CDC Scenario As stated earlier, this table does not provide details of all CDC security restrictions, but illustrates a sample of the data that was generated for this project. Full details of these communications are provided in the Implementation Guides, which contains the complete scenario-specific project details. These definitions should not be used only as a part of the project design but also as an ongoing document that is updated whenever new services or applications are added to the CDC environment. Services Worksheet—Service Consumer InformationThis worksheet was the result of a collaboration between the security and network design teams and the firewall service designer. The worksheet’s role was to gather the service-specific requirements from various service designers that would drive the overall network security design; this information was required for each network interface of the servers or network devices that the service introduced into the design. The following figures and requirement lists were given to the service designers as guidelines to facilitate consistent taxonomy in requesting their security and networking requirements: Note: Much of the following section applies to the network architecture. The project team decided to combine the collection and provisioning of the security and networking requirements to increase overall efficiency and consistency between the security and network architecture designs. Using these figures as common reference points, the service designers completed the service worksheet for their service. The following list is an example of the information that they had to provide in these documents: | • | Service definition: This was used to roll up all service requirements on a service-by-service basis. | • | Service name | | • | Service zone: Specify the security zone in which the device was to be placed. | | • | Device name | | • | Contact (e-mail alias) | | • | Service consolidation: Specify what other services were hosted by this device (for example, site-to-site and user VPN services were consolidated). |
| | • | Networking requirements: | • | Network segment: Specify what particular network segment, physical or virtual, the network or server network interface is placed at. A network segmentation diagram was provided for network segment IDs and device placement. | | • | Bandwidth: Specify the bandwidth required (for example, 10 Mbps, 100 Mbps, or 1000 Mbps) for the network interface. | | • | LoN participant (lights out): Specify whether this device participates in a lights-out or remote management access network through a dedicated network interface. | | • | DIP allocations (private or public): Specify the number of public or private dedicated IP addresses required for the network interface. | | • | IPSec offloading: Specify whether the network adapter needs to provide IPSec processing to reduce device CPU overhead. | | • | Data encryption: Specify if network packets needed to be encrypted. | | • | Register in DNS (internal or external): Specify whether this network interface needs to be registered in the internal or external (non-Internet, non-public) DNS; for example, the VPN back-end network interface needs to be registered in the internal DNS, whereas the front-end network interface needs to be registered into the external (Internet accessible, public) DNS. | | • | Packet trafficking (forwarding, recipient): Specify whether this network interface is a target or needs to forward BOOTP or DHCP or other requests. |
| | • | Routing requirements: | • | Internet access: Specify if this device requires public Internet access and business justification, because the security policy restricted data center servers from accessing the Internet directly. | | • | Destination service (list all services): List all services (represented by the Service zone code) with which the device needs to communicate; for example, the VPN service back-end network interface needs to communicate with the DNS and IAS services whereas the front-end interface needs to communicate with external clients or site-to-site VPN devices only. | | • | Required routing (list all services): Specify any segment or VLAN that the network or server device needs to route or have requests forwarded to. For segmentation and traffic path information, refer to the network segmentation figure. | | • | Open shortest path first (OSPF) routing: Specify if any OSPF routing needs to be enabled and configured for the device. | | • | Static routes (device): Specify if any static routes will be provided to the device and justification for this requirement. OSPF was provided by the networking devices to provide dynamic network routing; static routing was avoided because it does not provide a highly available solution. | | • | LMHOSTS lookup (device): Specify if a local LMHosts or Host file lookup needs to be enabled on the device and justification. The overall security and networking policies were to avoid host files as much as possible. |
| | • | Network load balancing and clustering requirements: | • | Virtual IP allocations (private or public): Specify the number of public or private virtual IP addresses required for the network interface. | | • | Virtual IP type: Specify the type of virtual IP required, whether it is for clustered or network load balanced devices or for content switching through a separate device. | | • | SSL offloading: Any service that needs to offload SSL processing to a load balancing network device needs to provide a certificate to enable this service. | | • | Load balancing type: Specify the type of load balancing required (for example, round robin, weighted, least connection, fastest, or custom). | | • | Persistence: Specify whether device persistence is necessary for the virtual IP (for example, cookie, session, SSL, or custom). |
| | • | Ports and protocol requirements: | • | Ports and protocols (application specific inbound, outbound): Specify all protocols required for the network interface or virtual IP and direction of traffic flow (for example, TCP, or UDP). | | • | Common ports and protocols (bidirectional): Specify what common ports are required by the service and device. |
|
This list generated a huge amount of information for each service during the CDC design process. The full details of this documentation for the services in the CDC scenario can be found in the service worksheets, which are provided as part of the Deployment Kit. VLAN Segmentation MatrixAfter reconciling the security zoning and the service requirements, the VLAN security ACLs could be defined. Cross referencing all source VLANs and segments to all destination VLANs and segments and then applying the type of network device that provided security provided the ability to generate a network segmentation matrix. The following table is a sample of the data that was generated and used in the CDC design; its key follows immediately after the table. This data is available in full from the ConfigurationMatrix.xls spreadsheet in the Implementation Guides. | Src | VLAN # | - | - | - | 517 | 518 | 519 | 523 | 524 | 316 | 317 | Internet Service Provider Upstream 1 | ISPU1 | - | - | D | R | D | D | D | D | D | D | D | Internet Service Provider Upstream 1 | ISPU2 | - | D | - | R | D | D | D | D | D | D | D | Internet Service Provider Downstream 1 | ISPD1 | - | R | R | - | D | D | D | D | D | D | D | Internet Service Provider downstream 2 | ISPD2 | - | R | R | D | D | D | D | D | D | D | D | Corporate Perimeter Front End (inbound) | CPFi | - | D | D | R | D | D | D | D | D | D | D | Corporate Perimeter Front End (outbound) | CPFo | - | D | D | R | D | D | D | D | D | D | D | Corporate Perimeter Screened Subnet (inbound) | CPSi | 512 | D | D | D | V | D | V | D | D | D | D | Corporate Perimeter Screened Subnet (outbound) | CPSo | 813 | D | D | D | D | D | D | D | D | D | D | Corporate Perimeter VPN | CPV | 802 | D | D | D | D | D | D | D | D | D | D | Corporate Perimeter Application | CPA | 516 | D | D | D | D | D | D | D | D | D | D | Corporate Perimeter Front End | CPF | 517 | D | D | D | - | D | D | D | D | D | D | Corporate Perimeter Backend | CPB | 518 | D | D | D | D | - | D | D | D | F | F | Corporate Perimeter DNS (answerer) | CPD | 519 | D | D | D | D | D | - | D | D | D | D | Corporate Perimeter Network Management | CPNM | 523 | D | D | D | D | D | D | - | D | D | D | Corporate Perimeter Remote Management | CPRM | 524 | D | D | D | D | D | D | D | - | D | D | Corporate Internal Application | CIA | 316 | D | D | D | D | F | D | D | D | - | D | Corporate Internal Front End | CIF | 317 | D | D | D | D | F | D | D | D | D | - | Corporate Internal Back End | CIB | 318 | D | D | D | D | D | D | D | D | D | D | Corporate Internal Infrastructure | CII | 311 | D | D | D | D | F | D | D | D | V | V | Corporate Internal Data Front End | CIDF | 319 | D | D | D | D | F | D | D | D | V | V |
Table 24. Network Segmentation Matrix for the CDC Scenario KEY | • | A): No ACL—allow all. | | • | D): No communication—deny all. | | • | F): Firewall rule is required to secure communications. | | • | R): Router ACL is required to secure communications. | | • | V): Switch VLAN ACL is required to secure communications. | | • | -): Not applicable. |
This table formed the basis of the network security requirements by proving the details of the type of security that was needed for each segment or VLAN. Network Security MatrixCombining the detailed port and protocol information from the service worksheets and the VLAN information from the previous Network Segmentation Matrix table provided the ability to generate the complete network security matrix. The following table provides a sample of how this information looked in the CDC scenario. | Source | Server Name | - | - | 516 | 517 | 317 | CIF VIP 10.1.17.170 | 318 | 311 | NA-DCi | IAS | 170.168.2.0/24 | ISPU1 | - | A | A | D | D | D | D | D | D | D | D | 170.168.3.0/24 | ISPU2 | - | A | A | D | D | D | D | D | D | D | D | 209.217.184.0/24 | ISPD1 | - | A | A | D | D | D | D | D | D | D | D | 205.46.134.0/24 | ISPD2 | - | A | A | D | D | D | D | D | D | D | D | 208.217.184.16/28 | CPFi | - | A | A | D | D | D | D | D | D | D | D | 208.217.184.32/27 | CPFo | - | A | A | D | D | D | D | D | D | D | D | 192.168.12.0/24 | CPSi | - | D | D | D | D | D | D | D | D | D | D | 192.168.12.76 & 77 | - | CP-FWPb | - | - | A | A | - | - | - | - | - | - | 192.168.13.0/24 | CPSo | - | D | D | D | D | D | D | D | D | D | D | 192.168.14.0/24 | CPV | - | D | D | D | D | D | D | D | D | D | D | 192.168.14.80 & 81 | - | VPNb | D | D | D | D | L4 | TCP:80 | D | L4 | D | UDP:1812-1813 | 192.168.16.0/24 | CPA | - | D | D | A | TCP: 80, 443, 8080-8085 | D | D | D | D | D | D | 192.168.17.0/24 | CPF | - | D | D | TCP: 80, 443, 8080-8085 | A | D | D | D | D | D | D | 192.168.19.0/24 | CPD | - | D | D | D | D | D | D | D | D | D | D | 10.1.25.0/24 | CPB | - | D | D | D | D | D | D | D | D | D | D | 10.1.25.14 & 15 | - | CP-DC | D | D | D | D | D | D | D | TCP: 464, 3268, 57903-57905 UDP: 123 | TCP: 464, 3268, 57903-57905, 389, 135, 445 UDP: 123, 389, 88 | TCP: 464, 3268, 57903-57905 UDP: 123 | 10.1.25.20 & 21 | - | CP-MGT | D | D | D | D | D | D | D | L4 | TCP: 464, 3268, 57903-57905, 389, 135, 445 UDP: 123, 389, 88 | D | 10.1.25.13 | - | CP-BAK | D | D | D | D | D | D | D | D | D | D | 10.1.25.22-25 | - | CP-WEB | D | D | D | D | L4 | TCP: 80, 443, 8100, 1810-1815 | D | D | D | D | 10.1.25.9,10-12 | - | CP-APP | D | D | D | D | L4 | TCP: 80, 443, 8100, 1810-1815 | D | D | D | D |
Table 25. Network Security Matrix for the CDC Scenario The process of creating this table was a collaborative effort between the network, security, and firewall design experts. The following key was used: | • | A): No ACL—allow all. | | • | D): No communication—deny all. | | • | L4): Host based security. | | • | -): Not applicable. |
The table is provided as part of the “Configuration Matrix” spreadsheet in the Implementation Guides because this data is highly specific to the requirements of the particular CDC scenario. Industry Standard Security and Network SettingsAt this point of the design, the security requirements for the CDC design have been defined and documented. However, in an area like computer security the nature of attacks and defenses keeps changing all the time. To help mitigate any current or future security risks, it is important that the design takes into account the latest industry guidance for security configuration settings and updates. Oftentimes this information is provided by the network device vendors or directly by network or security experts. Standard configuration, best practices, and guidelines can be found from the URLs listed in the “References” section in this blueprint. Once the latest security guidelines have been accounted for in the design, the process of creating the configuration files necessary to set up the various network devices and servers were created. Basic network traffic ACLs were added to the network security configuration files using the information from the previous tables. These were then uploaded to the network devices to provide the required network configuration for each device. As stated previously, the WSSRA security team’s primary focus was network penetration from the Public (untrusted) zone. The Perimeter zone had a significant number of ACLs applied, whereas the Internal zone had very few ACLs because this zone is typically very specific to an organization’s needs. These ACLs would need to be generated using a specific evaluation exercise to gather the explicit requirements for each application of the organization. The WSSRA security team decided not to apply explicit ACLs on every VLAN, segment, or host but rather to show the process that was performed for this release because each organization’s internal applications are tailored to their respective business needs and functions. Using this process and the sample data provided, the security team of future instantiations will be able to expand on this guidance to fulfill and document the security requirements of their specific instantiation. The configuration files that were created as part of the CDC implementation are available for download as part of the Deployment Kit.
| |
