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.

Zone Defense 3

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.

Conceptual Zone Design

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 Mapping

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

High Level Zone Design

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

Zone Design - 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

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 Service Roadmap

Secured Services Data Center Roadmap

Deployment & Migration Considerations

Zone Migration Flow

  • 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.

Adaptive Zone Defense – Part 2

Adaptive Zone Defense – Part 2

Adaptive Zone Defense – Part 1
Adaptive Zone Defense – Part 3
Adaptive Zone Defense – Part 4

Network segmentation is commonly used in network design to – increase network performance, create individually segmented networks to simplify network management, and divide networks up to create separate security zones. Because the APT is a “communicable disease” any part of a network involved with critical data can become infected.

Zone Defense 2

By limiting and intelligently managing communications between services and systems it helps contain an infection or compromise to keep malware or a persistent threat from running rampant.

Adaptive Zone Design Template

In Adaptive Zone Defense – Part 1 we proposed a conceptual and high-level security zone design template (see graphic) that we will use as a foundation in this series and build upon with some detailed use cases and traffic flows in Part 3.

Conceptual Zone Design

Conceptual Zone Design Template

In part 2 we are going to first develop another foundation, known as Application Architecture Taxonomy that talks to application and system placement, organization and, management within the proposed zones.

Application Architecture Taxonomy

The goal of the Application Architecture Taxonomy is to identify the requirements, dependencies and profile criteria needed to determine the application and system zone policy, placement, and controls.

The Application Architecture Taxonomy provides a correlation of application flows as an overlay to the network architecture in order to understand how traffic is delivered from the various user communities to the servers supporting the applications.

It provides understanding of who is talking to what and what portions of the network are used to deliver the services as a set of Applications and their relationships together with Users and their relationships.

The information discovered in the application taxonomy phase will be used to profile Application Use Cases as they are migrated to:

  • Define the types of data that exist and how best to establish risk classification (High, Medium, Low Risk) categories that meet the organizations business and risk requirements
  • Determine the requirements around application and system zone placement as well as the applicable security policy and controls needed to ensure that the network is deployed with the appropriate security.

The following table presents a list of the criteria that are useful in profiling the application, to identify security requirements for risk assessment and, to determine system placement and protection.

Example Application Architecture Taxonomy Matrix 1
 Example Application Architecture Taxonomy Matrix

Example Application Architecture Taxonomy Matrix 2

Security Control Solution Set

The Security Control Solution Set identifies the list of tools, technologies and, solutions that can be as options used to protect, log and, monitor applications and systems within the Zones and between Zones both physical and virtualized. An example table is illustrated below.

Security Control Solution Set

Example Security Control Solution Set

Risk Rating Controls Matrix

The Risk Rating Controls Matrix maps the risk, as determined by application or system criteria in terms of data classification, risk assessment and applicable law/regulation and/or policy to the minimum set of controls and restrictions that are required for the rating and/or zone placement.

Risk Rating Controls Matrix

Risk Rating Controls Matrix

Security Zones, Community & Controls

The Security Zones, Community and Controls worksheet enumerates all of the Security Zones and identifies the User Community (exposure) as well as applicable Controls that are applicable to manage the Zone Perimeter. This is a worksheet that is further developed and refined and maintained over time to describe and manage the design and current deployment.

Security Zones Community Controls

Security Zones, Community and Controls Worksheet

Security Zones, Perimeters & Protocols

The Security Zones, Perimeters, and Protocols worksheet is used to identify the connectivity between Zones across Perimeters and enumerates the allowed protocols between Zones as well as connection origination. This is a worksheet that is further developed and refined and maintained over time to describe the design and deployment.

Security Zones Perimeters Protocols

Security Zones, Perimeters, & Protocols

Conclusion

This blog provides a key foundation to describe a set of tables and worksheets that can be used to document the criteria needed to profile applications and systems as well as manage their security posture in terms of Zones, perimeters, placement, protocols, policy, community and, controls.

The worksheets enable best-practice management and organization, to prevent DMZs or Zones that organically evolve over time and are no longer compliant with the original security design and posture. They enable the inventory, classification and organization of critical data and assets with a focus on mapping Applications and their relationships together with Users and their relationships across and within Zones.

