JWP Whitepaper Hoehl Khalil

Implementing and Automating
Critical Control 19: Secure Network

Engineering
for
Next Generation Data Center Networks
STI Joint Written Project
Authors: Aron Warren, George Khalil, Michael Hoehl
Accepted:
Abstract
This document provides technical and best practice approaches to
implement and automate safeguards consistent with control 19,
Secure Network Engineering, of the SANS Twenty Critical Security
Controls for Effective Cyber Defense. The scope is the secure design of
cutting-edge high speed 40GbE networks designed to host Internet
facing web and mobile applications.
SANS JWP - Implementing and Automating Critical Control 16: Secure Network Engineering for
1. Executive Summary
People seem to want to treat computer security like it's rocket science or black magic. In
fact, computer security is nothing but attention to detail and good design.
Marcus J. Ranum
Next Generation networks will have to defend against many of the same threats
targeting todays networks. Modern reconnaissance, discovery, and mapping approaches
are versatile and just as effective at higher network speeds. The major difference is the
speed of exploitation. Whereas todays network may require a few days to complete a
multi-gigabyte data theft attack, poorly designed Next Generation 40 Gigabyte Ethernet
(40GbE) networks can facilitate this same exploit in just a few seconds. This condition
makes the requirement for secure network engineering vital for Next Generation
networks.
Network design is foundational to security controls. Incorporating safeguards at
this level is essential to prevent the circumvention of higher level controls. The first and
most fundamental requirement is to build a multi-tiered network architecture. To
accomplish this, assets of similar value and function are segmented into enclaves.
Chokepoints are then created between each enclave. This approach allows access,
detective, and preventive controls to be implemented in a logical manner with rapid
response to suspected threats. Further, proxies can be introduced at each chokepoint that
further reduces the surface of attack.
The proposed N-Tiered architecture has two silos. The first silo contains the
segmented applications. Enclaves for Internet Access, SSL/Proxies, HTTP/API Servers,
Web Applications, and Data are recommended. The second silo contains the
infrastructure services. Enclaves for Customer Authentication, Network Applications,
Management, and B2B connections are recommended in this silo.
Once the N-Tiered network architecture is in place, additional controls are
implemented within each enclave. Controls include centralized authentication, IPS,
NAC, malware scanning, data leakage prevention, vulnerability and patch management.
These controls are tuned for each enclave to optimize performance and effectiveness.
Enclaves are interconnected using a security fabric. A security fabric is created

by using a switching platform that provides multiple security services across the
enclaves. The security fabric includes the familiar firewall capabilities. It also is
expanded to provide other security services including network IPS/IDS, web application
and database firewalling, in-line malware scanning, and load balancing. By combining
all these services within the security fabric, packets can be exchanged beyond 40Gbps
through backplane speeds of over 500G. Services can also be performed in parallel (e.g.,
IPS inspection and firewall inspection simultaneously). The security fabric also provides
financial advantages by reducing the consumption of physical switch ports.
A second data center is incorporated into the design as a fully redundant site
offering the same services as the primary data center. Proposed design and services are
able to be delivered from either data center. This approach provides the ability to remain
fully functional if either site becomes unavailable (PROD-PROD). The solution can also
be implemented with a single production site and an alternate site hosting a testing
environment (PROD-UAT). The UAT site can be used as the standby DR location for
PROD.
The standard 40GbE was ratified by IEEE 802.3ba in June 2010. In 2012, only a
few vendors are offering products that support 40GbE and adoption by enterprises has
been slow. A solution based on functional requirements and product availability is
provided in this paper. A Bill of Materials is included in Appendix B.
Technology is just one part of a triad of considerations. People and process are the
other core considerations for this papers proposed solution. Documentation and
procedures are necessary to optimize the existing staff resources. Documentation is
living, with regular updates expected from requirements phase to asset retirement.
Automation of processes is necessary at 40GbE. Several approaches are proposed
including engaging Managed Security Service Providers (MSSPs) who must be
experienced in 40GbE or higher technologies.
There are several benefits associated with this secure network engineering of next
generation networks. These include improved security, increased design credibility,
better manageability, lower total costs, and faster response to threats. Ultimately,
adopting these design recommendations will provide a solid foundation for safeguarding
infrastructure and data at the highest speeds available todayand tomorrow.
2. Problem Description
2.1.
Introduction to SANS Critical Security Control 19
The SANS Institute, in collaboration with many other organizations, extracted

twenty critical technical security controls (SANS, 2011) from Revision 3 of the NIST
Special Publication 800-53 (National Institute of Standards and Technology, 2010), the
recommended security controls for federal information systems. These controls are
prioritized based upon NSA attack remediation strategies scores and are directed towards
CISOs, CIOs and IGs (SANS, 2011). The controls form a shared top priority list for
protection against todays and tomorrows cyber attacks. This paper is based on Critical
Control number 19, Secure Network Engineering, which focuses on the design aspects of
the network infrastructures.
Critical Control number 19 is centered on careful planning of the network
architecture to prevent attackers from bypassing security controls thusly allowing
pivoting through the network. This control is used in parallel with the other controls to
form a cohesive, secure deployment. The procedure to implement this control is to define
a template that describes the overall network services and layout that is to be provided.
Diagrams should show network components such as switches, routers, firewalls, client
and servers.
Sensitive systems, such as databases, must not be accessible from untrusted networks
when designing the network. DMZs are how these design aspects are implemented.
Taking DMZs to the next level is the implementation of trust zones. This paper uses the
word enclaves to represent the different trust zones. These enclaves have very specific
functions and allow for very granular controls to be implemented between boundaries.
To allow for rapid response to attacks, the network must be engineered so that quick
deployment of access lists, black holes, signatures and any other defensive methods can
be achieved. Any form of automation that is available is highly recommended.
Specifically mentioned in the control is the use of layered DNS service. This is
achieved by only allowing intranet DNS servers to forward unanswerable queries to DNS
servers located in a DMZ. In turn the DMZ DNS server is only allowed to forward
requests to the Internet.
To measure the success of the design, port and vulnerability scanners are used to
determine visibility of systems. If unauthorized systems are found or sensitive data
machines, such as database servers, are located and publically visible then the scoring of
the design takes a noticeable numerical hit.
2.2.
Critical Security Control 19 Implementation
Challenges
When designing a secure network, a balance of security, performance and
accessibility must be achieved. A perfectly secure network would be air-gaped, with so
many controls in place that the functionality would border on unusable. That design is
not what this paper strives to achieve. When too many controls are put into place, the
performance of the network begins to become degraded. This papers objective is to
define a secure network approach to perform at 40 Gbps Ethernet (40GbE) throughput.
This meant some of the security controls had to be shifted to specific individual devices
in order to ensure the necessary throughput. When single points of failure create too high
of a risk for loss of availability, redundancy must then be considered. The design
presented here does not detail all of the possible redundancy options that could or should
be implemented but instead focuses on the theme of Critical Control 19a design that
prevents a hacker from pivoting through the network by minimizing attack points and
creating data chokepoints for analysis. Network design must incorporate security
controls early into the planning process rather than as an afterthought. By not building
security into the project early, higher (and possibly unexpected) implementation costs
might occur down the road.
2.3.
Network Challenges for Next Generation Networks
40GbE and 100GbE, at the time of this writing, are still considered cutting edge
technologies with few vendors offering a product line specifically targeting 40GbE. To
clarify, this paper focuses on 40GbE in a single pipe as opposed to aggregation of 4
separate 10GbE pipes. Even though switch vendors have been offering 40GbE backplane
speeds for several years now, today the chokepoint or bottleneck impacting total
throughput is not with the switching fabric. The problem lies with the ability for the other
technologies, such as firewall, IDS, IPS and applications, to keep up with the sheer
volume of data being thrown at it.
The level of uncertainty increases relative to speed too. For example, in the past if
1% of traffic was missed on a 100Mbps pipe, this only resulted in an actual uncertainty of
1Mbps. However, this same 1% is equivalent to 100Mbps of unanalyzed traffic at 10GbE
and 400Mbps at 40GbE. With an increase in speed, the scale of unanalyzed traffic
(uncertainty) scales to an unacceptable level.
40GbE introduces human capital challenges as well. More traffic, and the associated
monitoring, will require additional experienced staff to review the alerts and events that
will be created. The 40GbE flows and technologies will also demand a higher skilled
staff. Automation will be critical if adding staff is not in the budget
Forensics analysis teams are only now beginning to ramp up for 40GbE.
Organizations must be careful not to get too far ahead of incident handling teams, law
enforcement, and assessment teams. In the event these teams are not prepared to work
with the 40GbE infrastructure, the enterprise may find work being done on production
systemsor even worse, the production systems may get confiscated to conduct
investigations.
2.4.
Organizational challenges with 40GbE and Next
Generation Networks
For this STI Joint Written Project, a fictitious organization was created and named
GIAC Enterprises. GIAC Enterprises is a small to medium sized growing business with
1,000 employees, two data centers, 200 people in central business and IT, and is the
largest supplier of fortune cookie sayings in the world. GIAC Enterprises has recently
decided to implement a 40GbE network to meet the demands of mobile apps that deliver
fortunes. The CIO has created a special tiger project team to handle this challenge. The
recommendations and scope of this paper are associated with this type of organization
profile. Further, the business has asked that automation be considered wherever available
so that additional staffing is minimized.
3. Functional Requirements
As with all projects and designs, a clear understanding of business and technical
requirements is required. Based upon the fictitious company GIAC Enterprises
organization profile, the following requirements were used to develop this papers
recommendations.
With 40GbE networks, security cannot be bolted on as an afterthought. The
network design will not be successful if security is not included early in the requirements
and planning phases. Secure network engineering is only 1 of 20 critical security
controlshowever it can be one of the most impactful. Further, there are no higher level
controls that can overcome a serious deficiency with lower level network controls.
Without proper network design and build practices, many of the other 19 critical security
controls can be defeated or simply circumvented.
3.1.
Documentation
Secure network engineering begins with gathering documentationnot creating

documentation. Understanding the specific business purpose(s) of the new infrastructure,
risk appetite of the organization, existing infrastructure, current data flows, planned
interfaces, financial constraints, corporate security policies, contractual (e.g., PCI) and
regulatory (e.g., SOX) obligations are important first steps. Gaps are typically discovered
during this first phase. A small investment of time here can result in big payoffs later in
the project.
Creating an accurate map of the current and intended network is necessary early on
in the project. A traditional network topology map is an excellent start however this does
not provide the entire picture. Documentation should also include all protocols running
through the network, data flows, chokepoints, asset lists (including value), access
controls, and system administration methods. Inter-system dependency should also be
documented. For example, an IP host cannot talk to its peer over the network without
names resolution. Several of these documents are living and change regularly. Establish
a change management procedure for documents, as well as a means to properly secure the
documentation.
3.2.
Data Center Physical Controls
Next, a data center site review is in order. Network engineers will commonly
consider data center environmental (e.g., cooling, power, cable distribution, and rack
space). However, data center physical security controls must also be inspected and
planned for. Secure network engineering includes implementing proper physical
safeguards to protect the new infrastructure from unauthorized access, tampering, and
theft. Ensure appropriate data center facility entry controls are implemented to limit and
monitor physical access to systems and infrastructure. Visitors must be easily
distinguished from authorized staff. Visitor logs, which include all staff and visitors,
building card access systems, and surveillance equipment must be implemented.
Physical security controls and logging are also required for any removable media.
3.3.
Enclaves
Fast, fat, and flat may seem like an ideal mantra for next generation networks.
However, this design approach leads to operational and security risks. Lack of
segmentation makes it difficult for the NOC to monitor traffic flows for anomalies and
routing failures. Congestion management and avoidance become challenging as well.
Inspection and troubleshooting Layer 4 through Layer 7 problems with conventional
tools becomes almost impossible. High value assets become mixed with different assets
that are not maintained, safeguarded, and monitored with the same level of rigor. The
surface of attack then becomes large and these low value assets might become pivot
points of attack.
Todays advanced web and mobile applications are tiered in architecture. This
provides another credible argument for separation of hosts into communities or enclaves.
An enclave allows for easy grouping of assets of similar functionality or value. Trust
boundaries can be created making it easier to assign responsibilities and establish
accountabilities. Chokepoints can be introduced between the enclaves to prioritize
network flows, inspect traffic, and perform forensics. The chokepoints can also be used
to limit access to the hosts and their associated applications. The use of enclaves is
mandatory.
Additionally enclaves make audit and compliance reporting easier for organizations.
Everything does not have to be in scope for inspection by an auditor or compliance
assessor. If the infrastructure contains hosts of various data classifications then
separation can provide financial benefits as well. When all hosts are present on a flat
network, security controls that are required for compliance (e.g., PCI DSS 2.0) may need
to be applied to all hosts within the segment. This may end up being extremely costly.
As a minimum design standard, the following enclaves are required:
Figure 3.3: Enclave Overview
The silo of enclaves on the left of Figure 3.3 is for the N-Tier Applications. The
Internet Access Enclave serves as the entry point into the infrastructure from the Internet.
This enclave contains the Internet access provider equipment including routers and
switches. A dedicated, standalone firewall separates the untrusted Internet access
10
provider network from the trusted customer premises equipment. The SSL/Proxy
Enclave services as the peering point for SSL encryption of mobile and browser devices.
Customers are challenged for authentication from this enclave. Additionally proxies are
to be hosted within this enclave. The HTTP/API Enclave, Web Application Enclave, and
Data Enclave are required to host the equivalent N-Tier application function.
The silo of enclaves on the right of Figure 3.3 is for Infrastructure Applications.
The Customer Auth Enclave contains the credential stores for customer authentication
and authorization. The Network App Enclave contains services like DNS, NTP,
RADIUS, SIEM, and tape back-up. The B2B Enclave is essentially a landing beach for
business partners to securely communicate with systems within the other enclaves. The
Management Enclave contains the jump boxes for remote administration and support.
Further technical elaboration is provided in the section 4, Secure Network Engineering
Practices for Next Generation Networks.
3.4.
Firewalls and Security Applications
Firewalls are used to interconnect the enclaves. The firewalls must be configured
to perform stateful inspection of network traffic. A standalone firewall is also required
for the Internet Access Enclave. A separate standalone firewall is required to connect the
N-Tier to the Enterprise Core. A security fabric is recommended to interconnect the NTier Application Enclaves. In addition to the conventional firewall functionality, the
security fabric includes integrated security applications. These security applications are
integrated into a high-speed (500GbE or faster) backplane chassis, reducing the need for
cabling and 40G physical ports. Security applications in scope are intrusion prevention,
in-line malware and spyware scanning. If supported, Web Application Firewall (WAF)
and Database Activity Monitor (DAM) services should also be integrated into the security
fabric. The aforementioned security services can be separated from the security fabric
and implemented as standalone systems if this provides business or technical advantages
over an integrated solution.
A final firewall is required to interconnect the Infrastructure Application Enclaves
to the N-Tier Application enclaves. A dedicated firewall is required so that common
network services (e.g., tape back-up, managed file transfer, ETL, data synchronization,
11
etc.) do not starve resources that are customer facing. For example, data that needs to be
exported, transformed, and loaded routinely may create a sustained high utilization on the
40GbE network. This will consume switch, firewall, and network interface card
utilization. A separate firewall for this purpose helps reduce the risk of appreciable
performance impact on interactive customer transactions. A firewall policy manager is
required to optimize policies and firewall rules. A tool for monitoring of flows through
firewall is also required to ensure state table overflow does not occur. This last function
might be available as part of the firewall element manager.
3.5.
Internet Access
The network design must support multiple Internet Service Providers and
diversity. The purpose of this requirement is primarily for availability. Also, the design
must incorporate integration between at least two data centers. The purpose of this
requirement is to synchronize data between environments (PROD-PROD and PRODUAT). Disaster recovery plans must be developed and scripted procedures implemented
prior to the infrastructure being made generally available.
3.6.
DNS
Internal DNS must be designed in a hierarchical manner. Secure

