Adaptive Zone Defense – Part 3

Adaptive Zone Defense – Part 3

Adaptive Zone Defense – Part 1
Adaptive Zone Defense – Part 2
Adaptive Zone Defense – Part 4

How do you contain an advanced threat? We continue our series focused on limiting and intelligently managing communications between services and systems on an organizations network to baseline and be able to identify anomalies.

In Adaptive Zone Defense – Part 1 we presented the business case and security justification for limiting and managing traffic flows together with presenting the conceptual high-level Adaptive Zone Defense design as a foundation.

In Adaptive Zone Defense – Part 2 we presented another key foundation, known as Application Architecture Taxonomy that talks to a framework for application and system placement, organization and, management within the proposed zones.

In Adaptive Zone Defense – Part 3 we build upon the above foundation and framework to provide a practical use case that illustrates the more detailed implementation of the design with inter-zone flows together with some practical deployment and migration considerations.

Adaptive Zone Design Recap

As we discussed in Part 1, the conceptual Adaptive Zone Defense design proposes 7 foundational layers or zones that are described as, the Untrusted Zone for assets not under the organizations control, Semi-Trusted (DMZ) Zone for assets that are externally shared (either publicly or to 3rd parties), Trusted Zone for internal systems, Restricted Zone for high risk and/or mission critical systems, a Management Zone for network services and management systems and, an Audit Zone to isolate and protect security logging and monitoring.

There is also the concept of a Sub-Zone that is basically a Zone within a Zone that enables special cases, such as regulatory mandated segmentation.

High-Level Zone Design

Data Classification Mapping to Zones

Regulations and other legal and compliance requirements impact security requirements and thus may impose mandated separation or additional boundary controls. The following graphic presents an example of where data classification can map to zone placement, impacting policy and controls based also upon risk assessment.

Data Classification Mapped to Zones

This clearly illustrates that the Application Architecture Taxonomy is key since you cannot create and deploy zones absent a holistic analysis based upon several impacting criteria (see Example Application Architecture Taxonomy Matrix in Part 2). All too often a set of DMZs are designed and deployed that do not reflect a complete analysis or do not have strong governance and management, so that they devolve into a level of complexity that introduces insecurity — since the design is not faithfully employed and/or exceptions ever increasingly become the norm and are never addressed.

Applications and systems are a subset of Services that often have complex interfaces and connectivity, such that there are Applications and their Relationships as well as Users and their Relationships that need to be considered both to design zones as well as decide upon deployment placement, policy and, controls. If this has never been done before in an open network then it is like “untangling the spider’s web” of connectivity but – it is necessary in order to understand anomalies as well as intelligently manage traffic.

Virtualization is a key component and driver in terms of requirements, data points and constraints for the application and system zone design. As much as possible there needs to be a holistic and consistent approach across physical, virtualized and, 3rd party security controls (as needed for high risk, high bandwidth or, mission critical) in the hyper-extended enterprise (insourced, co-sourced, managed).

Example Zone Use Cases

The following section applies a typical deployment use case to the high-level design so that the organization can begin to model and validate the design before committing to it in deployment. In Adaptive Zone Defense – Part 4 we will further discuss how to model and validate the zone design as it is prototyped, checked in a proof-of-concept and, continually validated and evolved as the migration of applications rolls out in phased stages with any exceptions or new requirements addressed.

Adaptive Security Zones enable:

• Protection:
  • A ‘Managed Boundary’ for all user access to applications and systems
  • Implement granular controls on traffic, users and assets
  • Enforce policy and regulations
• Detection:
  • Gain visibility of traffic, users and assets
• Containment:
  • Control communications and resources on both inbound and outbound requests
  • Set a default deny policy on all inter-segment connections

Zone Design Use Case – External View

Example Zone Design Use Case - External

The above Example Zone Design Use Case – External presents the following zone placeholders (which depends on the analysis from the Application Architecture Taxonomy):

• External User Community –
  • Public (Internet-Accessible), Remote (IPsec/SSL VPN users), Partner (Site-to-Site etc.)