In Adaptive Zone Defense – Part 3 we expand upon the conceptual and high-level security zone design with application architecture taxonomy that was introduced in Parts 1 and 2 to provide some practical use cases and more detailed examples of its implementation with traffic flows and inter-zone relationships.

High Level Zone Design

We will also discuss application deployment integration, i.e., to ensure that this zone design and process is integrated into the greenfield deployment (or refresh) of applications and systems as well as a waiver process to manage temporary exceptions.

Coming Soon

In Adaptive Zone Defense – Part 4 we will tie everything together with the above taxonomy, tables and worksheets 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.

System Placement Process

References

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

Thanks for your interest!

Nige the Security Guy.

Adaptive Zone Defense – Part 1

Adaptive Zone Defense – Part 1

Adaptive Zone Defense – Part 2
Adaptive Zone Defense – Part 3
Adaptive Zone Defense – Part 4

Limiting and intelligently managing communications between services and systems on an organizations network helps contain an infection or compromise to keep malware or a persistent threat from running rampant. In addition, business needs, regulations and other compliance requirements impact security architecture and design and thus may impose mandated separation or additional boundary controls.

Zone Defense

This blog offers guidance to organizations seeking to develop a modular and scalable network segmentation design. The blog is a part of both the Security Architecture Series as well as the APT Strategy Series with the overall goal to improve security around protecting users, applications and access to data to enable a Defensible Security Posture.

Organize for Future Growth

There are dramatic technology changes that are driving today’s network security trends –

Big Picture

  • Mobile networks, VPNs and roaming users
    • Connect-from-anywhere road warriors test boundaries
  • Targeted attacks and APTs
    • Advanced Persistent Threats are next generation attacks
  • Consumerization and BYOD
    • Consumer devices are moving onto the corporate network
  • Web application and web server protection
    • Attacks on web applications to extract data are more prevalent
  • The Elastic Network
    • The perimeter is expanding to include high speed 4G, home offices, roaming users, cloud services, and third parties

Importance of Security Zones

Organizations and their IT environments are constantly changing. For some years, these “hyper-extended” environments have been growing more globalized, virtualized, distributed, and mobile. The resulting significant architectural changes require network security zones to become more modular and dynamic while maintaining a level of organization and proactive management to prevent complexity or fragmentation.

Network security zones that separate systems based on their communication and protection needs minimize security risks while allowing information flows to continue even in the face of failures and security incidents. This blog series helps organizations determine how to group IT resources into security zones bounded by network perimeter controls that enforce mandated separation policies.

Security Zones are put in place to:

Protect Detect Contain

  • Protection:
    • A ‘Managed Boundary’ for all user access to applications and systems
    • Implement granular role-based controls on traffic, users and assets
    • Manage Inter-Zone communications
      • Including between sub-zones
    • Enforce policy and regulations
    • Data confidentiality and integrity rules for data stored within a zone
  • Detection:
    • Monitor Inter-Zone communications
    • Gain visibility of traffic, users and assets
    • Logging and Event Correlation
    • Elevate alerts for events using a SIEM/Analytics
    • Prevent Inter-Zone data leakage using a DLP solution
  • Containment:
    • Control communications and resources on both inbound and outbound requests
    • Set a default deny policy on all inter-segment connections

The key benefits of network segmentation and policy-based Zones are, as follows:

  • Ability to Limit Exposure and Impacts
    • Access Control: Firewall, VPN, Proxy
    • Risk-Based Organization and Access
  • Focus on Protecting Critical Assets
    • Impossible to Protect Everything Equally
  • Ability to Detect Suspicious Activity
    • Visibility is Key (Sensors / Network Taps on Zone Gateways)
      • IDS/IPS, Netflow, Packet Capture, Traffic Analysis, Analytics
      • Network Behavior Anomaly Detection (NBAD)
      • Predictive Threat Modeling
    • Group Critical Assets and Users to Log and Monitor
  • Enable Containment of an Infection or Compromise
    • Lockdown a Zone or Sub-Zone to prevent further impacts
  • Expedite the Eradication and Recovery
    • Investigate
    • Incident Response
    • Recovery (Backup and DR)