DNS servers are required within the Network Application Enclave. These DNS servers
are intended for hosts within the N-Tier Application and Infrastructure Enclaves only.
These DNS servers must point to trusted DNS servers within the Enterprise Core. The
Enterprise Core DNS servers then connect to authoritative servers on the Internet. DNS
servers within the Network Application Enclave as well as all DNS clients within the
other enclaves are not permitted direct Internet access for names resolution. For queries
of external domains, the Network Application Enclave DNS servers must perform
recursive lookups through the Enterprise Core DNS servers. Zone transfers in/out of the
Network Application Enclave are not permitted. A managed service provider must host
and protect the domain used by customers to access the services offered by GIAC
Enterprises. Customer queries of the external domain are not to be resolved by the DNS
servers within the Network App Enclave.
3.7.
12
System and Infrastructure Hardening
System and infrastructure hardening is required. Benchmarks from SANS, CIS,

or similar authoritative source must be adopted as part of standard system build process.
Verification of build standards must be done prior to commissioning the system.
Automation of security control verification and recurring configuration inspection must
be implemented. Procedures should follow an authoritative standard (e.g., NIST Special
Publication 800-128 Guide for Security-Focused Configuration Management of
Information Systems). Lastly, formal certification and accreditation procedures for
systems must be created and integrated into change management.
3.8.
Configuration and Change Management
Automated file-integrity monitoring (also known as change-detection software) is

required to track network and security component alterations. These tools must alert staff
to unauthorized modification of critical system files, configuration files, or content files.
Recurring configuration comparisons must be performed to ensure integrity of
applications, systems, and infrastructure. All detected configuration changes with
material impact must be reconciled to Change Management tickets.
3.9.
Virtual Server and Blade Server Management
Virtual switching is inherent to hypervisor platforms. Care must be taken when

implementing Layer 3 virtual switch capabilities. Network based security controls (e.g.,
firewalls, NIPS, etc.) are not to be circumvented using these virtual switches. Netflow or
similar technology must be included in the solution to baseline traffic patterns and to
identify communication anomalies between virtual clients. Flows associated with virtual
servers and blade servers are to be inspected in the same manner physical hosts would be.
Trunking is not permitted to ensure 802.1q tagging exploits are not successful. Separate
NICs on the hypervisor and blade server chassis must be used for each enclave. NetFlow
or a similar technology must be included in the solution to baseline traffic patterns and to
identify communication anomalies between virtual clients.
3.10.
13
Vulnerability and Threat Management
Vulnerability scanning and penetration testing must be performed routinely.

Scanning and testing must be performed using sources originating from the Internet as
well as from within each enclave. This provides insight into the initial surface of attack
as well as pivot weaknesses.
Once the vulnerabilities are identified through scanning or vendor notification,
remediation is required. An operational framework is required that delivers patch and
non-patch remediation in a timely manner. Consider an approach based on NIST Special
Publication 800-40 Version 2.0 Creating a Patch and Vulnerability Management Program.
Real-time threat analysis must be performed using IPSs, in-line malware and
spyware scanning. Host Intrusion Prevention Systems (HIPS) are highly recommended
for seasonal companies that cannot patch systems promptly throughout the year.
Seasonal freezes (e.g., Chinese New Year) may require systems to go unaltered for
months, preventing implementation of patch and non-patch remediation within 30 days.
A HIPS can help serve as a bridge during these freezes. Additional IPSs are
recommended including Web Application Firewalls (WAF) and Database Activity
Monitoring (DAM). For 40GbE next generation networks, WAF and DAM services are
becoming vital for detecting higher level attacks that may be deluded among the millions
of events and alerts that are being reported by the systems.
3.11.
Log Management
Threat monitoring with actionable intelligence is a prerequisite for rapid response.

A Security Information and Event Management (SIEM) system is required to gather,
process, correlate, alert, and archive security events. Events from IDSs (e.g., replay
attacks, fragmentation attacks, buffer overflow attacks, etc.), firewalls (e.g., DoS attacks,
port errors, dropped packets), SSL (e.g., DoS attacks, certificate errors, session drop),
reverse-proxies (e.g., dictionary logon attacks, cached content change, etc.), and file
integrity monitoring can collectively overwhelm the SOC staff without automation.
Resiliency depends on a clear understanding of operational and security threats. If
the log sources are not properly configured, then the SIEM and SOC cannot be effective.
Log and event sources for SIEM include operating systems, applications, databases,
14
network, and security components. Secure Network Engineering includes the proper
configuration of these components to generate the necessary events that drive incident
response. Further, the log sources and files must be safeguarded from unauthorized
viewing and alteration while in transit, if possible, and while in storage. Logs must be
sent to a centralized SIEM to protect the integrity of event data. A log source
configuration standard based on PCI Requirement 9 or NIST Special Publication 800-92
Guide to Computer Security Log Management is required.
3.12.
Asset Management
An asset management or CMDB is required to track assets and configuration

information in a secure manner. This information should be verified routinely using
automated tools that scan the network and fingerprint assets. Assets must be scanned for
data classification as well. Scanners must incorporate algorithms to identify restricted
data (e.g., Luhn Mod-10 method for identifying and validating credit card primary
account numbers).
Rogue device detection must be performed routinely. Data center physical security
controls should be the primary preventive control to prevent unauthorized devices from
connecting to the network. Rogue device detection should be used to verify that the
physical controls are effective. The automation for asset discovery and restricted data
scanning may be used for discovering rogue devices.
3.13.
Access Management
Authentication, Authorization, and Auditing (AAA) systems for customers must be

separate from system administrators. High Authority accounts used by DBAs, firewall
administrators, network engineers, system administrators, and vendors must be located in
a separate enclave from customer accounts. No trust is to be established between the
Enterprise Core, High Authority, and Customer credential systems.
Remote administration is made available from the Management Enclave. Business
partners, manufacturer support staff, outsourced staff, managed service providers, and the
IT staff must all use jump boxes to gain access into the applications, systems, and
infrastructure. Products that may be considered for the jump box function include
15
Microsoft Terminal Server, Citrix, and VMWare. Multi-factor authentication is required

for access onto these jump boxes. Further, remote administrators must have their
computer scanned to verify basic security controls are in place and working properly.
Network Access Control (NAC) products are to be implemented to check the status of
malware prevention, personal firewall, patches, and vulnerabilities on administrator
computers prior to revealing the jump boxes.
3.14.
Performance Management
SNMP, RMON, and NetFlow are common tools for network engineers to perform
performance monitoring and capacity planning. These protocols must be properly
secured. Vendor defaults (e.g., SNMP community string public) are not permitted.
SNMP v3 is required. When available, authentication and encryption controls must be
incorporated into performance management design.
3.15.
Forensic Management
Support for forensic analysis and network monitoring Out-of-band is required.

Network taps or in-line OSI Layer 1 network monitoring devices are acceptable. These
devices are to be transparently connected so that they do not introduce performance
degradation. SPAN or similar technology features are not to be used on 40GbE
components. In addition, the integration of the network monitoring devices must be in a
manner that does not allow circumvention of network based security controls (e.g.,
firewalls). Dedicated network monitoring systems for each enclave would provide the
necessary boundary to prevent this exploit.
3.16.
Service Management
Where there is a business advantage, consider the use of managed service providers
as an alternative to additional staffing. Opportunities include domain hosting, managed
PKI, firewall/IPS/IDS/AV management, security operations center services, computer
security incident handling, vulnerability scanning and penetration testing. Some of these
same services are available as a cloud computing offering. This option might be
desirable for reducing capital and expense commitments. This allows the limited IT staff
to focus on business communications and solutions by reducing the demands of daily
16
security operations. This also provides an elastic bench of resources for the busy seasons
and rapid business growth.
4. Secure Network Engineering Practices for Next