• DMZ Zone –
  • Public Servers (Internet Accessible)
  • Remote Access Services
  • Infra Services (DNS, SMTP, etc.)
  • B2B Partner connections
• Trusted Zone (Internal) –
  • B2B Services (Limited Access)
  • Dev.-Test Platforms (Controlled Environ)
  • Load Balancing, Web, App Services
  • Production Databases
• Restricted Zone –
  • High Risk / Critical Servers
  • High Risk / Critical Databases
• Management Zone –
  • Infrastructure Services (Internal)
  • Network Management
  • Virtualization Management
  • Backup
• Audit Zone –
  • Telemetry (DLP, NetFlow, PCAP, etc.)
  • SIEM
  • Analytics, Event Correlation
  • Central Logging

Zone Design Use Case – Internal View

Example Zone Design Use Case - Internal

The above Example Zone Design Use Case – Internal presents the internal view where open access is progressively limited leveraging consistent access controls into the environment, as follows:

• Internal User Community –
  • Internal, Developer, Privileged, IT Admin users
• Secure Business Unit –
  • Enables business units where regulations, legal and, compliance requirements impose mandated separation or additional boundary controls
• Data Center Perimeter –
  • VPN Gateway
  • Access Gateway

Secure Access Anytime from Any Device

The rationale behind limiting all access consistently is that the internal network is just a transport, like the Internet, wireless and, mobile with a mix of users (employees, contractors, temps) thus should not be implicitly trusted. As users become more and more mobile it makes access and user experience more challenging to support an open internal access security model and then a different remote access, vendor access, partner access security model. The complexity and fragmentation introduces significant risk.

Global Services Data Center Security Model

It is far simpler, in our opinion to treat the data center(s) as the (Server object) and wrap a consistent security perimeter around them that enables a Secure Access Anytime from Any Device (Client object) model. This model also facilitates the flexible secure movement of services across co-sourced, outsourced and, re-insourced hybrid clouds and service platform providers reducing risk and complexity.

The following example presents a basic but often typical example of a security snapshot and roadmap that helps organizations evolve towards Adaptive Zone Defense and a Secured Services Data Center security model on various needed fronts in a phased program.

Secured Services Data Center Roadmap

Deployment & Migration Considerations

• Governance & Process Integration – It is key to establish a strong governance structure with process integration for IT deployments
  • Strategy, Organization, Education
  • Standard Operating Procedures (SOP)
• Zone Data Center Deployment
  • Network Security Tiger Team – Leverage a cross-functional team (see below) to target batches of applications for analysis and migration
    • Perform initial heavy-lifting
    • Development and refinement
    • Process integration
    • Documentation and Operational transition
  • Phased: Zones, Application Controls, User Access Control, Role-Based Access, Secure Access Anywhere (Mobility)
• Application Architecture Taxonomy – See Adaptive Zone Defense – Part 4 for more details
  • Application Security Profile Form
  • Application Security Profile Catalog
• Enterprise Role Management – Evolve toward Identity Management to enable granular access controls with zero trust
  • Role-Based Access (Organize Users)

Conclusion

Security zone isolation for managed communications is a lot of work, at least initially, but it offers a tangible Return on Security Investment (RoSI) that helps stop that bad end-user(s), a weak remote office(s), a malware infection or, a persistent attacker from compromising the whole network. In that regard the advanced threat defense benefits are … priceless!

Add to that the benefits of the Secured Services Data Center with consistent access across the whole user community with the ability to place services in-house, co-sourced or, outsourced with agility and flexibility and it becomes a modular plug-and-play win-win.

In Adaptive Zone Defense – Part 4 we will tie everything together with the previous taxonomy, tables and worksheets (Part 2) to describe the rationale and process flow from examining a new application or system, reviewing the data classification, risk assessment and, criteria and, identifying the placement, policy and controls.

References

This Adaptive Zone Defense – Part 3 blog is also a part of the APT Strategy Series and Security Architecture Series. It complements and builds upon the Adaptive Zone Defense and the Defensible Security Posture blogs.

Thanks for your interest!

Nige the Security Guy.