Layered Zone Components

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.

  • Untrusted Zone
    • External Systems (not owned by organization)
      • Internet, Public data classification
  • Semi-Trusted (DMZ) –
    • Externally-Exposed systems
      • Public data classification
    • 3rd Party Exposed systems
      • Business Partner systems
  • Trusted Zone
    • Internally-Exposed systems
      • Internal data classification
      • Confidential data classification
  • Restricted Zone
    • High-Risk Mission Critical systems
      • Restricted data classification
  • Management Zone
    • Network Management systems
      • Virtualization Management
    • Security Management systems
  • Audit Zone
    • Regulatory Compliance
    • Security Logging
    • Security Monitoring (SIEM)
  • Sub-Zones
    • Zones divided into Subzones
      • Span Global Sites
    • Special Cases
      • Regulatory Mandated

High-Level Zone Design

The following graphic presents a conceptual high-level zone design that provides a foundation for a series of multi-layered zones based upon the device or systems Application Security Profile criteria. The criteria will be applied to this security model to develop the Application Security Design (Placement, Policy, Controls) based upon the Zone Architecture Rules as well as Application Architecture Taxonomy (discussed further in the next blog).

Conceptual Zone Design

Zone Deployment and Migration

The critical success factor is in the Zone Deployment and Migration to move servers and systems to this model. This section provides an overview of the considerations and we will go into more detail in a future blog on this topic.

Zones – User Experience, Perception and Buy-in is key –

Zone Deployment

  • Baseline Prototype
    • Start Open/Simple
    • Gain Quick Key Wins
  • Implement / Migrate
    • Analyze Application Use Cases
      • Group by Service / Dependency
    • Migrate to Zone Structure
  • Monitor
    • Review Logs and Connections
    • Establish Progressive Policy Controls
  • Iterative Improvement
    • Validate the Model with Feedback Loop
    • Reverse Engineer Policy/Standards
    • Structure as needed
    • Iteratively Evolve over time

Zone Lifecycle Management – Smart Growth

Like Firewall Rules, Network Security Zones are organic and can easily become complex over time as new services and servers are deployed. It should be noted that the original Zone Architecture and Design was based upon the security model and business requirements at one point in time.

The concept of Adaptive Zone Defense talks to the critical need to continually review the Zone Design and to validate it against the needs of the business, new services, application and system deployments, new relationships, and so on.

Based upon assessments of 100’s of organizations the typical challenge with legacy DMZ approaches is that they start out well designed and organized. Over time the security model does not quite fit a new business need or deployment and/or the security model is not well understood and so either exceptions are made or human errors are made. The result is a DMZ implementation that is not only complex and harder to manage and maintain but also at risk of human error with configuration and implementation mistakes creating backdoors or side doors.

Keeper of the Zones – Security Vision

IT needs to be continually educated about the Zone Design, the business rules and the security model so that it is clearly understood. In addition, the Application Architecture Taxonomy (see below) needs to be integrated early in the cycle of service and server deployment processes and refreshes so that deployments are included in a risk assessment, are designed appropriately and thus, are placed within the Zone Design based upon both their connectivity and security needs to protect them and not break the model.

Zones need an owner, the keeper of the Zones and need to be managed to enable Smart Growth –

Smart Zone Growth

  • Create Zones
    • Based on Risk Assessment and Mitigation
    • Application Profile – Placement
  • Divide Zones
    • Risk Profile Changes
    • Special Cases, Security Exceptions
  • SubZones
    • Zones within a Zone
  • Review Zones
    • 6 Monthly Zone Organization Review
  • Condense Zones
    • Monitor and Consolidate
  • Retire Zones
    • Remove Zones from prior temporary Security Exceptions

Conclusion

Security zone isolation 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 Adaptive Zone Defense – Part 2 we develop a key profile that is currently termed an Application Architecture Taxonomy that considers Applications and their relationships as well as Users and their relationships. profile organizations and are currently in operation.

In future parts we will tie this all together in terms of how to profile applications based upon data classification and risk assessment as well as communications needs to determine the appropriate zone placement, protection controls and, access control policy.  We will also discuss the deployment and migration considerations which are extremely critical to success. Lessons learned.

Thanks for your Interest!

Nige the Security Guy.