Generation Networks
Before authoring this paper, the STI team approached vendors, consultants, and early
adopters of 40GbE to share their expertise and lessons learned. This research
incorporates their feedback. Current benchmarks and standards were also reviewed for
applicability to 40GbE. Section 4 presents risk considerations, remediation strategies,
technical approaches, design recommendations, and references to best practices for
secure network engineering of a 40GbE infrastructure intended to host web and mobile
applications.
4.1.
Design and Build Technical Approach for Next
Generation Networks
Figure 4.1 visually depicts a high-level network architecture overview with multiple
enclaves that host an Internet facing mobile or web application.
Figure 4.1: High-Level Network Architecture Overview
17
Two major groups of enclaves are recommended. The silo of enclaves on the left of
Figure 4.1 and labeled N-Tier App Enclaves contain the web and mobile applications.
Each function of the application is isolated into a separate enclave. This silo of enclaves
is connected by a customer facing firewall (A) and infrastructure firewall (B). Separate
firewalls are used substantially for performance and capacity planning in a 40GbE
networknot security. As new 40GbE firewalls arrive on the market, a single multi-port
firewall to interconnect all N-Tier Application Enclaves could be considered with proper
capacity planning. Access is cascading between enclaves through the firewall so that any
enclave can only connect to adjacent enclaves within the N-Tier Application Enclave silo.
The Infrastructure Enclaves contain network applications and access controls necessary
for all N-Tier Application Enclaves. This includes account authentication and
authorization, in addition to common network applications (e.g., DNS, tape back-up,
SNMP, patching, etc.). Administrators of the systems and applications within the N-Tier
18
Application Enclave must pass through the Management Enclave. The B2B Enclave is
for EDI, ETL, and vendor partner connections (e.g., MSSP). The Enterprise Core access
into this new infrastructure is restricted using a dedicated firewall(s) (D) and Internet
access into the N-Tier Application Enclave if also restricted using a dedicated firewall(s)
(C).
Once the network has incorporated proper security controls, the architect must
consider the operational impact of 40GbE speed. Automation becomes a critical
consideration as the velocity of data increases many orders of magnitude. With speed
comes an increase in the number of flows, events, and triggers. Procedural controls that
were successful with slower speed networks may get overrun at higher speeds. For
example, swapping current firewalls with new firewalls containing faster 40GbE
interfaces has a cascading effect. The firewall may be able to handle the new packet
volumehowever the SOC, SIEM and associated firewall administration tools may go
into a meltdown. Security controls, automation, and capacity planning must go hand-inhand.
4.2.
Internet Access Enclave
This first enclave within the N-Tier Application silo is where the mobile and web
applications are revealed to the Internet. Multiple Internet access providers may be
terminated here to provide diversity and redundancy.
Figure 4.2 Internet Access Enclave
4.2.1.
19
Risk Considerations and Remediation Strategies
This is the first location where customer and attacker are being identified and
separated. This enclave contains the highest level of uncertainty because the untrusted
network and trusted network are both present. Internet sourced mapping and scripted
attacks use this as their primary point of entry. Intrusion detection and prevention
devices are necessary to safeguard the infrastructure as well as to examine the evolving
taxonomy of Internet based attacks. Probes and brute force authentication attacks
targeting infrastructure devices at this layer are common. Poorly designed networks will
unintentionally allow enumeration of network accounts in RADIUS/TACACS or
AD/LDAP credential store.
Ethernet switches in general are by design oversubscribed (sum of physical interface
speed exceeds switch backplane speed) and can be overwhelmed by sustained traffic
20
volume from metro networks. A standalone firewall and switch are recommended for this
enclave for the above mentioned performance reason as well as security benefits.
4.2.2.
Technical Approach and Design Recommendations
The Internet Access Enclave is the first layer into the network. Redundancy, high
availability and resource isolation is critical to maintain stable and secure access to
customers. To offer redundancy, Internet access should be provided by multiple ISPs,
for diversity, using different paths and peering partners. This approach will provide high
availability in the event of an ISP outage, upstream provider failure, or network
equipment failure. Multiple ISPs will allow traffic engineering, load balancing and
provide an alternate connection in the event of a DoS attack.
Each connection from the Internet accesss providers should be terminated into a
router supporting 40GbE interfaces running BGP using a private AS number. This
provides IP mobility across separate ISPs and allows for future transitions between
carriers. Internet facing interfaces must prevent any leakage of internal routes, topology
broadcasts or redistribution, and explicitly prevent external management of the routers.
For traffic engineering, multiple high availability instances can be created to allow a path
across both ISPs concurrently.
Any peering relationship (e.g., routing protocols, VPN, RADIUS, etc.) must be
mutually authenticated prior to making a trusted connection. This control will help defeat
attack sources masquerading as a trusted peer. Integrity checking must also be in place to
defeat man-in-the-middle attacks.
The Internet access routers connect into a high speed 40GbE switch which provides
a common media for high availability and fail-over capabilities. Network taps provide
inspection points for Internet traffic. Switch SPAN features are not recommended.
A firewall connects the aforementioned switch to the N-Tier Application silo. This
perimeter firewall must be a standalone device with large processing power capable of
handling legitimate traffic and potential attacks simultaneously. The standalone firewall
is intended to serve as a buffer between the Internet Access Enclave and the remaining
enclaves within the N-Tier Application silo. This approach prevents resource exhaustion
attacks that target the Internet facing firewall. External management and non-public
21
information exposure must be disabled on the outside interfaces. The firewall should
point to the High Availability IP address of the perimeter routers based on the traffic
engineering designs. Access Control Lists (ACLs) should be created with permit
statements that match security policy and align with business requirements. This
approach applies to both inbound and outbound traffic. ACLs must end with an explicit
deny with logging enabled for dropped connections. Logging of denied packets provides
valuable insight including common attack vectors, taxonomy, and firewall administrator
ACL change errors. This data is also valuable for effective data and event correlation
across all network and security devices. Logging of the permitted traffic is a commonly
accepted practice. Data leakage considerations should include network related
information (e.g., internal IP addresses, routing tables, etc.). ICMP should be disabled to
defeat reconnaissance efforts by attackers. Further, ICMP should be filtered to prevent
smurf attacks and using the network as a reflection or amplification point.
Flow data should be enabled on all devices that support it (e.g., Cisco 12816 router).
This network data is very useful to the security team with 40GbE networks to identify
baseline changes, detect threats, and perform event correlation. This same data is
valuable to an attacker when mapping the network. Safe network engineering practices
must be considered early on so that flow data is not exfiltrated or altered.
There are multiple options to forward traffic on to the next enclave (SSL/API). The
first option and most traditional is Network Address Translation (NAT). NAT is only
recommended at the perimeter within the Internet Access enclave. This is required to
translate from the ARIN IP address space to a RFC 1918 private IP address space. For
the other enclaves, RFC1918 addresses are used (e.g., 10.0.0.0/8, 192.168.0.0/16, and
172.16.0.0/12) and routing is performed. Routing is recommended because there is less
queue delay associated with deep packet inspection and less chance of errors than with
NAT traversal. The router protocol must be secure, ensuring that routes cannot be
maliciously manipulated or deleted. Recommended security controls include router
authentication and integrity checking. Modern firewalls support routing protocols with
associated security settings. The router protocol should have established boundaries.
Routing tables are not to be redistributed from Enterprise or Internet peers. Route
summarization or static routes must be used.
22
All network devices must have a common authoritative time source (NTP). This
provides credibility for logging and data correlation.
4.2.3.
Industry Best Practices and Authoritative Sources for Security
Controls
Dynamic routing protocols, such as BGP, are generally preferred on border and edge
routers due to the ability of the router to propagate route changes more efficiently and
rapidly than by an operator entering the routes statically. BGP has existed for a long time
and been thoroughly tested throughout the world. One of the benefits of dynamic routing
protocols is they offer route injection protection such as TTL verification and
authentication of peers (see Appendix A.2). Having independent AS numbers on the
border routers provide flexibility to advertise routes to different ISPs for failover or
attack remediation strategies (see Appendix A.2).
Routing black holes should be implemented on the routers and firewall and
automated where available. Routers must already have the ACLs or maps in place to
perform this traffic filtering. This is needed to minimize the amount of time needed to
create the black hole and apply it. Automation is achieved when a black hole route is
injected on one router and via a dynamic routing protocol is distributed to the other
routers (see Appendix A.9.3).
Black hole routes are used to prevent traffic from crossing network segments. For
example, a black hole route implemented on the border router might be used to prevent a
DoS attack. Another example might be to prevent the further exfiltration of data. If the
destination network is known, implementing traffic drops across the entire network can
be done quickly and efficiently.
Deployment of Infrastructure ACLs (iACLs) is expected on border routers (see
Appendix A.3). iACLs permit management and control traffic to the infrastructure
switches and routers while preventing attack traffic directed at the infrastructure devices.
Typically iACLs focus on source and destination IP addresses as well as Layer 4 ports
and protocols. Antispoofing ACLs explicitly permit traffic based on authorized source
IP addresses only. Any traffic sourced from outside the explicitly permitted IP address
range is dropped (Schudel & Smith, 2008, Interface ACL Techniques, para. 3) such as
23
private network address leakage, Martians and bogons. Transit ACLs (tACLs) explicitly
permit only required and authorized traffic to transit the IP network (Schudel & Smith,
2008, Interface ACL Techniques, para. 3). TACLs typically dont filter IP addresses
but are used more on packet types such as IP header options, IP fragments or protocols
such as routing protocols.
Many general router hardening practices such as IP Options selective dropping and
disabling of IP Source Routing must be deployed on the router (see Appendix A.9.5 and
A.9.7 respectively). Unused features or services must be turned off on routers and
switches. Such services include dhcp, bootp and NTP timeserving (see Appendix A.8).
The additional CPU availability, created by removal of unused services, allows more
flexibility to avoid CPU resource exhaustion.
Login banners are to be implemented on every device in the network to provide a
vetted legal notice to anyone using the device as to the level of privacy and the legal
issues associated with accessing the devices. Neither physical location data nor network
architecture information should be found on any switches, routers or firewalls (see
Appendix A.9.1).
Implement ARP inspection on routers to prevent malicious frame redirection or
MAC table poisoning. Another method available is to hard code static MAC addresses
for the most critical devices (see Appendix A.30).
Disable, if possible, or do not use VLAN 1, the default VLAN for some vendors.
VLAN 1 is not to be revealed to any of the enclaves. Further, the management VLAN
must only be revealed to the Management enclave. This eliminates the switch interface
from being a possible target of attack.
A firewall located after the border router provides the next depth and breadth layer
of defense (Schudel & Smith, 2008, Principles of Defense in Depth and Breadth, para.
1). Where implementation of traffic controls might overwhelm the border router, those
controls are transferred to the firewall. Not only are the same Antispoofing ACLs, iACLs
and tACLs found on the border routers implemented here, but more fine grained ACLs
are implemented on the firewall, too. Adoption of an explicit deny rule is preferred here
to allow only authorized ports and protocols through as determined by the firewall
security plan (see Appendix A.4).
24
Quality of Service (QoS) is used to ensure that control and management traffic are
guaranteed passage when the routers and switches are overwhelmed with normal data
traffic (see Appendix A.15). Deployment should be on both the router facing the service
provider and the interior router of the Internet Access Enclave. Traffic markings should
persist when passing through the firewall.
Role based CLI access and passwords must be implemented on all network devices
(e.g., routers, switches, firewall, etc.). A read-only view, account or level of access
should be used by all staff that access the router or firewall. A separate read-write view,
account or level of access should be used only when changes to the devices is necessary
(see Appendix A.11). To protect storage of configuration files that may contain
passwords in the clear, use the highest level of encryption available (see Appendix A.10).
If possible the use of one time passwords or multi-factor authentication is preferred (see
Appendix A.16.
All network devices (e.g., routers, switches, firewall, NIPS, etc.) must implement
Authentication, Authorization and Accounting, also known as AAA services. This
ensures that password policies are enforced, that account access is revoked in a timely
manner, that the correct levels of authorization are enforced, and a record of account
usage is created (see Appendix A.7).
All non-console administrative access must use the most secure mechanisms such
as SSH versus the insecure telnet. Remote management must use the most secure
mechanisms such as SNMPv3 versus SNMPv1/2. iACLs should be implemented to limit
access to the management consoles and services (see Appendix A.17).
NAT is introduced by this enclave on the firewall. NAT provides obscuration of
internal IP addresses by providing a many-to-one mapping of internal IP address to a
single outside IP address (see Appendix A.26).
Administratively disable any unused ports that are not actively in use to prevent
unauthorized access or incorrect insertion of cables.
4.3.
25
SSL/Proxy Enclave
SSL accelerators and reverse proxy servers are present in this enclave. These serve
multiple purposesthe most common being to off-load encryption processing overhead
from HTTP servers. If logging is required, customers are challenged at this enclave for a
name and password.
Figure 4.3 SSL/Proxy Enclave
4.3.1.
Man-in-the-middle, session high-jacking, Cross-site Scripting (XSS), and denial of

service (DoS) attacks are quite prevalent today. In some cases these attacks are effective
because of poor network design. In other cases these attacks are effective because too
much surface is revealed to the Internet, leaving systems vulnerable to attack because of
product defect and configuration errors. Secure network engineering must include an
26
approach that reduces the surface of attack and optimizes performance. Specialty
products like proxies and SSL accelerators are hosted in this enclave to defeat brute force
authentication attacks and resource exhaustion attacks targeting HTTP and API Servers.
If logon is required, challenging for customer account authentication is done from
this enclave. Logon at this point within the infrastructure is necessary to disguise the
complexity (and potential vulnerability) of authentication servers deeper within the
infrastructure. The actual customer credential store (account name, passwords,
passphrase, account number, attributes, etc.) is not to be hosted within this enclave. The
SSL accelerator or proxy will reach out to the authentication servers for credential
verification. This design approach is necessary to defeat direct attacks against the
authentication server platform (e.g., DoS, buffer overflow, etc.) that could result in
circumventing authentication controls.
If SSL is used for mobile device or browser access (which is recommended), this
enclave reveals the Internet sourced data in the clear for the first time. Security controls
that safeguard confidentiality must be balanced with controls to inspect for attacks and
errors. Keep in mind that encryption without inspection may disguise exfiltration
occurring within the N-Tier Application Enclaves. Further, throughput of a 40GbE
network can quickly decline when traffic is repeatedly encrypted and unencrypted.
Proxy and reverse proxy servers can be used to cache content. These platforms
might be used as a springboard of attack. Cached contend that is not properly
safeguarded can result in unintentional data leakage. Further, malicious alteration of
cache content could allow client side attacks.
4.3.2.
The SSL/Proxy enclave consists of an SSL offloading engine that will accept
inbound 40GbE SSL traffic from mobile app customers and decrypt it. SSL poses certain
challenges for security device inspection as packets traverse the network in an encrypted
form. Utilizing an SSL offloading appliance provides the enterprise with the following
advantages:
Inspection of unencrypted traffic as it traverses other enclaves.
Elimination of SSL processing on servers

27
Implementation of an application layer firewall. Several SSL accelerator products

reviewed provide additional application firewall or Layer 7 inspection capability.
Traffic from the Internet Access Enclave must pass through a firewall before being
passed into the SSL/API Enclave. Unlike the Internet facing firewall, this firewall that
interconnects the Internet Access and SSL/Proxy Enclaves does not have to be a
standalone appliance. A more sophisticated device can be considered that serves the
secure interconnect needs between the remaining N-Tier Application Enclaves. The
proposed device contains shared security services that are applied to the switching fabric.
A security fabric is created by using a shared platform that provides multiple
security services across the enclaves. The security fabric must include firewall
capabilities but also can be expanded to provide other security services including network
IPS/IDS, web application and database firewalling, in-line malware scanning, and load
balancing. By combining all these services within the security fabric, customers can take
advantage of backplane speeds of over 500 Gbps that today far exceed the physical
limitations of 40GbE. Services can also be performed in parallel (e.g., IPS inspection and
firewall inspection simultaneously). The security fabric also provides financial
advantages by reducing the consumption of physical switch ports. Examples of security
fabric solutions include Fortinet, Cisco, and Crossbeam.
To alleviate the server I/O challenge of handling 40GbE, consider load balancers.
This approach will help eliminate a significant throughput bottleneck.
A Network Intrusion Prevention System (NIPS) is introduced as traffic is passed to
the HTTP/API Enclave. Data is in the clear at this point. IPS must run in learning or
monitoring mode for initial deployment to identify any business traffic anomalies that
needs to be addressed prior to make the switch to active in-line blocking.
4.3.3.
Controls
Several of the security controls mentioned in 3.2.3 apply to this enclave as well.
Specifically, the guidance provided with routing, hardening, QoS, ACLs, firewalls, AAA,
patch and vulnerability management, and remote management apply to this enclave.
28
The same VLAN protections mentioned in the Internet Access Enclave apply here
as well with the addition of disabling trunking on access layer ports (see Appendix A.23).
This enclave continues the design practice of separation of services and
classification. Each device or service in the enclave offers similar services or has data
classified at the same level. This separation provides protection from the previous less
trusted enclave while also allowing the uniform inspection of data between the enclaves.
Since only one type of data is passing between the different enclaves the traffic
inspection can be narrowed and made very specific. This also provides measurable
optimization of performance for firewalls and IPSs at 40GbE speeds.
4.4.
HTTP/API Enclave
This part of the N-Tier Application Enclaves contains the HTTP Servers and API
Servers.
Figure 4.4 HTTP/API Enclave
4.4.1.
29
The aforementioned enclaves contain function specific devices (e.g., firewall, IPS,
SSL Accelerator, etc.) that are in many cases appliances and proprietary. This enclave
most likely will introduce multi-function capable hosts based on common enterprise
operating systems (e.g., Red Hat Enterprise Linux, Microsoft Windows Server, IBM AIX,
etc.). Hardening, configuration management and file integrity monitoring will be
required. The network design must permit the associated automated tools into this
enclave to routinely update, inspect and report. Release management and change
management practices become vital as the hosts within this enclave will be updated
frequently (e.g., code updates, software releases, content changes, etc.). Further,
automated update of security controls must be incorporated (e.g., patching, web
application firewalls and HIPS signature updates, malware detection databases, etc.).
Blade server and virtual server integration is now a major design consideration for
this enclave. Port aggregation is commonly considered during the design phase. This
provides higher bandwidth as well as fault tolerance between blade server chassis (or
hypervisor) and ethernet switch. Careful consideration is required if cable taps,
inspection devices (e.g., IPS/IDS) and forensic analysis devices are to be integrated. For
example, if the blade server chassis and ethernet switch are interconnected using 4 x 10
Gbps to get an aggregate of 40 Gbps, there may not be a way to introduce a tap or IPS inline.
Virtualization and blade servers may introduce new flows in which traffic never
passes a physical switch. As an example, consider two Microsoft Windows Servers
running IIS as guests on VMWare ESX. If clustered, the Windows Servers would be able
to intercommunicate without inspection by a network intrusion prevention system
appliance. This would make detection of a pivot attack more difficult. Some switch
vendors like Cisco and Extreme Networks are introducing virtual switches with features
to overcome this issue. SPAN may help in some conditions, however this feature is
typically the first sacrificed when the switch approaches maximum utilization.
30
Common IT service activities will result in large volumes of data movement even
though HTTP Server content is static. Tape backup moves a substantial amount of data
daily. Creating snapshots of VMs prior to software upgrades is a common practice. With
SLAs of 99.5% or better required, the operational risks associated with patching and
system updates requires frequent backup and image motion. Tape backup, snapshotting
VMs, and replicating servers can become a security risk as configuration and restricted
data may be present on hosts. This data motion can happen very quickly with 40GbE
networks. Network design should incorporate controls to inspect and protect IT service
initiated data motion.
Many of the aforementioned risk considerations apply to the remaining enclaves.
4.4.2.
The HTTP Enclave is a separate security zone defined in our firewall with ACLs
defining inbound and outbound traffic between the SSL and the Web Application
Enclaves. The decrypted SSL traffic that was provided by the SSL/Proxy Enclave
crosses back into the firewall, IPS, AV and web application firewall for inspection and
back out to an interface of the load balancer to distribute to the HTTP server farm. The
connection between the firewall and the load balancer and between the load balancers can
either go directly or through a switch. A business and design decision can be made based
on business needs. From one prospective not having a switch reduces the chance for the
wrong device being connected to the network. Potential signal interception or
unauthorized taps introduce additional points of failure. On the other hand not using a
switch reduces some of the insight into port statistics monitoring that is a part of our
overall infrastructure monitoring.
This enclave must not store any customer data or any proprietary information;
however that data is transported through this enclave. The sole purpose of this enclave is
receiving the decrypted http traffic, parsing the HTML requests and forwarding it to the
next enclave for logic and web application request processing. Bandwidth at 40 Gbps
speed could present a challenge for the server side processing. Load balancing is
recommended.
31
Anomaly detection at the HTTP layer is critical to monitor abnormal URL access,
frequency and volume. From the 40GbE network prospective, NetFlow/sFlow data is
crucial at all layers to monitor abnormal spikes between specific hosts and destination.
This provides non-signature based analysis in the event that our other layers of security
fail as well as provide us insight into attacks that do not fit our normal traffic behavior. A
correlation engine is required to process the various sources of data to detect anomalies
(e.g., HTTP server logs, IPS logs, NetFlow/sFlow logs, etc.)
Host based monitoring is another critical layer of protection to identify attacks and
traffic from the host and application prospective. The network will see the traffic but
might not have full understanding of how each application will handle the various types
of anomalies that is being directed towards it. Layering security implementation is
recommended as through the 20 critical controls and specifically critical control number
19.
With a limited number of systems, the understanding of data flow is the foundation
to creating access lists limiting source and destination traffic between the SSL enclave
and the HTTP enclave moving to the Web Applications Enclave. ACLs are applied on the
firewall limiting communications to trusted hosts between the enclaves while dropping
and logging any other non-authorized traffic.
4.4.3.
Controls
patch and vulnerability management, and remote management apply to this enclave.
The network design makes use of virtualization and blade servers. VMs should be
separated by different trust levels, asset values, or data classification. This would be
achieved by running VMs of the same trust level on the same box and using a separate
hypervisor on a separate machine to host VMs of a different trust level. VMs should also
be prevented from accidentally being migrated from one trust level to another trust level.
Securing the hypervisor is another hardening technique and can be implemented by using
32
multi-factor authentication, separation of roles and privileges, and disabling or removing

unused services on the hypervisor (See Appendix A.27).
Hypervisors also introduce their own network switches. A thorough understanding
of how the switch is implemented to prevent unintentional misconfigurations or breaches
of trust levels. These virtual switches are also capable of using VLAN trunking and as
such the same considerations presented above regarding trunking apply here as well (See
Appendix A.27).
If VLAN trunking is used then usage of an authentication method is highly
recommended. Ports should have a default configuration of not allowing trunking so that
manual configuration is required as a safety precaution. Automatic VLAN propagation,
if necessary, must also be contained to propagate VLANs within similar security zones
(See Appendix A.22).
4.5.
Web Application Enclave
This enclave contains the web application servers and API servers. In addition, load
balancers, web application firewalls, and web application intrusion prevention systems
may be present.
Figure 4.5 Web Application Enclave
4.5.1.
33
This enclave has many of the same risks as the aforementioned HTTP/API Server
Enclave including multi-function hosts, virtualization, blade servers, common IT
services, and Ethernet port requirements. Further, this enclave is a very dynamic
environment operationally. It is also the most complex. The hosts within this enclave are
a hub for combining content and data from a variety of sources. There are many leads
and feeds to consider for this enclave including enterprise service buses, message
services, databases, warehouses, SOA gateways, XML accelerators, and legacy gateways.
Because of this, accurate documentation and comprehensive data mapping are critical for
this enclave.
Managing this enclaves ACLs for firewalls, routers, and switches can be a daunting
task for engineers. An unintended configuration error might reveal vulnerabilities and
new targets of attack. In addition to the firewall administration tools provided by firewall
34
manufacturers, consider the use of firewall policy managers. These products integrate
with multiple firewalls from multiple manufacturers. In addition to the routine policy
updating, they also include policy optimization. A poorly written ACL has one of the
biggest impacts on firewall performance.
Many different types of IT administrators must access this enclave including
database administrator, system administrators, middleware administrators, application
administrators and the occasional developer. Direct access into this enclave is a
common request, however this is a poor approach. Access must be proxied through the
Management Enclave to ensure access controls are enforced and activity can be tracked.
Security integration into SDLC is also vital. Early adoption of security best practices will
reduce the likelihood of unplanned application problems that result in network security
controls being temporarily relaxed to troubleshoot production problems.
4.5.2.
Many organizations must consider hosting multiple web application standards that
reside within this enclave. As an example, the majority of new web applications may be
built on IBM Websphere, however a legacy web application based on Microsoft Windows
.Net may have to remain around for a few more years. A design decision is required to
create duplicate web application enclaves or introduce further segmentation within the
enclave.
For architects considering further security to isolate disparate standards within the
enclave, there are a few options. A common option considered is to implement IPSec
ESP on the hosts. This provides mutual authentication and encryption. However, legacy
systems many not have a practical IPSec solution or the processing overhead is materially
impactful to application performance. Some switch manufacturers offer Private VLANs
in which the Ethernet switch limits inter-port conversation to within the same VLAN.
This can be effective, however load balancing and clustering can be a challenge to
integrate. A new standard IEEE 802.1ae is being adopted by some 40GbE switch
manufacturers. In this case the switch itself performs the encryption of framesthere is
no supplicant required on the host for authentication and no client needed for encryption.
Kerberos snooping, LLDP, or DNS are used by the switch to determine the host type.
35
The switch can automatically assign the encryption and segmentation settings or the
switch administrator can set this manually.
Application firewalls are common within this enclave. Also known as layer 7
firewalls or Web Application Firewalls (WAF), they safeguard web applications from the
most common forms of attack. The difference between these firewalls and the traditional
network firewall is they have context intelligence. A WAF can recognize attacks
targeting web application weaknesses including configuration errors, parameter
manipulation, coding errors, buffer overflows, and known web application defects in a
way IPS and traditional firewalls cannot. For example, Imperva offers a product
SecureSphere which provides protection against the OWASP Top Ten attacks, including
SQL injection, XSS and CSRF. Several other commercial and open source solutions are
available. XML firewalls, SOA firewalls, and HTTP firewalls may be of interest. These
application firewalls can be installed as agents on the server, in-line Ethernet, SPAN, or in
some cases as a cloud-based service. With 40GbE speed, any help applying intelligence
to raw events must be considered.
4.5.3.
Controls
patch vulnerability management, and remote management apply to this enclave.
4.6.
Data Enclave
This enclave may contain traditional databases (e.g., Microsoft SQL Server, Oracle,
MySQL, etc.) as well as a number of other data sources including enterprise service
buses, message services, databases, warehouses, SOA gateways, XML accelerators, and
legacy gateways.
Figure 4.6 Data Enclave
4.6.1.
36
Enterprises might consider dissolving this enclave, opting to access data within the
Enterprise Core Enclave directly. Concerns about data synchronization and the cost of
redundant data stores may make this seem an attractive design approach. Expanding the
use of database technology in place within the Enterprise Core might be tempting to
consider. Rapid growth in customer demand may accelerate capacity demands and
require an unplanned upgrade of existing enterprise data services impacting internal and
external customers. Further, segmentation within the core may not be sufficient to create
boundaries for compliance and audit. This may draw the entire enterprise into scope for
compliance evaluation and control implementation.
Operationally, there are potential problems using data sources within the Enterprise
Core. For example, two phase commit and record level locks become difficult to execute.
There are many hidden costs and risks associated using data resources residing within the
37
Enterprise Core. A thorough investigation into all design options for is strongly
recommended. Creating this enclave is highly recommended.
As with the Web Application Enclave, documentation and data mapping are critical
for this enclave. Policies should also be documented including data retention and data
destruction. These policies may drive archiving and transfers impactful to the network
capacity.
The pattern of traffic for this enclave will be high volume, large payload transfers.
Database ETL (Export-Transform-Load) and EDI (Electronic Data Interchange) will
cause bulk transferspossibly while customers transactions are occurring. The benefits
of a separate customer facing firewall and infrastructure firewall are best demonstrated
with this enclave when running at 40GbE speeds.
There are a number of attacks targeting database servers that a conventional IDS
will not detect. Database intrusion prevention systems (also known as database activity
monitors) are becoming increasingly popular. They provide contextual knowledge of
database protocols and structures that is used to detect database attacks. These products
can be placed in-line, installed as an agent, assigned to a SPAN port, or connected to a
tap.
4.6.2.
There are a variety of data sources that might be placed within or revealed through
this enclave. Database servers are commonly staged within this part of the network. Day
one the database is empty. There must be an approach defined for getting data in and out
of the database server to ensure the data remains relevant. ETL is a common way to get
this data. However this creates a challenge for real-time data. ETLs are typically done
once or twice a day, so customers that demand data with quick expiration will not be
satisfied. For example, if the web or mobile application is to provide logistic information
(e.g., Where is my shipment of fortune cookies and when will it arrive?), then ETL
simply wont work. In some cases the data may not be on-premise. A B2B connection or
EDI service is required. In some cases the data is not entirely from the enterprisebut
instead a collection of information from enterprise, business partners and vendors. This
38
enclave is where these data feeds are intended to land before being revealed to the Web
Application Enclave.
Network engineering for this enclave must include the secure transport of data.
Confidentiality is important, but so is authentication and integrity checking. Garbage
traveling at 40 Gbps is still garbage.
If for some business reason the data cannot reside within the Data Enclave, then
consider alternatives like database gateways (e.g., SQL, XML, DB2, etc.), an enterprise
service bus (e.g., Tibco), or message service (e.g. IBM MQ Series) for the enclave.
4.6.3.
Controls
Specifically, the guidance provided with routing, hardening, QoS, ACLs, firewalls,
AAA, patch and vulnerability management, and remote management apply to this
enclave.
In this enclave we scope in our monitoring to continuous analysis of all database
traffic to detect unauthorized or anomalous activities. This can be done in-line on the
network or a copy of the database transactions can be offloaded to another device for
analysis. Baselining is another important step that will assist in the identification of
normal versus malicious transactions (see Appendix A.28).
4.7.
Customer Authentication and Authorization Enclave
This enclave contains the credential store for customer accounts. Authentication,
authorization, and auditing of customer account activity are performed here. This
enclave does not contain the credential store for Enterprise Core accounts nor
infrastructure (i.e., firewalls, routers, switches, etc.) accounts. Customer data is not
stored herejust the account information necessary to access the applications revealed to
the Internet.
Figure 4.7 Customer Auth Enclave
4.7.1.
39
Requiring customer authentication provides several business opportunities for the

enterprise. Website personalization, order processing, fulfillment tracking, logistics,
loyalty programs, and promotions can all be integrated with the website customer
credentials. Internal business systems like ERP may have to integrate with this customer
credential store, too. The business may require many touch points to this credential store.
This might unintentionally create a large surface for attack. Segmenting customer
authentication and authorization data is vital to protect confidentiality and integrity. This
enclave is intended to prevent customer account harvesting and pivot attacks deeper into
the enterprise infrastructure. Lastly, breach notification is expensive and can have a
material impact on enterprise reputation.
40
This enclave is generally revealed to all N-Tier Application Enclaves, so secure

network engineering is critical for this enclave. Once this enclave is compromised,
attackers will attempt to circumvent firewalls between the N-Tier Application Enclaves.
4.7.2.
This is not the location where system administrators, DBAs, and network engineers
store their accounts to manage the infrastructure. This enclave and associated services
are not intended for the Enterprise Core. There should be no trust established to
enterprise credential stores or directories.
A dedicated solution to host customer credentials is placed within this enclave.
Several options are available including RADIUS, LDAP, Microsoft AD, Tivoli Identity
and Access Manager, and others. Identity and Access Services (IAM) systems, federated
services, and single sign-on services may also reside within this enclave.
Automation for IAM will become critical as the number of customers increase.
Customer self-registration and self-password reset should be considered. Tokens for
passing credentials to HTTP, Web Application, and Data enclaves will also be created
here. Mutual authentication between hosts within in this enclave and other enclaves is
required prior to customer credential or token exchange.
4.7.3.
Controls
Several of the security controls mentioned in 3.2.3 apply to this enclave, too.
patch and vulnerability management, remote management, and NAT apply to this
enclave.
4.8.
Network Application Enclave
Traditional network applications and services reside in (or are revealed by) this
enclave. This includes tape back-up, DNS, SIEM, NTP, File Integrity Monitoring,
RADIUS, TACACS, administrator authentication servers, MFT, release management,
41
application performance monitoring, network performance monitoring

(SNMP/RMON/NetFlow), transaction auditors, and forensic analysis tools.
Figure 4.8 Network App Enclave
4.8.1.
The largest fraction of firewall ACLs are associated with this enclave. This part of
the network offers the greatest opportunity for firewall policy and rule optimizationor
the greatest source of inefficiency and firewall performance hit. For example, 100
network services (DNS, NTP, RADIUS, etc.) presented from this enclave to the other
enclaves would result in at least 700 ACLs (7 enclaves x 100 network services= 700
ACLs). With redundancy of hosts and services, this could possibly translate into 10,000
Access Control Entries! As with the Web Application Enclave, consider Firewall Policy
Managers (FPM).
42
In addition to ACL optimization on the firewall, network engineers must consider

the number of flows passing through the firewall. Though a firewall may have a new
40GbE interface that is 40 times faster than conventional 1GbE interface firewalls, the
state table buffer may not be the same order of magnitude larger. With 40GbE, firewalls
might be overwhelmed with stateful flow management long before the physical Ethernet
interface is saturated. This may result in unexpected outcomes including session loss
through the firewall. Worse, this may result in a buffer overflow state in the firewall
resulting in a failed closed condition that passes traffic that should be denied.
System, database, application, middleware and firewall administrators all store their
accounts in RADIUS or similar authentication system within this enclave. Centralized
authentication of high authority accounts is required for this entire infrastructure.
Distributed account management is not practical (and in some cases not compliant). A
RADIUS or similar service for administrative accounts should be placed within this
enclave. This will also provide a convenient method of centralized management of
authentication controls (e.g., password complexity, rotation, etc.). Insider threats should
be strongly considered when designing this enclave.
The velocity of traffic for 40GbE networks is very high, making management a
challenge. This enclave creates even more complexity because of the high volume
combined with small packets. Security Information and Event Management (SIEM)
automation is critical for processing and correlation is necessary. Events from IDS (e.g.,
replay attacks, fragmentation attacks, buffer overflow attacks, etc.), firewall (e.g., DoS
attacks, port errors, dropped packets), SSL (e.g., DoS attacks, certificate errors, session
drop), reverse-proxy (e.g., dictionary logon attacks, cached content change, etc.), and file
integrity monitoring can collectively overwhelm the SOC staff and SIEM platform
without proper planning.
4.8.2.
All network application servers that serve the N-Tier Application enclave silo
reside within this enclave. Network applications serving the Enterprise Core do not
reside within this enclave. Network applications include DNS, Logging, NTP,
management, monitoring, patch and release management, and SIEM. These services are
43
securely revealed into the remaining N-Tier Application enclaves using the
aforementioned iACLs.
Two Public Key Infrastructures (PKIs) are introduced within the enclave. The first
is for customer authentication of the services offered
(www.giacenterprisescooolmobileapp.com). The second is for non-console
administrative access to infrastructure components including SSL accelerators, firewalls,
IPS/IDS, reverse-proxies, and load balancers. PKI and certificate mismanagement at this
layer can impact customer trust (expiration and signing errors) and security control
integrity. In addition to PKI, DNS is offered from this enclave. This is necessary for
intersystem communication without embedding IP addresses (e.g., SSL accelerator needs
DNS to find HTTP server IP addresses). Mobile device and web browser names
resolution of www.giacenterprisescoolmobileapp.com is provided separately from this
infrastructure. Managed security providers or cloud hosted services (e.g., Symantec,
Entrust, etc.) are recommended for automation and administration to minimize the need
for additional internal resources to maintain these services securely.
DNS servers within this enclave point to trusted DNS Servers within the Enterprise
Core. For queries of external domains, the Network Application Enclave DNS servers
perform recursive lookups through the Enterprise Core DNS servers. Hosts within the NTier Application Enclaves are not permitted to query untrusted, external DNS servers
directly.
Functional isolation will result in a large number of servers within this enclave.
Servers residing in the network applications enclave connect to a high port density switch
with a high speed backplane. In addition, port aggregation may be required to link
multiple chassis together. Capacity and Performance Monitoring are vital for this enclave
as network application performance problems could manifest as application performance
problems. Through the security fabric the traffic is inspected and filtered real-time (e.g.,
firewall, IPS and inline AV, etc.) before going to its destination enclave and final system.
A network monitoring switch is required between the high speed Ethernet switch
and security fabric. The network monitoring switch provides an inline tap to capture and
monitor traffic without effecting enterprise services or having to schedule downtime
44
when the need arises. The network monitoring can then forward frames to a variety of
devices including IDS, forensic analysis, and data leakage analysis.
For managing the virtual environment, networking becomes a challenge at 40GbE.
Managing virtual network switching (in addition to guest CPU and memory demands)
can have a material impact on performance of the host system. When the network is
virtualized at this speed, the host must allocate more resources to virtual switching and
starves guest resources. Several vendors are approaching this issue with very different
solutions. Some are offering virtual switching in which a separate host is providing the
resources for switching. Others have taken an approach of eliminating the virtual
switching with device drivers and redirecting virtual switching to actual switching with
external physical switches. This last approach presents a problem when there are only a
limited number of physical ports supporting 40GbE. As the cost per port drops, adoption
of the last approach may grow. Lastly, these new solutions provide SPAN ports, network
QOS and ACL control down to the VM level.
Visibility into network traffic flows in the virtual environment can be a challenge.
The monitoring controls (e.g., NetFlow/sFlow/jFlow) present in the physical switching
environment must be made available within the virtual environment. This is vital for
performance monitoring as well as security and anomaly detection. In some cases, the
switch vendor offers an option for virtual environments (e.g., Cisco Nexus 1000V). A
switch vendor agnostic alternative should also be considered (e.g., Lancope StealthWatch
FlowSensorVE).
NTP Servers reside within this enclave. Time synchronization is necessary for
system clocks, session management, and key management. Host time settings must also
be safeguarded from unauthorized change. For credible security event management, an
authoritative clock source is required (e.g., PCI DSS Requirement 10).
All administrative non-console access to network applications must be encrypted.
SSL or SSH are to be used with ciphers at least 128 bit. When available, mutual
authentication between jump boxes in the Management Enclave and hosts within this
enclave must be implemented.
Centralized infrastructure account management is performed within this enclave.
This service is not to be integrated with the customer or Enterprise Core authentication
45
solutions. A RADIUS or TACACS server is recommended. AD integration can be

consideredhowever there may not be any integration with the Enterprise Core AD.
Key rotation between authentication server and infrastructure components must be
performed at least yearly. Logging of authentication and access is required and retention
policies would apply.
Logging of events is required. These events must be reviewed daily or automation
must be implemented. Several categories of events would be gathered including
component failures, port errors, threshold exceeded, and security controls defeated.
Centralized logging is necessary for IT administrators as well as for security staff for
which the solution would reside within this enclave. Logged events from the other
enclaves make their way here for centralized analysis. The approach and solutions
implemented here of data aggregation and analysis by the monitoring group are outside
the scope of this paper.
This enclave additionally contains the NTP servers for the network. NTP time
synchronization is required for all routers, switches, servers, desktops, proxies and any
device capable of being synced (see Appendix A.6). Time synchronization is necessary
for credible correlation of events associated with security, syslog (see Appendix A.29),
SNMP/RMON (see Appendix A.17), NetFlow, as well as any application performance
monitoring servers.
Anti-virus, anti-spyware, malware detection, file integrity monitoring, configuration
management, and data leakage prevention are all necessary services and must be
considered as critical controls. Definition of these controls is outside the scope of this
paper, however the centralized management of these services would reside within this
enclave.
4.8.3.
Controls
46
enclave.
NTP in an environment can be implemented in many ways. Most commonly has
been the use of a local NTP master server that contacts a stratum 2 or stratum 3 time
server to synchronize time. That local NTP master server then is authoritative for
distributing time throughout the network. With the availability of commercial stratum 1
receivers that receive updates from either the US Naval Observatory or from a GPS
signal, the local NTP master server then becomes a stratum 1 time server for the entire
environment (See Appendix A.5).
An infrastructure DNS server is located here to service requests by any device or
host in the N-Tier Application and Infrastructure silos of enclaves. DNS requests for
lookups of Internet domains are sent to enterprise DNS servers that proxy access to
authoritative servers provided by trusted ISP or DNS service provider. Implemented here
are the DNS protocol extensions that form DNSSEC. DNSSEC provides a chain of trust
from the root DNS servers on down using public key cryptography (See Appendix A.32).
4.9.
B2B Enclave
This enclave is intended for connectivity to vendor partners and service providers.
For example, a company selling fortune cookies would have several connection
requirements including payment processors, call centers, warehouse, logistic services,
and managed services providers. Common business functions like accounting and
marketing may also require integration of their vendor partners and cloud based services.
This enclave must provide a versatile and secure means of connecting to these vendors
and hosted business systems.
Figure 4.9 B2B Enclave
4.9.1.
47
Global outsourcing and managed service providers are commonly engaged by

todays enterprise. Remote IT and business support services may be desirable, too. This
is another vector of attack that enterprises must consider.
Inspection controls (IPS, logging, etc.) must be implemented to protect the
confidentiality and integrity of data movement. Network engineers and security staff
should not lose this opportunity to verify trustworthiness of partners and providers. If
reconnaissance activity is detected, then the vendor must be notified immediately.
4.9.2.
The B2B Enclave is the entry point for partners data transfers. Due to the different
trust levels of the traffic coming in from partners versus traffic coming in from
customers, a separate ISP connection is recommended for B2B. A 40GbE router and
firewall at the edge are required for this alternate ISP connection. All access into the B2B
48
Enclave is challenged to validate the identity of the source prior to permitting access into
B2B and appropriate systems. A VPN service is implemented within this enclave to
perform this authentication as well as encryption. All B2B vendor connections must be
authenticated and encrypted using IPSec IKE and ESP respectively. The VPN function
may be offered by the security fabric or with a standalone appliance.
Once traffic is unencrypted by the VPN, an IPS is required for traffic inspection and
attack prevention within B2B. If the security fabric does not provide an IPS service, then
a standalone IPS is required. Vendor data flows should be terminated to a front end
application (e.g., Data Exchange Server) to process the request and validate the web or
application logic prior to being allowed into the backend data store.
Management connections by the vendors must not be allowed unmonitored and
must be pre-authorized formally. All vendor remote access must be forced through the
Management Enclave with a dedicated jump box or proxy. Connection to all other
enclaves and systems must be explicitly denied. Remote support sessions must be logged
for auditable record of vendor changes. Even changes to the vendors own asset must be
logged. This assists internal staff with identifying application anomalies that might occur
after a vendor makes changes to the way applications or systems operate.
Many different methods of data exchange will occur through this enclave including
managed file transfers (e.g., scp, ftp, sftp, etc.), Electronic Data Interchange (EDI),
electronic payment processing, and database gateways to vendors. In some cases the
partner or service provider will permit security associations using IPSec or SSL. In other
cases the vendor partner or service provider will require their own asset be installed
within the customer network. Payment processors commonly require their own VPN
appliance or dedicated circuit/router connection to be installed at the merchant location.
Systems may have to be installed that will reach out to cloud based services to retrieve or
push data. In short, there will be a considerable amount of network engineering that will
be required within this enclave.
With all these leads and feeds, it may be beneficial to create a data exchange
server. Several vendors (e.g., IPSwitch, Sterling, Axway, etc.) offer managed file
transfer solutions that are intended to handle this many-to-many data movement.
Authentication, integrity checking, and encryption are incorporated into this one
49
centralized solution. Standards enforcement and operations are much more effective with
this approach.
4.9.3.
Controls
enclave.
This enclave provides access to and from B2B partners via VPNs, either of the
IPSec or SSL types (see Appendix A.22). The VPN terminates inside the enclave and is
inspected by the NIPS when data is in the clear.
Virtual Desktops provided to each external B2B partner create a secure
environment that can be monitored, restricted and reset after each use. This prevents
direct data transfers as well as limits the ability for the B2B partner to connect outside of
agreed upon hours.
4.10.
Management Enclave
The purpose of this enclave is to host administrator and support team jump boxes.
These jump boxes are used to gain access into the infrastructure for activities that require
high authority. For example, a member of the security team wants to update firewall
ACLs. This individual must pass through this enclave to access the firewall console or
policy manager. Direct access into the infrastructure is not permitted from administrator
PCs.
Figure 4.10 Management Enclave
4.10.1. Risk Considerations and Remediation Strategies

There a many components throughout this new infrastructure that will need to be
routinely accessed for configuration and update purposes. High Authority Accounts
(such as admin, sa, and root) are used to perform these duties. The security these
components offer can be easily defeated if high authority access is not properly
safeguarded. Further, many security controls are relaxed for high authority accounts.
There is an assumption that a conscientious administrator is at the wheel with all
appropriate safeguards. Of course, this may not always be the case. A variety of
individuals will require high authority access. This includes manufacture technical
support, help desk, NOC/SOC, administrators, MSP, outsourcing providers, and
operations support staff. This enclave provides a solution for secure administrative
access to protect the integrity of the security components themselves.
50
51
Also, if out-of-band management access is desired, further inspection and

monitoring is required to ensure this path is not exploited to circumvent firewalls and
other critical security controls. Network engineers will typically design this out-of-band
management network without considering how attackers may also use it. This enclave is
intended to contain the out-of-band and in-band management so that appropriate security
controls are engaged.
4.10.2. Technical Approach and Design Recommendations
The Management Enclave is the gateway to manage all servers and equipment in all
enclaves. To control and track administrator access, all management services are denied
across all enclaves except from the Management Enclave. Inside the Management
Enclave, access is permitted using a white list approach via ACLs applied to the security
fabrics enclave connection. Logging is extremely critical to validate change controls are
effective and provide a centralized point of audit.
The Management Enclave is a high risk target because it is the gateway into the
other enclaves. To reduce the risk, a NAC appliance must be installed at the entry point
to the Management Enclave. An in-line based NAC appliance is recommended as
compared to software agents. This is simpler to implement and maintain. It provides
clients and authentication validation through a redirected browser session as compared to
requiring a full client to be installed in advanced. This option provides flexibility to
control guest accounts and non-organization issued devices being connected to the
network. It also provides a method to validate that vendors meet the organization's
minimum security requirement prior to be being granted access to the network. At the
time this paper was written, several vendors offer products in this vector. For example,
Cisco offers the Clean Access NAC and McAfee currently offers a NAC appliance.
Ideally, all management access must go through a secure proxy server, with access
enforced via ACLs. Management access that does not support a proxy or browser client
must have client software installed on jump servers with access controls (i.e.,
authentication and network ACLs). Access to the proxy server and jump box requires
multi-factor authentication and AES128 encryption.
52
All access through the Management Enclave must be logged. This includes proxies,
jump boxes, and network applications. Logs are then presented to a correlation engine
for processing and alerting. Further, logs must be gathered and archived in a secure
location to prevent unauthorized access and alteration.
Multiple jump boxes should be created to separate vendor access from trusted
employee access. This approach allows creation of specific ACLs based on functional
role (network administrator, DBAs, etc.) and the asset value of the target system ACLs
must prevent any user or administrator from connecting to any management ports or
services without passing through Management Enclave. Further, ACLs must prevent
direct file transfer from Management Enclave. File transfer (e.g., TFTP for router OS and
service pack for Microsoft Windows OS) must be sourced from Network Application
Enclave. To upload files or patches administrators must go to the appropriate jump box
then connect to the release management server to upload the required files. Once
formally authorized, the files are scanned and submitted or transferred via the release
management software to release and apply the approved patches.
Management service authentication and authorization are maintained by a system
located within the Network Application Enclave. This identity and access management
service must be separated from all Customer and Enterprise Core services. Explicit
blocking of traffic between the other authentication systems outside of this enclave is
required. The management authentication services are the most critical due to the
elevated privilege provided across the organization. Rigorous Identity and Access
Management policies (IAM) for high authority accounts must be enforced here. This
includes password policies, naming conventions, idle timeout, and automated disabling of
unused accounts. Further this control is a common target for audits.
Data Loss Prevention (DLP) controls must be placed within this enclave. Managed
file transfers and release management are to be orchestrated using this enclave, however
the actual file transfer (ETL, firmware upgrades, patches, etc.) occur from the Network
Applications Enclave. This way data integrity inspection can be done, malware scanning
can be done, and release management controls can be enforced. Further, data leakage is
prevented using the administrator non-console connection.
53
Based on the number of interfaces needed, a smaller form factor stacked switch is
recommended. This provides physical security advantages in addition to lower per port
costs. In-line TAP or a monitoring switching in this instance is included as a part of the
design to allow for traffic capture and analysis outside of switching. This approach also
avoids downtime to implement inspection tools in the event of problem or security
incident.
Network taps and network management solutions that provide in-line access to
network traffic are consolidated into this enclave for console and non-console
administrative access. NIDS, forensic analysis tools, packet capture and performance
monitoring solutions are integrated into the taps here.
4.10.3. Industry Best Practices and Authoritative Sources for Security
Controls
enclave.
Network Access Control, NAC, solutions are implemented in this enclave providing
network level policy compliance for computers in the Enterprise Core as well as for
remote access users to ensure that computers meet the required antivirus, HIDS/HIPS and
operating system patch versions (See Appendix A.33).
Multi-factor authentication is implemented in this enclave wherein we verify the
administrator or users identity from not only a password but another mechanism like a
token, SMS message, smartcard or biometrics which is necessary to minimize use of
compromised passwords.
All network devices (e.g., routers, switches, firewalls, etc.) must implement AAA
services. This ensures that password policies are enforced, that account access is revoked
in a timely manner, that the correct levels of authorization are enforced, and a record of
account usage (see Appendix A.7) is created.
Terminal servers, virtual desktops, KVMs, and jump boxes allow the administrator
to connect to a machine that is a launching point to the management device they are
54
attempting to connect to. This centralized point of connectivity reduces the number of
ACLs that must be implemented on the networking devices.
4.11.
Enterprise Core
This is the existing network that collectively defines the enterprise. This includes
LANs, WANs, MPLS, or similar network connectivity as well all hosts and applications.
Controls for the Enterprise Core are out of scope for this document. However, there are
some general assumptions that should be addresses.
Figure 4.11 Enterprise Core
55
4.11.1. Risk Considerations and Remediation Strategies

Many of the IT staff will use PCs that reside within the Enterprise Core. Remote
access may be provided into the Enterprise via PC VPN or site-to-site connections.
Remote access into the enterprise (e.g., PC VPN) may be indistinguishable from local
access within the enterprise. All these access points can be used as a vector of attack into
the aforementioned enclaves. Therefore, all interactive administrative access from the
Enterprise Core must first pass through the Management Enclave and be inspected.
Segmentation of systems and services within Enterprise Core is highly
recommended to create separate communities based on data classification and risk. As a
minimum, systems and services revealed into N-Tier Application Data Enclave silo
should be segmented. This provides security advantages as well as makes routing easier
to design.
4.11.2. Technical Approach and Design Recommendations
Controls for the Enterprise Core are not in scope for this paper. The Enterprise Core
contains the organizations internal systems and applications (e.g., HR, Finance, email,
file services, etc.). This infrastructure is separate and distinct from the new infrastructure.
All network applications (e.g., DHCP, DNS, etc.) necessary for the Enterprise Core are
contained within the Enterprise Core. None of the aforementioned network applications
or security services are reused for the Enterprise Cores needs.
The DNS Servers within Network Application Enclave will reach into Enterprise
Core to query third-party domains. These DNS Servers within the enterprise must be
properly secured to prevent DNS poisoning. The DNS Servers within the Enterprise
Core will use separate controls and Internet access than that used by the aforementioned
Internet Access Enclave.
A standalone firewall is required to separate the Enterprise Core from the new
infrastructure. This firewall is similar to the firewall placed within the Internet Access
Enclave in that it serves as a demarcation point and is intended to prevent attacks that
exhaust resources. ACLs within the firewall restrict access to predetermined services and
hosts.
56
NAC must be implemented at the border between the Enterprise Core and the
Management Enclave to provide security control inspection of administrator computers.
Administrator computers must be inspected for Anti-Virus, HIPS, and patching prior to
being permitted access into the Management Enclave.
5. Recurring Security Service Considerations

The following services are necessary for maintaining the new
infrastructure in a commercially reasonable and compliant manner.
Managed Security Service Providers should be considered for these
obligations to supplement current IT resources. In some cases an MSP
should also be considered for seasonal demands (e.g., Chinese New
Year customer volume for fortune cookies).
5.1.
Patch and Vulnerability Management
Typically, network engineers will consider in their plans common operational duties
associated with break/fix. However, one of the most common causes of system outages
and service interruption is changenot component failure. Change is typically
accelerated for public facing infrastructures. Part of this change is driven to continually
improve the customer experience. Part of this change is to deploy patches and security
updates. Microsoft Patch Tuesday is an example of routine vendor notification of product
defect that demands at least monthly updates.
A patch and vulnerability program is required to automate product defect discovery
and remediation delivery to this new environment. Patch and vulnerability management
framework must be in place for network and security software. This mitigates
exploitation of network product defect or code errors. Software should follow the version
control method used by the company as well as the vetting process for rollout of software
and firmware (see Appendix A.19). Depending on the regulatory requirements, a formal
patch and vulnerability management program might be required for compliance (e.g., PCI
DSS 2.0 Requirement 6 Develop and maintain secure systems and applications). NIST
provides a very credible resource (Special Publishing 800-40v2) for creating a patch and
vulnerability management program.
5.2.
57
Vulnerability Scanning and Penetration Testing
Inspect what you expect is a popular slogan that security professionals know well.
For the infrastructure proposed in this document, regular inspection of security controls is
required. A vulnerability scanning solution must be incorporated into the design so that
systems can be tested for configuration and product defect weaknesses. In some cases,
this testing may be required quarterly for compliance reporting. If this is the case, then
automated vulnerability scanning solutions by an authoritative source should be strongly
considered.
In general, there are three categories of vulnerability scanning. The first category is
network based vulnerability scanning. Products like Nessus, Qualys, and Foundstone
(McAfee) scan hosts and network infrastructure over the network to identify weaknesses
that might be exploitable. These products are also useful for asset profiling and
identifying unintentional sensitive data leakage. The second category of vulnerability
scanner is more specialized and focuses in on web applications. Products like Burp, IBM
AppScan, and HP WebInspect review HTTP content to determine if common website
attacks (e.g., parameter manipulation) can be effective. The last category of vulnerability
scanning is source code security analysis. Products like HP Fortify and Veracode Static
examine program code for vulnerabilities including potentially insecure library functions,
control flow errors, bounds checking errors, and buffer overflows. All three of these
categories are necessary for comprehensive vulnerability scanning.
In addition to vulnerability scanning, a more thorough testing is required
periodically. Penetration testing must be done just prior to initial promotion of this
infrastructure to production, as well as on a yearly basis. Penetration tools like
Metasploit and Core Security Technologies Core Impact simulate a variety of common
attacks to reveal the cause, effect, and prevention of breaches. They include thin agents
that are used on compromised hosts to pivot through the infrastructure. This approach
provides insight into the methods advance persistent attack would use.
With each major change, vulnerability scanning and penetration testing must be
performed. The network architecture will have to include integration of these tools into
58
every enclave. Simply scanning from the Internet is not adequate. This practice ensures
intentional or unintentional changes do not introduce new material risks.
5.3.
Asset Management and Configuration Management
Database
There are quite a large number of components to this proposed architecture. The
network engineering team has many assets to design and build. Building out a 40GbE
infrastructure is a significant investment with recurring financial obligations. Because of
these considerations, an Asset Management and Configuration Management Database
(CMDB) are highly recommended. Asset information includes component specifications,
configuration, maintenance providers, support contracts, and financial obligations. This
information should all be stored in a centralized and secure warehouse. The assets are in
many cases inter-related (e.g., data mapping). Configuration Items (CI) and element
relationship information are tracked within a CMDB. Asset Management and CMDB
solutions provide many benefits including access to as-built information for operations
staff, configuration information for future design enhancements, and useful forensic
information. Organizations considering a 40GbE network and deployment of mobile
applications are strongly advised to implement a system to organize and maintain the
configuration information in a secure manner.
5.4.
MSSP
Many IT services were mentioned in this paper. An enterprise embarking on a new

web presence should consider the operational impact to existing IT resources and
processes. Bench strength may be required to serve the demands of a global customer.
Managed Security Service Providers (MSSP) can offer this support. An MSSP can
perform operational duties such as DNS hosting and administration, patch and
vulnerability management, firewall administration, IPS monitoring and response, PKI
management, SIEM hosting and monitoring, and perform first responder duties. The
enterprise does not have to tackle these duties alone. Engaging an MSSP can be cost
effective and measurably improve service delivery.
5.5.
59
CSIRT
Rapid response is critical for organizations considering Next Generation networks.

A comprehensive computer security incident response plan must be in place prior to
production release of the new infrastructure. Roles and responsibilities must be clearly
communicated in advance of a serious security incident. Enterprises are advised to
engage organizations with incident handling expertise and services. Services to consider
include CSIRP development, incident handling training, mock incident exercises,
incident response, and litigation support.
5.6.
Audit and Compliance
Depending on the data classification of the new website, a formal audit may be
required. For example, web sites intended to accept credit cards for payment will require
an audit by a PCI certified Internal Security Assessor (ISA) or Qualified Security
Assessor (QSA). Audits may have to be performed routinely and after any major change.
Engaging auditors during the network design phase will help to ensure all controls
including inspection controls for auditors are incorporated properly.
In addition to periodic review by auditors, inspection of controls may have to occur
frequently to demonstrate the required security controls and safeguards have been
working continuously between audits. Automation of this frequent inspection is
recommended. Tools like Tripwire Enterprise can be used transparently to credibly
demonstration that the security controls have been sustained in a commercially
reasonable and compliant manner. These same tools can be used for quality control and
change management reconciliation, too.
6. Lessons Learned
Before authoring this paper, the STI team approached vendors, consultants, and
early adopters of 40GbE to share their expertise and lessons learned. This section calls
out specific feedback regarding pitfalls, promising solutions, and strategies for success.
6.1.
60
Pitfalls
Firewall ACL optimization is required for rapid implementation of changes and

firewall performance. In addition to ACL optimization, network engineers must consider
the number of flows passing through the firewall. Though a firewall may have a new
40GbE interface that is 40 times faster than conventional 1GbE interface firewalls, the
state table buffer may not be the same order of magnitude larger. 40 times more flows
may not be possible with 40GbE. Firewalls might be overwhelmed with stateful flow
management long before the physical Ethernet interface is saturated because the same
silica from 1Gbps interface firewalls is being reused for buffering. This may result in
unexpected outcomes such as random session loss through the firewall. Worse, buffer
overflow conditions may occur resulting in a fail closed condition that passes traffic that
should be denied. Remember to research limitations of flow tables, IP tables, and routing
tables.
With high-speed networks, tracking traffic can be a challenge. NetFlow systems
provide valuable insight for both network and security engineers. Unfortunately, the
NetFlow system capacity may have been intended for the total number of flows
associated with 1Gbps Ethernet. The aforementioned firewall flow management
condition can occur with NetFlow systems, too. A 40GbE switch network between a
Web Application Server and Database server may still be supported with existing
NetFlow management solutions. However, 40GbE with many brief flows (e.g., Internet
clients accessing SSL Accelerator) may cause existing NetFlow management platform
integrity and capacity issues. Further, NetFlow data from a 40GbE network could
unintentionally saturate 100Mbps and 1Gbps connections that lead to the NetFlow
Management platform.
40 gigabit speed Ethernet can be achieved in a variety of ways. Port aggregation
technologies available today provide the ability to achieve 40 gigabit speed. However,
the implementation of this feature may prevent integration of new security controls inline. For example, the 4x10GbE uplink between switches might be done in a proprietary
way that is incompatible with a 40GbE interface on a new IPS. Network Engineers are
61
advised to review current port aggregation implementation if legacy equipment

integration is required. This is especially true for todays blade server technology.
Physical switches running at 10GbE and 40GbE can quickly overwhelm virtual
switches within hypervisor platforms. Baselines for processing by the hypervisor
platform will change when integrating physical high-speed Ethernet. A blade server
chassis can also experience similar drinking from the fire hose conditions. Network
design should include considerations for all data flowsphysical and virtual.
Serialization delay, latency, queue delay, jitter, and packet fragmentation are still
present with 40GbE. These conditions must still be a design consideration when building
40GbE networks. Improper implementation of QoS will be negatively impactful to
actual throughput and quality. Mismanaged traffic will result in more work for the
security controls to follow flows for threats and policy enforcement. When the security
controls are over-utilized with network traffic tracking, the network throughput quickly
declines.
Forensics and Incident Handling teams are only now beginning to ramp up for
40GbE. Enterprises must be careful not to get too far ahead of incident handling teams,
law enforcement, and assessment teams. In the event these teams are not prepared to
work with the 40GbE infrastructure, the enterprise may find work being done on
production systemsor that the production systems may get confiscated to conduct
investigations.
6.2.
Promising Solutions
Today, many vendors have available firewalls with backplane speeds of over
500Gbps. These same firewalls have integrated switching fabric and the ability to add
security applications such as IPS, IDS, in-line virus and spyware scanning, proxy, WAF,
and DAM. This integrated platform is sometimes referred to a security fabric. The
designs are modular, with specialty processors provided for each of the security services
to optimize performance. This modular design also allows capacity to be added without a
forklift approach. Further, the backplanes allow presentation of a packet to multiple
services simultaneously. This parallel processing reduces latency considerably as
compared to using external appliances serially connected 40GbE. In addition, these
62
vendors offer integrated management solutions with a standard user interface. System
administrator and operator staff benefit from the management software consistent look
and feel. Today, security fabric solutions do have a limit of 1Gbps and 10Gbps Ethernet
external physical interfaces. 40GbE physical interfaces are not expected until later in
2012.
Third-party Firewall Policy Management (FPM) vendors include
AlgoSec, FireMon, LogLogic, RedSeal Networks, Skybox Security, and
Tufin. They are extremely helpful for optimization and visualization so
that administrators can effectively reduce firewall rules and policies.
They also provide insight into permitted data flows across multiple
firewalls (even from multiple firewall vendors).
Flows through the virtual environment can be a blind spot for network and security
engineers. Increase the network speed to 40GbE, and even more uncertainty occurs.
Several switch vendors are offering software switches for the virtual environment. These
solutions replace the default virtual switch found on the hypervisor platform. Products
from Cisco (Nexus 1000V) and Lancope (StealthWatch FlowSensor VE) are useful in the
virtual environment for anomaly detection, data flow mapping, and network performance
monitoring.
The new IEEE 802.1AE standard (also known as MACsec) provides a new method
of protecting data traversing Ethernet LANs without the hosts having to provide CPU
cycles to benefit from the encryption. The switching fabric performs the host
identification using LLDP, Kerberos Snooping, IEEE 802.1af, or static configuration. No
802.1X supplicant is required on the host. Once authenticated, traffic is passed
encrypted. This standard also provides an effective method to identify and isolate
unauthorized hosts on a LAN. Communication with these unauthorized hosts is
automatically prevented. Snooping attacks are also defeated. Several switch vendors
have announced this standard is on their product road map.
6.3.
63
Strategies for Success
While in the network design phase, consider how an attacker will be able to exploit
this new 40GbE architecture. This will foster conversation about the need for security
controls and choke points. In addition, this will drive solutions that will be able to handle
the volume and type of threats associated with high speed networks. Smurf and Bot
attacks can be highly effective if reflected off a 40GbE network. Data leakage is also
harder to detect when deluded within 40GbE flows.
Document the existing data flows before designing the new network. Understand
how traffic is intended to flowas well as how traffic is actually flowing. This can lead
to constructive discussions about the requirements for the new network (and associated
security controls).
Consider the financial benefits of 40GbE in addition to the performance benefits.
Port aggregation has several cascading expenses including Ethernet NICs, Ethernet ports,
LIU ports, fiber patch cables, and host I/O. A single 40GbE connection may be a fraction
of the cost of a 4x10GbE connection.
Leverage automation to handle the velocity of 40GbE traffic. Resiliency depends
on clear understanding of operational and security threats. A 40GbE network can fail just
as quick (or even quicker) as a 1GBps network. Automation scope includes people,
process and technology. Consider cloud offerings and Managed Service Providers.
Develop scripts for repetitive processes as well as security incident procedures.
Implement technologies such as SIEM, Firewall Policy Managers, and NetFlow
Managers.
Lastly, efficiencies gained by 40GbE may be lost with unplanned security
investment requirements. The planned speed and unplanned spend of 40GbE networks
can be several orders of magnitude larger than that of conventional 1GbE networks.
64
7. References
Aggarwal, V. (2010). 40 GbE will be an important technology for the data center.
Retrieved from http://m.informationweek.in/Data_Center/10-0924/40_GbE_will_be_an_important_technology_for_the_data_center.aspx
Anue Systems Inc. (2002-2011). Anue 5288 Net Tool Optimizer . Retrieved from
http://www.anuesystems.com/resource-library/datasheets/anue-5288-net-tooloptimizer-data-sheet
Antoine, V., Bongiorni, R., Borza, A., Bosmajian, P., Duesterhaus, D., Dransfield, M., . . .
Ziring, N. (2005). Router Security Configuration Guide (Report No. C4-040R02). Retrieved from http:// www.nsa.gov/ia/_files/routers/C4-040R-02.pdf
Blade Network Technologies. (2010). 40G and 100G Ethernet. Retrieved from
http://bladenetwork.net/userfiles/file/PDFs/WP_40G_and_100G_Tech_Brief.pdf
Blue Coat Systems, Inc. (2011). Blue Coat Full Proxy Edition ProxySG 900/9000.
Retrieved from
http://www.bluecoat.com/sites/default/files/documents/files/bcs_ds_fullproxy_90
0-9000_v6b.pdf
Brocade. (2010). 40 Gigabit and 100 Gigabit Ethernet Are Here! Retrieved from
http://www.brocade.com/forms/getFile?
p=documents/white_papers/40_100_GbE_Are_Here_WP.pdf
Brocade. (2010). 40 and 100 Gigabit Ethernet Overview. Retrieved from
http://www.brocade.com/downloads/documents/white_papers/higher-speedethernet.pdf
Center for Internet Security. (2011). Security Configuration Benchmark for Cisco IOS
(Version 3.0.0). Retrieved from http://benchmarks.cisecurity.org/en-us/?
route=downloads.benchmarks
Chanda, G., Yang, Y. (2010). 40 GbE: What, Why & Its Market Potential. Retrieved
from http://www.cse.ohiostate.edu/~panda/788/papers/1h_40GbE_What_Why_Its_Market_Potential.pdf
65
Check Point Software Technologies Ltd. (2011). Check Point 61000 Security System.
Retrieved from http://www.checkpoint.com/products/61000-appliances/
Cisco Systems, Inc. (2006). Cisco XR 12000 and 12000 Series . Retrieved from
http://www.cisco.com/en/US/prod/collateral/routers/ps167/product_data_sheet090
0aecd8027c8dd.pdf
Cisco Systems, Inc. (2010). Cisco SAFE Reference Guide. Retrieved from
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/SAFE
_rg.html
Cisco Systems, Inc.. (2011). Cisco NAC Appliance. Retrieved from
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5707/ps8418/ps6128/prod
uct_data_sheet0900aecd802da1b5.pdf
Cisco Systems, Inc. (2012). Cisco Nexus 1000V Series Switches. Retrieved from
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/data_sheet_
c78-492971.pdf
Convery, S. (2004). Network Security Architecture [Kindle version]. Retrieved from
http://www.amazon.com
CrossBeam (2011). cross beam X-Series X60 & X80-S. Retrieved from
http://www.crossbeam.com/wp-content/uploads/DS_X60_X80S.pdf
Edelman, J. (2011). 40GbE Data Center Switching. Retrieved from
http://www.jedelman.com/1/post/2011/12/40gbe-data-center-switching.html
Extreme Networks, Inc. (2011). BlackDiamond 8800 Series Switches. Retrieved from
http://extremenetworks.com/libraries/products/DSBD8800S_1023.pdf
Extreme Networks, Inc. (2011). BlackDiamond X* Series Switches. Retrieved from
http://extremenetworks.com/libraries/products/PBBDX_Series_1778.pdf
Extreme Networks, Inc. (2011). Extreme Networks Direct Attach Implementation on
VMware ESX Server. Retrieved from
http://extremenetworks.com/libraries/solutions/ANDAVMwareESX_1745.pdf
Extreme Networks, Inc. (2011). Summit X670 Series Switches. Retrieved from
http://www.extremenetworks.com/libraries/products/DSSumX670_1777.pdf
F5 Networks. (2011). Platform Guide: 11050. Retrieved from
http://support.f5.com/content/kb/en-us/products/bigSTI Joint Written Project
66
ip_ltm/manuals/product/pg_11050/_jcr_content/pdfAttach/download/file.res/pg_1
1050.pdf
IBM. (2009). Confronting HPC Cloud Computer Security Concerns. Retrieved from
http://www.hpcwire.com/whitepapers/2009-1023/confronting_hpc_cloud_computing_security_concerns.html
IBM. (2011). IBM InfoSphere Guardium. Retrieved from
ftp://public.dhe.ibm.com/common/ssi/ecm/en/imd14286caen/IMD14286CAEN.P
DF
IBM. (2011). IBM System Networking RackSwitch G8264. Retrieved from
http://www.redbooks.ibm.com/technotes/tips0815.pdf
ICANN. (2008). DNSSEC @ ICANN. Retrieved from
http://www.icann.org/en/announcements/dnssec-paper-15jul08-en.pdf
Imperva. (2008). Imperva Data Security and Compliance Lifecycle. Retrieved from
http://www.imperva.com/docs/WP_Regulatory_Compliance.pdf
Imperva. (2009). Protecting Databases from Unauthorized Activities using Imperva
SecureSphere. Retrieved from
http://www.imperva.com/docs/WP_Protecting_Databases_from_Unauthorized_A
ctivities.pdf
Imperva. (2011). The Business Case for Database Security. Retrieved from
http://www.imperva.com/docs/WP_Database_Security_Business_Case.pdf
Interface Masters Technologies, Inc. (2011). Niagara 4232-4XL . Retrieved from
http://www.interfacemasters.com/pdf/Niagara_4232-4XL.pdf
NIST (2005) Special Publication 800-40 Version 2.0 Creating a Patch and Vulnerability
Management Program. Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf
NIST (2006) Special Publication 800-92 Guide to Computer Security Log Management.
Retrieved from http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
NIST (2007) Special Publication 800-95 Guide to Secure Web Services. Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
67
PCI Security Standards Council (2010), Payment Card Industry (PCI) Data Security
Standard Requirements and Security Assessment Procedures (Version 2.0).
Retrieved from https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
PCI Security Standards Council, Virtualization Special Interest Group. (2011).
Information Supplement: PCI DSS Virtualization Guidelines (Version 2.0).
Retrieved from
https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf
SANS Institute. (2011) Twenty Critical Security Controls for Effective Cyber Defense:
Consensus Audit Guidelines (Report No. 3.1). Retrieved from
http://www.sans.org/critical-security-controls/cag3_1.pdf
Schudel, G., Smith, D. J. (2008). Router Security Strategies [Securing IP Network
Traffic Planes] [Kindle version]. Retrieved from http://www.amazon.com
U.S. Department of Commerce, National Institute of Standards and Technology. (2010).
Guide for Assessing the Security Controls in Federal Information Systems and
Organizations: Building Effective Security Assessment Plans (NIST Special
Publication 800-53A Revision 1). Retrieved from
http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
Wexler, S. (2011). Sourcefire Claims First IPS For 40 GbE. Retrieved from
http://www.networkcomputing.com/wan-security/231900482
68
APPENDIX A: Secure Network Engineering Benchmarks

and Standards
Overview
This appendix contains specific reference locations as a supplement to the best practices
outlined in the enclaves above. While this list is not exhaustive, it is intended as a
launching point for further research. At the end of this section additional reference
material is listed which may be of further benefit.
1. BGP
Schudel & Smith, 2008, BGP Security Techniques, para 1-3.
Schudel & Smith, 2008, AS Path Limits, para 1-2.
2. ACLS
2.1. Infrastructure
Schudel & Smith, 2008, Interface ACL Techniques, para. 3.
2.2. Anti-spoofing
2.3. Transit
2.4. Classification
Schudel & Smith, 2008, Interface ACL Techniques, para. 3
69
3. Firewall
Convery, 2004, Network Firewalls, para 1.
Convery, 2004, Application Firewalls, para 1.
4. Dedicated Management LAN

Schudel & Smith, 2008, Chapter 6. IP Management Plane Security
5. NTP Service
Antoine et al., 2005, p.146
6. AAA Services
Schudel & Smith, 2008, Authentication, Authorization and Accounting, para 1-7.
7. Unused Services
Schudel & Smith, 2008, Disabling Unused Management Plane Services, para 1-3.
Convery, 2004, Disable Unneeded Services, para 1.
8. General Router Hardening
8.1.
Logins and Banners

Schudel & Smith, 2008, System Banners, para 1-2.
Convery, 2004, Login Banner, para 1.
8.2.
Router Network Traffic and the Loopback Interface

Antoine et al., 2005, p. 58
8.3.
Black hole routing

Schudel & Smith, 2008, Remotely Triggered Black Hole
Filtering, para 1-15.
8.4.
Remote management via ssh/https

8.5.
Disabling IP source routing

Schudel & Smith, 2008, Disable IP Source Routing, para 1.
8.6.
ICMP Best practices

Convery, 2004, ICMP Design Considerations, para 1-3.
8.7.
IP options selective drop

Schudel & Smith, 2008, IP Options Selective Drop, para 1-4.
9. Passwords
Convery, 2004, Reusable Password, para 1-2.
Convery, 2004, Password Encryption, para 1-3.
10. Role based CLI access

Schudel & Smith, 2008, Role-Based CLI Access, para 1-5.
11. IP Directed broadcast and ICMP direct broadcast

disabling
Convery, 2004, Smurf, para 1-4.
Schudel & Smith, 2008, Disabling IP Directed Broadcasts, para 1-4.
70
12. NIDS
Convery, 2004, Network Intrusion Detection Systems, para 1.
Convery, 2004, Inline NIDS, para 1.
Convery, 2004, NIDS Placement para 1.
13. HIDS
Convery, 2004, HIDS, para 1-4.
14. QOS
Schudel & Smith, 2008, QoS Techniques, para 1.
15. OTP / Multi-Factor Authentication

Convery, 2004, OTPs, para 1-4.
16. SNMP
Schudel & Smith, 2008, SNMP Security, para 1-4.
17. Rogue Device Detection

Convery, 2004, Rogue Device Detection, para 1-2.
18. Software Version Management

Schudel & Smith, 2008, Software Vulnerabilities, para 1-4.
71
19. NetFlow
Schudel & Smith, 2008, Network Telemetry and Security, para. 1
20. Routing Authentication

21. VPNS
Schudel & Smith, 2008, IPsec VPN Services, para 1-2.
Schudel & Smith, 2008, SSL VPN Services, para 1-2.
22. VLANS
Schudel & Smith, 2008, Disable Auto Trunking, para 1-3.
Convery, 2004, VLAN Trunking Protocol (VTP), para 1-3.
23. Proxies
Cisco, 2010, p. 6-17
24. Trusted zones

Cisco, 2010, p. 10-5
25. NAT
Schudel & Smith, 2008, Network Address Translation, para 1-12.
72
26. Virtual Machines

PCI Security Standards Council, 2011
27. Database Security

Impervia, 2011
IBM, 2011
28. Syslog
Convery, 2004, Syslog, para 1-2.
29. ARP Inspection

Convery, 2004, ARP Considerations, para 1-15.
30. Web Application Firewalls

https://www.owasp.org/images/a/a6/Best_Practices_Guide_WAF_v104.en.pdf
31. Virtualization
PCI Security Standards Council , 2011
32. DNS
ICANN, 2008, pg. 2
33. NAC
Schudel & Smith, 2008, Layer 2 Ethernet Control Plane Security, para 1-2.
73
74
Additional Benchmarks
The Center for Internet Security has dozens of benchmarks for operating systems,
networking devices, applications and mobile devices. The benchmarks are consensus
driven from subject matter experts across a wide range of operating environment (Center
for Internet Security, 2011). The U.S. Defense Information Systems Agencys Security
Technical Implementation Guides (DISA STIGs) also provide another set of benchmarks
dive deeper into the focus areas of network devices and operating systems (see
http://iase.disa.mil/stigs/). The combination of both resources along with the references
listed above should provide good coverage of the current authoritative best practices in
the industry.
Tools
Center for Internet Security

The Center for Internet Security has available benchmark assessment tools freely
available for download. The Router Assessment Tool, or RAT, ensures conformance to
CIS benchmarks by comparing a routers configuration against the benchmark.
Additionally the site has Apache HTTP, Oracle Database and UNIX Server Assessment
Tools.
http://benchmarks.cisecurity.org/en-us/?route=downloads.browse.category.tools.rat
75
APPENDIX B: Bill of Materials

Bill of Material Per Data Center
Description
Customer Facing segment
Internet Enclave
Security Fabric with 2 x 16 port 10 Gbps
Network Module, Firewall, IPS, AV module
Edge Firewall providing 40 Gbps interfaces
Edge Router with providing 40 Gbps
connectivity
40 GbE switch with 4 x 40 Gbps interfaces
and 48 x 10 Gbps ports
40 Gbps capable inline monitor / tap
Device Example
Quantity
CrossBeam X80
CheckPoint 61000
1
1
Cisco 12816 Router
Extreme Networks Summit X670

Anue Systems 5288 monitoring switch
1
1
SSL Enclave
SSL offloading providing 40 Gbps wire speed
and 15 Gbps decryption
F5 BigIP 11050
4 x 40 Gbps load balancer
Interface Masters Niagara 4232-4Xl
Connection to security fabric Bound 4 x 10
Gbps ports
HTTP Enclave
Gbps ports
Connection to CrossBeam X80 Security

Fabric
Virtual switch for managing virtual machines Cisco Nexus 1000v for VMWare
Web Applications Enclave
Gbps ports
3
1
1
One per
each VM
host
1

Fabric
Virtual switch for managing virtual machines Cisco Nexus 1000v for VMWare
Inspect requests on the application level for Web application firewall
malicious content. One is needed for each
1
One per
each vm
host
VMWare ESX server

76
Web application firewall (Naxsi,

Layer7, F5, Trustwave, etc)
Web application IPS (Imperva)
Data Enclave
Connection to security fabric bound 4 x 10
Gbps ports

Fabric
Database Intrusion Detection System
10 Gbps interface cards for early
adopters
Database Intrusion Detection System

(McAfee etc.)
Customer Authentication Enclave
bound 4 x 10 Gbps Ports connected back to
External Cross beam Chassis
CrossBeam X80 Security Fabric

Security Fabric with 2 x 16 port 10
Gbps Network Module, Firewall, IPS,
AV module
Network Applications Enclave

Gbps ports

Fabric
Cisco Nexus 1000v for VMWare or

Virtual switch for managing virtual machines Extreme's Direct attach option
and 48 x 10 Gbps ports stacked
AV module
1
Agent per
server as
network
based is
limited to
1 Gbps
1
1
Agent per
server as
network
based is
limited to
1 Gbps
1
1
1
One per
each VM
host
1
1
High density 40 Gbps or 10 Gbps switch

B2B Enclave
Connection to security fabric bound 4 x 10
Gbps ports
Edge Router with providing 40 connectivity
Management Enclave
Gbps ports
77
Extreme Networks BlackDiamond X

Series switch

Fabric

CheckPoint 61000 with VPN Module
Cisco 12816 Router
1
1
1

Fabric

Cisco Clean access NAC, McAfee NAC
or similar inline NAC appliance

Although 40 Gbps proxy servers are not
available at the time this paper was written,
Management traffic is not very bandwidth
intensive. As the technology allows for 40
Gbps it can be used in this location
Blue Coat SG Proxy 9000
2
1
One per
each VM
host
Enterprise Services Segment

Internet Enclave
40 Gbps switch with 4 x 40 Gbps interfaces
Authentication Enclave
bound 4 x 10 Gbps Ports connected back to
External Cross beam Chassis
CrossBeam X80
CheckPoint 61000
Cisco 12816 Router
1
1
1

1
1
CrossBeam X80 Security Fabric
78


AV module
Network Applications Enclave

Gbps ports

Fabric
1
1
One per
each VM
host
1
AV module
1
Extreme Networks BlackDiamond X
High density 40 Gbps or 10 Gbps switch
Series switch
1
B2B Enclave
Gbps ports
Management Enclave
Gbps ports

Fabric

CheckPoint 61000 with VPN Module
Cisco 12816 Router
1
1
1

Fabric

Cisco Clean access NAC, McAfee NAC
or similar inline NAC appliance

Although 40 Gbps proxy servers are not
available at the time this paper was written,
Management traffic is not very bandwidth
intensive. As the technology allows for 40
Gbps it can be used in this location
Blue Coat SG Proxy 9000
Enterprise Enclave
2
1
One per
each VM
host
1 and 10 Gbps high density switch

Bound 12 x 10 Gbps Ports
79
Extreme networks BlackDiamond 8800

Series Switch
Fabric

JWP Whitepaper Hoehl Khalil

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

JWP Whitepaper Hoehl Khalil

Diunggah oleh

Hak Cipta:

Format Tersedia

Implementing and Automating

Critical Control 19: Secure Network

Enclaves are interconnected using a security fabric. A security fabric is created

Introduction to SANS Critical Security Control 19

The SANS Institute, in collaboration with many other organizations, extracted

STI Joint Written Project

Network Challenges for Next Generation Networks

STI Joint Written Project

Secure network engineering begins with gathering documentationnot creating

Data Center Physical Controls

STI Joint Written Project

Firewalls and Security Applications

STI Joint Written Project

Internal DNS must be designed in a hierarchical manner. Secure

STI Joint Written Project

System and Infrastructure Hardening

System and infrastructure hardening is required. Benchmarks from SANS, CIS,

Configuration and Change Management

Automated file-integrity monitoring (also known as change-detection software) is

Virtual Server and Blade Server Management

Virtual switching is inherent to hypervisor platforms. Care must be taken when

STI Joint Written Project

Vulnerability and Threat Management

Vulnerability scanning and penetration testing must be performed routinely.

Threat monitoring with actionable intelligence is a prerequisite for rapid response.

STI Joint Written Project

An asset management or CMDB is required to track assets and configuration

Authentication, Authorization, and Auditing (AAA) systems for customers must be

STI Joint Written Project

Microsoft Terminal Server, Citrix, and VMWare. Multi-factor authentication is required

Support for forensic analysis and network monitoring Out-of-band is required.

4. Secure Network Engineering Practices for Next

STI Joint Written Project

STI Joint Written Project

Internet Access Enclave

STI Joint Written Project

Risk Considerations and Remediation Strategies

STI Joint Written Project

Technical Approach and Design Recommendations

STI Joint Written Project

Industry Best Practices and Authoritative Sources for Security

STI Joint Written Project

STI Joint Written Project

Risk Considerations and Remediation Strategies

Man-in-the-middle, session high-jacking, Cross-site Scripting (XSS), and denial of

Technical Approach and Design Recommendations

Inspection of unencrypted traffic as it traverses other enclaves.

Elimination of SSL processing on servers

Implementation of an application layer firewall. Several SSL accelerator products

Industry Best Practices and Authoritative Sources for Security

STI Joint Written Project

STI Joint Written Project

Risk Considerations and Remediation Strategies

STI Joint Written Project

Technical Approach and Design Recommendations

STI Joint Written Project

Industry Best Practices and Authoritative Sources for Security

STI Joint Written Project

multi-factor authentication, separation of roles and privileges, and disabling or removing

Web Application Enclave

STI Joint Written Project

Risk Considerations and Remediation Strategies

STI Joint Written Project