Systems and methods for applying policies in a data center environment

Abstract

This document describes a method comprising: one or more applications running on at least one processor for segmenting an application in a networked environment, the one or more applications being communicatively coupled to the application, the one or more applications providing: receiving network flow information of the application from at least one source; using the network flow information to discover a plurality of policies in a first policy enforcement environment; receiving the discovered plurality of policies in a first format according to a first policy naming convention; mapping the discovered plurality of policies from the first format to a second format following a second policy naming convention; enforcing at least a portion of the discovered plurality of policies in the first policy enforcement environment using the first format; and enforcing at least a portion of the discovered plurality of policies in the second policy enforcement environment using the second format.

Description

Related applications

[0001] This application claims the benefit of U.S. Application No. 63 / 534,072, filed August 22, 2024. Technical Field

[0002] This disclosure relates to systems for implementing security policies to ensure secure access to applications operating within an enterprise data center. More specifically, this disclosure relates to the discovery, management, and enforcement of policies for ensuring the security of data center applications.

[0003] By incorporating via reference Each patent, patent application and / or publication mentioned in this specification is incorporated herein by reference in its entirety, to the same extent that each individual patent, patent application and / or publication is specifically and individually indicated as incorporated by reference. Background Technology

[0004] In short, a data center is the physical infrastructure an organization uses to store its critical applications and data. Data center design is based on networks that enable the delivery of computing and storage resources for shared applications and data. Key components of a data center design include routers, switches, firewalls, storage systems, servers, and application delivery controllers.

[0005] Data center security tracks workloads across physical data centers and multi-cloud environments to protect applications, infrastructure, data, and users. This approach works from traditional data centers based on physical servers to more modern data centers based on virtualized servers. It also applies to data centers in the public cloud.

[0006] Data centers contain a significant portion of a company's information assets and intellectual property. These are the primary targets of all targeted attacks, and therefore require a high level of security. Data centers contain complex networks of servers and applications. Creating and managing appropriate security rules to control access between data center resources can be exceptionally difficult. Attached Figure Description

[0007] Figure 1 The zero-trust segmentation hierarchy is shown in the embodiment.

[0008] Figure 2 The workflow and environment for policy discovery, management, and solution implementation are illustrated in the embodiments.

[0009] Figure 3 Example results of application dependency mapping are shown in the embodiment.

[0010] Figure 4 The application hierarchy in the embodiment is shown.

[0011] Figure 5 The policy lifecycle is shown in the example.

[0012] Figure 6 The scope tree in the embodiment is shown.

[0013] Figure 7 The relationship between the EPG and the contract is illustrated in the example.

[0014] Figure 8 An example contract is shown in the embodiment.

[0015] Figure 9 An example contract is shown in the embodiment.

[0016] Figure 10 An example contract is shown in the embodiment.

[0017] Figures 11A to 11C The strategy for mapping from CSW to ACI environment is shown in the example.

[0018] Figures 12A to 12D An ACI contract is shown in an example. Detailed Implementation

[0019] The company's data centers contain hundreds to thousands of physical and virtual servers, which are segmented by application type, data classification regions, and other methods. Therefore, the company implements a security architecture to control access to resources in both the (north / south) and (east / west) regions.

[0020] Enterprise policy enforcement tools can include Cisco Secure Workloads (CSW) solutions or Cisco Application-Centric Infrastructure (ACI). Business Technology Architects (BTAs) implement security architectures that integrate both solutions. Companies can engage BTAs to use the BTA Policy Automation Engine (PAE) within the Cisco Secure Workloads (CSW), Cisco Application-Centric Infrastructure (ACI), and BTA Architecture Explorer (BTA AE) to create and document the architecture used for micro-segmentation of their data center applications. The PAE integrates CSW and ACI to automatically enforce policies from CSW to ACI. Running within the BTA AE, the BTA PAE assists network, systems, application, and security engineers, as well as administrators, in understanding the micro-segmentation architecture and how to implement it.

[0021] Zero Trust requires a hierarchical structure within the data center, including internet, users, applications, zones, and micro-segments. This hierarchy provides visibility into dependencies within and between each layer by using network objects—such as addresses or VLANs—in the organization's business language. Policies using business language are easier to review and approve. Once approved and implemented, the policy restricts traffic to only what is necessary for application operation and management. All other traffic is dropped, preventing east / west propagation within the data center. This architecture works in conjunction with perimeter firewalls that drop unwanted south / north traffic to limit or prevent intrusion from outside the data center.

[0022] Figure 1 The zero-trust segmentation hierarchy in this embodiment is illustrated. Layer 110 includes the Internet layer. The Internet layer, or Layer 3 in the OSI model, is responsible for routing packets across different networks. It handles IP addresses, routing protocols, and logical addressing. Packets are inspected and authorized at the Internet layer based on established security policies, regardless of their source or destination. This means that even traffic crossing traditional network boundaries or originating from external sources is subject to the strictest security measures before being allowed access to critical resources.

[0023] The zero-trust segment at user tier 120 aims to ensure that every user, regardless of their location or device, must continuously verify and prove their identity before gaining access to specific resources, applications, or data. At user tier 120, the architecture prevents VIP bypass and requires a jump host for Secure Shell (SSH) and Remote Desktop Protocol (RDP). The jump host acts as a single entry point between different segments of the network. Privileged resources on the network are typically hidden behind the jump host, making them inaccessible to users directly from their workstations. Instead, users must connect to the jump host and then to the privileged resource.

[0024] Zero-trust microsegmentation at the application layer 130 leverages dependencies between different applications (via application dependency mapping) to implement effective microsegmentation at the application layer. Application dependency mapping provides insight into how applications interact and communicate with each other, enabling security teams to create accurate and secure segmentation policies.

[0025] Zero-trust micro-segmentation at region level 140 involves dividing the network into isolated segments or regions, each dedicated to a specific business function, application, or user group. This grouping can include production and non-production, or PCI and non-PCI. Each region is protected by its own security policy, and communication between regions is restricted based on established rules.

[0026] Zero-trust microsegments at region level 150 involve restricting traffic within an application or cluster.

[0027] The zero-trust microsegment at process level 160 includes server processes on restricted ports.

[0028] The CSW ACI micro-segmentation architecture enforces segmentation policies within Linux, Windows, and AIX servers and ACI contracts. Policies are discovered using Application Dependency Maps (ADMs) derived from flows ingested from the CSW agent on the server into the CSW platform or from the Encapsulated Remote Switch Port Analyzer (ERSPAN) on the ACI switch. The policy lifecycle identifies all steps necessary for policy discovery, approval, analysis, and enforcement. Depending on the application being segmented, the Policy Enforcement Point (PEP) will be in the host firewall, the ACI contract, or both. The BTA Policy Automation Engine (PAE) in the Architecture Explorer (AE) automates policy enforcement within ACI, ensuring consistency between host firewalls and ACI policies.

[0029] Figure 2 The BTA Architecture Explorer 250 (running BTA PAE) is shown residing between the CSW environment 200 and the application-centric infrastructure environment 201.

[0030] Cisco security workloads The CSW environment comprises the CSW Platform 202 and the Agent 204. Cisco Security Workloads (CSW) support micro-segmentation by enforcing policy lifecycles against host-based firewalls in Windows, Linux, and AIX operating systems. CSW is an agent-based platform that requires agents deployed to servers (workloads) to report streaming data and apply policies to localhost-based firewalls.

[0031] Agents are software components deployed on servers and endpoints within the data center. These agents collect streaming data and send it to the Cisco Security Workload Platform, which can then use this streaming data to perform Application Dependency Mapping (ADM). As its name suggests, Application Dependency Mapping discovers and visualizes dependencies between data center workloads.

[0032] A workload can be a simple or complex application running on one or more servers, with thousands of client systems connecting and interacting with the application server across a vast network. Workloads may depend on other shared assets or a larger platform, but there should be clear boundaries regarding the assets they rely on and the processes that depend on them. Workloads can be visualized by monitoring network traffic between data center assets.

[0033] The agent provides network flow information. CSW can then analyze this information to discover dependencies. This network flow information includes packet metadata, process details, packages, events, etc.

[0034] In one embodiment, ADM leverages a knowledge organization structure using scopes and tags. Specifically, tags can be applied to workloads. Scopes then use tags to group workloads. Workspaces encompass the grouping of scopes across various levels within a hierarchy. A hierarchy can include multiple scopes. And each scope can be a parent scope of multiple subscopes that further segment workloads at lower levels. Thus, CSW provides horizontal and vertical segmentation of workloads within the hierarchy. Application dependency mapping is applied to workspaces to provide the interdependencies between workloads within the workspace and to recommend strategies based on data flow and the organization of scopes. Furthermore, administrators can use the results of ADM to create strategies.

[0035] Figure 3 The result 300 of the ADM process is shown. Figure 3 The diagram illustrates the dependencies between workloads and their corresponding server groups 302 and 304, external dependencies 308, and the interaction between the user and workload 306.

[0036] like Figure 2 As shown, the agent can run on Linux, Windows, or AIX bare metal (212GB) or virtual machine (214GB). The virtual machine can be local or in the cloud.

[0037] When the CSW platform executes a policy on a host, it sends the policy to the CSW agent. The agent receives the optimized policy for the corresponding workload. The agent then programs the policy into the local host firewall. For example, in the Linux operating system, iptables is a user-space utility that allows system administrators to configure IP packet filtering rules for the Linux kernel firewall. ipset is an extension of iptables that allows you to create firewall rules that match an entire set of addresses at once. Microsoft and AIX implement similar host-based firewalls.

[0038] Some data center servers may not permit agents. A physical or virtual device, or any application in which a CSW agent cannot be deployed, is referred to as device 210. Servers where a CSW agent is not deployed may be due to licensing, operating system, or other constraints. If an agent cannot be deployed, flow ingestion from network ingestion can be used for discovery policies but not enforced on the host. In one embodiment, ERSPAN ingestion provides flow data from an ACI switch. Encapsulated Remote Switch Port Analyzer (ERSPAN) allows traffic monitoring within a network area. It uses Layer 3 routing to route SPAN traffic to network traffic analyzers in different network areas. Alternative embodiments may use NetFlow for similar purposes. ACI switches are equipped with ERSPAN and / or NEFLOW functionality. In this architecture, ACI contracts are then used for agentless enforcement.

[0039] Inventory management is crucial for identifying servers within an application and their roles within the application. CSWs can categorize inventory using tags or manually through integration with Infoblox IP AM 212, ServiceNow CMDB 210, vCenter tags 214, or other sources where inventory is managed. The Inventory Service is used to configure scopes and filters within the CSW. Additionally, workspaces assigned to scopes can have clusters representing the layering of the application. Clusters can be qualified using the Inventory Service.

[0040] The CSW EDGE virtual appliance 218 forwards events from the CSW to other services, such as system logs or emails.

[0041] Application-centric infrastructure Figure 2 The ACI environment 201 is shown. The ACI architecture includes Cisco Nexus switches 230 forming the foundation of the network. The switches are organized into a leaf-spine architecture. The Application Policy Infrastructure Controller 232 (APIC) acts as the central point for control and management of the ACI architecture. The Cisco APIC controls the ACI architecture for network virtualization and policy enforcement. This architecture focuses on policy enforcement using ACI contracts.

[0042] The Nexus Dashboard Orchestrator (NDO) manages one or more ACI fabrics by interfacing with the APIC used for fabrication. NDO facilitates intersight configuration of all network virtualizations across multiple sites. NDO can also apply ACI contracts to the ACI fabrics it manages. This architecture focuses on ACI contracts configured via the API using the PAE-to-NDO interface. In one embodiment, PAE derives ACI filters, filter entries, contracts, and bodies from policies approved by the CSW and then configures them in the ACI. Filters have one or more filter entries that define the protocols and ports for permitted traffic. Contracts have one or more bodies that contain the filters. Once the contracts are configured, PAE assigns consumer EPGs and provider EPGs to use the contracts, which will permit the desired traffic between the consumer and provider.

[0043] Cisco ACI solutions' basic security architecture follows an allow list model, which defines which traffic should be permitted. Contracts are policy structures used to restrict communication between EPGs. Without contracts between EPGs, unicast communication between them is not possible unless the VRF is configured in "unenforced" mode or these EPGs are in a preferred group. Figure 7 This illustrates the relationship between EPG and the contract.

[0044] EPGs are provided or consumed under contracts. For example, in Figure 7 In the example, the App EPG provides the contract consumed by the Web EPG and consumes the contract provided by the DB EPG. It defines which side is the provider of a given contract and which side is the consumer of that given contract, allowing the application ACL (Access Control List) filtering direction that establishes the contract; for example, if the Web EPG is a consumer of a contract provided by the App EPG, you might want to limit the filter to allow HTTP port 80 as the destination in the consumer-to-provider direction and as the source in the provider-to-consumer direction. In the case of a traditional network, these two filters for the two directions are separate ACLs. In the case of an ACI architecture, when a contract with an HTTP filter (source port "any" and destination port "80") is configured between the Web EPG and the App EPG, both filters (one for each direction) are deployed by default in Cisco ACI, as shown below. Figure 8 As shown in the figure.

[0045] If you alternatively limit the Web EPG to the provider of the contract and the App EPG to the consumer of that contract, the same filter will be applied in the opposite direction; that is, you will allow HTTP port 80 as the source in the consumer-to-provider direction and as the destination in the provider-to-consumer direction (see [link]). Figure 9 ).

[0046] In the most common designs, you don't need to define more than one contract between any given EPG pair. If you need to add more filtering rules to the same EPG pair, this can be achieved by adding more entities to the same contract.

[0047] Body and filter The body is a structure contained within the contract and references filters. A contract contains one or more bodies, and each body contains one or more filters. Each filter contains one or more filter entries. Filter entries are rules that specify fields such as TCP port and protocol type. Figure 10 The logic of the subject and filter is shown.

[0048] Policies reside at the switch level. Therefore, policies can be enforced before data reaches the host-based firewall.

[0049] BTA Architecture Explorer BTA Architecture Explorer (AE) 250 is a multi-tenant, multi-site application running in a virtual appliance that facilitates policy automation from CSWs to ACLs. AE requires API access to CSW(s), NDO(s), APIC(s), and network services: DNS, NTP, SMTP, and MFA. Figure 2 (240). AE requires a certificate to access the Web GUL via HTTPS. Insecure HTTP access is not supported. SSH access is required for management. All user logins are protected by Multi-Factor Authentication (MFA).

[0050] BTA AE Strategy Automation Engine (PAE) PAE reads the CSW policy and ACI configuration, then automatically configures filters, filter entries, contracts, and subjects, and applies the contracts to the EPG in ACI to enforce a policy consistent with the CSW policy of a given application.

[0051] Application profiles and EPGs must be pre-configured for ACI according to strict naming conventions. CSW scopes must match the expected naming conventions in ACI because ACI objects cannot be renamed. Scope naming follows this structure, which PAE maps to the ACI configuration. The application's CSW scope name: <datacenter name>:<structure name>:<tenant name>:<application profile name> maps to the ACI object <datacenter name>-<structure name>-<tenant name>-<application profile name>. For example, DC1:FABRIC1:TENANT1:APP1-AP maps to del-fabric 1-tenant1-vrfl-appl-ap. The cluster within the CSW workspace used for the scope identifies one or more EPGs within APP1-AP used for the application contract. The cluster and EPG names are the same in both CSW and ACI: dcl-frabricl-tenantl. Typically, there is a one-to-one relationship from Tenant to VRF. If so, vrfl is not needed in the ACI name in the example above. In rare cases where each tenant has multiple VRFs, a unique VRF name is then required in the ACI name, as in the example above. It should be noted that the CSW policy name can be automatically exported after the CSW workspace is configured for leaf scopes.

[0052] Both the ACI name and the CSW name must fully specify the naming object hierarchy. CSW scopes are separated by a colon (:), which maps to a hyphen (-) in ACI to indicate the separation of ACI objects. Names must not contain spaces, therefore names with multiple words should use spaces. Instead of spaces between words.

[0053] The implemented ACI policy will be broader than the CSW policy because it will allow all traffic within the EPG. If traffic between servers within the same application must be segmented, a host implementation using a CSW proxy must be used.

[0054] BTA AE provides reporting services. BTA AE reports generate multiple reports necessary for automating and validating policy implementation. These reports document the policy configuration before and after implementation.

[0055] The ACI configuration report contains all existing configurations in ACI, including application profiles, EPGs, contracts, bodies, filters, and filter entries.

[0056] The CSW policy review report lists all the policies identified and configured in the CSW. The policy review report helps to review policies against the policy approval steps throughout the policy lifecycle.

[0057] The CSW ACI policy validation report identifies all required ACI configurations to enforce a consistent policy within ACI. Validation will fail if required objects, such as application configuration files or EPGs, are misnamed or missing. Validation failure indicates that ACI configurations need to be updated and / or that CSW configurations are required before proceeding. A post-implementation CSW ACI policy validation report should indicate that no additional configuration is needed, thus confirming that all required objects have been configured and applied in ACI.

[0058] The CSW implementation checklist report confirms that all necessary CSW configurations are in place before implementing the strategies in the CSW.

[0059] The CSW escape report lists the traffic that will be dropped once the policy is implemented. This is necessary to finally confirm that the required traffic will not be dropped after implementation.

[0060] The CSW Denial Report lists the traffic that was denied after implementation and can be used to troubleshoot the application or identify new traffic that may need to be allowed after implementation.

[0061] Application ranking Applications must be prioritized for segmentation, not only ordering segmentation activities but also taking into account CSW licensing and ACI TCAM resource constraints. Multiple environments may exist within an application: production, development, testing, QA, pre-release, etc. Segmentation should begin with dev for each application's environment to prevent issues from propagating from dev through the environment to production and to provide full visibility into cross-regional issues during policy approval.

[0062] Ternary Content-Addressable Memory (TCAM) (also known as Overflow TCAM (OTCAM)) is a dedicated hardware resource designed for fast table lookups. Each switch includes a TCAM resource in the form of a microprocessor that manages the TCAM for each port or port group on the switch. The TCAM utilizes 0, 1, and 1 as its base values. The wildcard matching capability performs batch searches of content. For each packet, the switch identifies the direction of ingress or egress, the consumption of the EPG, the provision of the EPG, the contract associated with the combination of consumer and provider EPGs, and the permitted protocols and ports within the contract. If the packet is not permitted, the switch discards it.

[0063] TCAM is a valuable hardware resource for ACI Nexus switches. Therefore, the use of these hardware resources is carefully planned. In environments implementing complex policy relationships (especially if policies are concentrated on several switches simultaneously), ACI policy enforcement can easily reach policy CAM limits and exhaust hardware resources. If resources are exhausted, no additional policies / contracts are programmed into the hardware. Consequently, unexpected system behavior will occur.

[0064] In one embodiment, Figure 4 This diagram illustrates the data center applications listed in a hierarchical structure according to their importance. Multiple applications reside within each tier. The hierarchy includes: —Critical Applications 410, which are core assets of the enterprise and / or have stringent compliance requirements.

[0065] —Shared service applications 420. These shared service applications are widely used by most or all data center applications and users. Some typical shared service applications are: Active Directory, Jumphosts, Key Server, DNS, NTP, Mail… (Jumphosts is used for management and testing) —Publicly-oriented application 430 has a public internet address assigned to one or more servers.

[0066] —Cannot deploy CSW agent on devices or other servers 440.

[0067] —A shared database used by many applications or users 450.

[0068] —Web Application 460.

[0069] —Virtual desktops with daily or other periodic lifecycles 470.

[0070] —Other applications 480.

[0071] Application Key Metrics The goal of app ranking is to create an ordered list of App+Environs (AppEnv) that determines which apps will be segmented first. Information discovered during the app segmentation workflow can lead to a re-ranking of apps. Some of the things discovered that can affect ranking are: unlisted apps, App Server Count (APC), app breadth, and percentage of cross-environment or TCAM utilization.

[0072] Applications are segmented sequentially until resources are exhausted. The primary resources are software agent licenses and / or TCAMs in the exchange infrastructure, but other resources can also be utilized. Once resource limits are reached, more critical applications are segmented. Resources can be added or released, at which point re-ranking and further segmentation begin.

[0073]

[0074]

[0075]

[0076]

[0077] The applications are ranked as follows... 1. List all known applications and environments. This is the AppEnvs list.

[0078] Please remember that you may know very little or nothing. The segmentation process can begin with a single server, and the owner builds the AppEnvs list through discovery and business negotiation.

[0079] 2. Assign metrics to each AppEnv.

[0080] Assignments do not need to be precise. Discovery will provide more information that may require changes to the metrics.

[0081] 3. Group AppEnvs according to ACM.

[0082] All AppEnvs with ACM = 1 are in GroupACM1. The same applies to other ACM values.

[0083] 4. Sort the AppEnvs within each group according to this priority list: a. Environment = Production b. If the environments are the same, then ASC is the lowest. c. If ASC is the same, then AAC is the lowest. d. If AAC is the same, then ABM is the lowest. Do the same for other environments after production.

[0084] At this point, the applications are ranked in an ordered list, thus indicating which applications should be segmented first.

[0085] In one embodiment, the environment priority list from highest to lowest includes production, quality assurance (QA), testing, and development. In another embodiment, there is a further prioritization as follows: in production: mission-critical, customer-facing, internal; and within mission-critical: regulatory compliance, PCI security certification, audit readiness, industry certification.

[0086] Re-ranking occurs when new applications are added or discovered (applications not previously listed) or when metrics change. Metrics can change over time due to server discovery, policy discovery, new business requirements or challenges, funding, and other events. Re-ranking may require some applications not yet segmented to free up resources for segmenting higher-ranking applications in the new rankings.

[0087] The application type (AppType) is either a server or a device. For various reasons, such as (1) being delivered as an OVA, (2) being a physical device that cannot access an operating system (OS), or (3) having an OS that the HEA does not support, an application can be a device.

[0088] As indicated above, the policy lifecycle is implemented by the Architecture Explorer (AE). The policy lifecycle identifies all steps necessary for policy discovery, approval, analysis, and enforcement. Depending on the segmented application, the Policy Enforcement Point (PEP) will be in the host firewall, ACI contract, or both. The BTA Policy Automation Engine (PAE) in the Architecture Explorer (AE) automates policy enforcement in ACI to ensure consistency between host firewall and ACI policies.

[0089] Inputs to the policy lifecycle Application list Create a list of applications that need to be segmented. For each application in the list... 1. List the IP addresses assigned to the applications.

[0090] 2. Identify the environment of the IP address: production or non-production.

[0091] a. Optionally, for non-production environments, further clarify the environment: development, testing, QA, pre-release, etc. Each application+ environment must list at least one IP address.

[0092] The process can begin with a single server used for an application and, over time, create an overall list by discovering other servers and consulting with business owners to identify the applications used on those servers.

[0093] Policy lifecycle output An application segmentation strategy is implemented at one or more policy implementation points, and if there are multiple implementation points, it is implemented consistently.

[0094] The report shows the traffic that was rejected by the implemented strategy.

[0095] Steps in the strategy lifecycle ( Figure 5 ) Select the application + environment for segmentation ( Figure 5 ,502) enter A list of applications, their environments, and the IP addresses of those environments.

[0096] action The list is ranked based on the application category list.

[0097] Select the highest-ranked applications for segmentation.

[0098] Multiple applications can follow the process simultaneously without needing to serialize them.

[0099] Output The name of the application to be segmented.

[0100] Start stream collection ( Figure 5 ,504) Enable flow collection for any network traffic that includes one of the IP addresses in the application.

[0101] Deploy a CSW agent to report the flow from the server to the CSW platform.

[0102] Deploy CSW ingestion devices to report flow from infrastructure to the CSW platform.

[0103] Configure the application in the CSW platform ( Figure 5 ,506) CSW scopes are configured in a hierarchical manner to reflect data centers, ACI architecture, ACI tenants, environments, applications, and ACI EPGs.

[0104] Each node in the scope tree contains a set of discovered IP addresses. The root scope contains all discovered addresses. Child scopes contain fewer addresses than the parent scope, up to a leaf scope that has no child scopes.

[0105] Figure 6 An example scope tree 600 is shown in one embodiment. Figure 6 As shown, child node (internal) 604 is characterized by a subset of the IP addresses of the root node 602. Similarly, Figure 6 This displays the set of child nodes corresponding to the IP addresses of data centers 606, 608, and 610. ACI structures 612, 614, and 616 cascade from data center 608; tenants 620, 622, and 624 cascade from application 614; applications 626, 628, and 630 cascade from tenant 622; and application environments 632, 634, and 636 cascade from application 628 at the leaf scope level.

[0106] The leaf scope contains the server for a given application+ environment.

[0107] The CSW workspace is configured for leaf scopes.

[0108] Within this workspace, the CSW cluster is configured for each EPG in the application. Typically, EPGs reflect the hierarchy of application, web, app, and database (see [link to documentation]). Figure 6 (638), but this convention does not need to be followed. A single EPG can represent all servers in AppEnv.

[0109] The CSW cluster name must match ACI EPG.

[0110] Once leaf scopes, work areas, and work area clusters are configured, policies that reflect traffic between application servers (within an application) and traffic to other applications (between applications) can be discovered.

[0111] If an EPG reflects the hierarchy of an application, then the EPG can be used as a policy provider or consumer for other applications to segment inter-application flows. The same EPG can be a provider or consumer for other EPGs within the same application to segment intra-application flows. If traffic exists within an EPG, policies showing the same EPG as both the provider and consumer will be found. The CSW will enforce intra-epg segmentation, but PAE typically ignores intra-epg policies when enforced in ACI. Alternatively, PAE can enforce intra-epg policies for some applications, such as those on devices where the CSW would not enforce policies. In cases where a single EPG contains all servers within an application, there is no hierarchy within the application. Segmentation is only inter-application, or optionally intra-epg, not inter-EPG.

[0112] Discover application policies ( Figure 5 ,508) Segmentation strategies are generated based on flows associated with IP addresses in the application.

[0113] All flows within a predetermined period are considered, including daily, weekly, and monthly seasonal fluctuations. In the illustrated embodiment, the predetermined period is a 5-week duration used by the segmented application operation.

[0114] Perform CSW application dependency mapping on the application workspace for a predetermined duration. Preferably, the duration is at least 5 weeks.

[0115] During policy discovery, functional, backup, failover, mobility, or other tests should be performed to ensure that the policy will allow the conditions required for testing.

[0116] Review, configure, and approve application policies ( Figure 5 ,510) For each policy, determine whether traffic is needed. If so, approve the policy; otherwise, delete it.

[0117] The approved policy should allow all traffic to the application to run, including functional traffic, management traffic, and test traffic.

[0118] All policies are whitelist policies, meaning that only allow policies, and the last policy defaults to discard. There are no explicit negation policies.

[0119] BTA AE validates CSW policies using ACI configuration by reading configurations from CSW and ACI, matching scope names in CSW with tenant, application profile, and EPG names in ACI. This is essentially a matching exercise. Names are read from CSW and ACI. CSW names are modified, with colons replaced by hyphens and spaces replaced by quotation marks. The system will check if the policy matches an existing ACI name. If all policies in the workspace have matching information in the ACI, the policy is valid. If some do not match, the CSW policy can be deleted if the traffic is not needed, or additional configuration in the ACI or CSW may be required.

[0120] Policy approval is complete once all policies in the workspace are approved and validated using ACI.

[0121] Strategy approval may take days, weeks, or months, depending on the time span required to capture seasonal traffic, which may be a weekly, monthly, quarterly, or yearly seasonal fluctuation.

[0122] Analysis strategy ( Figure 5 ,512) Simulate the approved policy against current or historical net inflow data to identify what will be dropped (CSW escape). Review the escapes to determine if they should be permitted. If permitted, return to the configuration from the previous step to update the policy configuration and validate with ACI.

[0123] The strategy analysis should occur within a predetermined period, depending on the urgency and criticality of segmenting the application. In one illustrative embodiment, the predetermined analysis period is selected within the range of 1 to 7 days.

[0124] Implementation strategy ( Figure 5 ,514) After the strategy analysis is completed, preparations are made to implement the strategy. Implementation is carried out within the scheduled implementation window of CSW, ACI, and other implementation points. These can all be completed within the same implementation window or scheduled for different times.

[0125] The operator enables execution using the CSW GUI during the window, or the BTA AE is configured to execute using the CSW API during the window. CSW execution is always the first to be completed.

[0126] The BTA AE is triggered to perform actions at ACI, firewalls, or other enforcement points using two methods: polling or event-driven. If polling, the BTA AE periodically polls the CSW API for the application being enforced. The polling interval can range from seconds to minutes. If event-driven, the CSW sends syslog or Kafka events to the BTA AE.

[0127] As the CSW begins enforcing policies, the BTA becomes aware of these policies through polling or events, i.e., through notifications from the CSW. It then triggers a BTA AE to enforce the policies within the ACI. In one embodiment, this implementation is limited to the ACI. However, the BTA AE is not limited to the ACI. In alternative embodiments, other enforcement points, including firewalls or other switching infrastructure, are integrated via their APIs. Similar naming or new name mappings are implemented for these other enforcement points.

[0128] Once the BTA AE detects an application implementing a CSW via polling or events, it validates the CSW policy using the ACI. If validation is successful, the ACI filter and contract are configured to implement the policy within the ACI. BTA configures contracts in the ACI using the NDO API or APICAPI. The mapped ACI name includes all the information needed to configure contracts in the ACI, and the contract configuration process is fully automated.

[0129] The BTA Architecture Explorer enforces consistency by automatically implementing strategies from CSW to ACI.

[0130] The strategy was confirmed to be implemented at all implementation points. Figure 5 ,516) Once the policy is implemented at a given implementation point, the BTA AE reads back the policy and compares it with the implemented policy for verification during the automation process.

[0131] This step is necessary to account for any errors or unforeseen problems in the system. In most cases (if not all), policy readbacks should match the deployed policy, but if there are errors in any component or communication failures between them, the policy may not be configured completely or accurately. This must be detected so that the policy can be rolled back, as the policy must be applied as a whole, not its parts.

[0132] Consider / must consider any differences between the executed strategy and the read strategy. As an example, consider an error in ACI implementation where the API indicates successful implementation, but the strategy is not actually configured. This process occurs at both the CSW and ACI levels.

[0133] Execute = Read - Verification successful Enforce narrower than read - verification warning - some unwanted traffic may be allowed, but all necessary traffic will be allowed.

[0134] Reading is narrower than executing—validation errors—some of the required traffic may be dropped.

[0135] Missing read - validation error - no strategy applied.

[0136] Validation errors will cause the policy to roll back at all execution points.

[0137] Verification warnings may lead to policy rollback depending on the configuration.

[0138] rollback( Figure 5 ,518) Roll back the policy to the previous version and verify that the content implemented after the rollback matches the previous version.

[0139] A rollback error indicates that the rollback does not match the previous version and indicates the differences between the previous version and the current version (after the rollback).

[0140] Application testing ( Figure 5 ,520) Test the application after implementation, but simultaneously during the implementation change window. If the test fails, it confirms that the test was successful during policy discovery. If the test did not complete during policy discovery, consider rolling back.

[0141] If rollback is not an option, add a policy to allow the required traffic and enforce it. The added policy is automatically approved.

[0142] Once the test is passed, the implementation is complete.

[0143] Figures 11A to 11C The policy to be implemented is shown. The workspace (application) used for the leaf scope is APP1-PROD. The workspace DC1-COMMON has policies found in APP1-PROD (and other leaf scope workspaces) that are shared by most (if not all) servers in the data center. Therefore, the combined policy in the review tab will be processed by BTA AE PAE and implemented in ACI. Figures 12A to 12D The implemented contract is shown, and the mapping from CSW to ACI naming convention is demonstrated.

[0144] Figures 11A to 11C The CSW strategy in ACI has one row for each unique combination of consumer, provider, protocol, and port. Rows with the same consumer and provider map to a single contract in ACI; see [link to ACI documentation]. Figures 12A to 12D The contract has multiple filters, one for each port. In some cases where the provider serves many consumers, a contract is created for the provider, and filters are added to the contract for each port.

[0145] In one embodiment, a method includes: one or more applications running on at least one processor for segmenting applications in a networked environment, the one or more applications being communicatively coupled to these applications, the one or more applications providing: receiving network flow information of these applications from at least one source; discovering a plurality of policies using the network flow information in a first policy enforcement environment; receiving the discovered plurality of policies in a first format according to a first policy naming convention; mapping the discovered plurality of policies from the first format to a second format following a second policy naming convention; enforcing at least a portion of the discovered plurality of policies in the first policy enforcement environment using the first format; and enforcing at least a portion of the discovered plurality of policies in a second policy enforcement environment using the second format.

[0146] In this embodiment, the first policy enforcement environment includes a Cisco Security Workload (CSW) environment.

[0147] In this embodiment, the second policy implementation environment includes an application-centric infrastructure (ACI) environment.

[0148] In one embodiment, a CSW agent is deployed to a server hosting at least a portion of the application, wherein the at least one source includes the CSW agent.

[0149] In this embodiment, network flow information includes network activity of the application reported by the corresponding CSW agent.

[0150] In an embodiment, the ACI environment includes network switches, wherein an Encapsulated Remote Switch Port Analyzer (ERSPAN) resides on each network switch and monitors its traffic, wherein the at least one source includes the ERSPAN.

[0151] In this embodiment, the network flow information includes an export from ERSPAN.

[0152] In one embodiment, the discovery strategy includes applying a CSW application dependency mapping (ADM) to the application using network flow information, wherein the ADM discovers and visualizes dependencies between application groups.

[0153] In one embodiment, the CSW agent enforces at least a portion of the discovered policies at the host firewall level.

[0154] In an embodiment, the first format includes the CSW environment naming convention.

[0155] In this embodiment, the second format includes the ACI environment naming convention.

[0156] In an embodiment, the mapping includes converting the discovered policy from a first naming convention to a second naming convention, wherein the second naming convention defines the contract in the ACI environment.

[0157] In one embodiment, the contract includes filters that define the protocols and ports for network traffic permitted between application groups.

[0158] In one embodiment, it was found that prioritizing applications for segmentation was included, with each application corresponding to an environment.

[0159] In an embodiment, prioritization includes assigning application metrics to each application / environment (app / env) combination.

[0160] In this embodiment, the application metrics include Application Criticality (ACM), where ACM indicates on a scale of one to five how critical the app / env is to the enterprise served by the networked application, with a score of one indicating the highest criticality.

[0161] In this embodiment, the application metric includes the application server count (ASC), where the ASC includes the number of servers corresponding to the app / env combination.

[0162] In an embodiment, the application metric includes the Application Address Count (AAC), where AAC includes the number of Internet Protocol addresses assigned to the app / env combination.

[0163] In an embodiment, the application metrics include application breadth (ABM), where ABM indicates the dependencies of other applications on the app / env combination on a scale of one to five, with a score of one indicating the largest dependency.

[0164] In one embodiment, prioritization includes grouping app / env groups by ACM score.

[0165] In one embodiment, prioritization includes selecting the most critical group based on ACM scores.

[0166] In one embodiment, prioritization includes further subgrouping the selected group of applications based on the context.

[0167] In this embodiment, prioritization includes selecting the most critical subgroups.

[0168] In one embodiment, the priority ranking includes ranking applications in the subgroups from lowest to highest ASC scores.

[0169] In one embodiment, prioritization includes further ranking applications in subgroups from lowest to highest AAC scores using a common ASC score.

[0170] In one embodiment, prioritization includes further ranking applications in the subgroups using a common AAC score, from lowest to highest ABM score.

[0171] In one embodiment, priority ranking includes iteratively selecting the next most critical application subgroup and performing further ranking of the applications within that subgroup.

[0172] In one embodiment, prioritization includes iteratively selecting the next most critical group based on ACM scores and performing further ranking of applications within the corresponding subgroups.

[0173] In this embodiment, the process continues in segments until the ternary content-addressable memory resources of the ACI environment switch are exhausted.

[0174] In an embodiment, the method further includes analyzing the identified multiple strategies before implementation in the second strategy implementation environment.

[0175] In one embodiment, the analysis includes applying the discovered multiple policies to historical network flow data and identifying unexpected drops in a second policy enforcement environment.

[0176] Systems and methods for applying policies in a data center environment can be components of a single system, multiple systems, and / or geographically separated systems. Systems and methods for applying policies in a data center environment can also be subcomponents or subsystems of a single system, multiple systems, and / or geographically separated systems. Components of systems and methods for applying policies in a data center environment can be coupled to a host system or one or more other components (not shown) of a system coupled to that host system.

[0177] One or more components of a system and method for applying policies in a data center environment and / or corresponding interfaces, systems, or applications coupled or connected to the system and method for applying policies in a data center environment include processing systems and / or systems operating under and / or associated with processing systems. A processing system includes any collection of processor-based devices or computing devices operating together, or components of a processing system or device, as known in the art. For example, a processing system may include one or more of a portable computer, a portable communication device operating in a communication network, and / or a network server. A portable computer may be any one and / or a combination of devices selected from a plurality of devices including, but not limited to, personal computers, personal digital assistants, portable computing devices, and portable communication devices. A processing system may include components within a larger computer system.

[0178] The processing system of the embodiments includes at least one processor and at least one memory device or subsystem. The processing system may also include or be coupled to at least one database. As is generally used herein, the term "processor" refers to any logical processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. Processors and memory may be monolithically integrated onto a single chip, distributed across multiple chips or components, and / or provided by a combination of algorithms. The methods described herein can be implemented in one or more of one or more software algorithms, programs, firmware, hardware, components, circuits, or any combination thereof.

[0179] Components of any system, including systems and methods for applying policies in a data center environment, may be located together or in separate locations. Communication paths couple these components and include any media used to transfer or transmit files between components. Communication paths include wireless connections, wired connections, and hybrid wireless / wired connections. Communication paths also include coupling or connection to networks, including local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), private networks, inter-office or back-end networks, and the Internet. Furthermore, communication paths include: removable fixed media such as floppy disks, hard disk drives, and CD-ROM disks; as well as flash RAM, universal serial bus (USB) connections, RS-232 connections, telephone lines, buses, and email messaging.

[0180] Systems and methods for applying strategies in data center environments, and aspects of the corresponding systems and methods described herein, can be implemented as functions programmed into any of a variety of circuits, including programmable logic devices (PLDs), such as field-programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices, as well as standard cell-based devices, system-on-a-chip (SoCs), and application-specific integrated circuits (ASICs). Other possibilities for implementing systems and methods for applying strategies in data center environments, and aspects of the corresponding systems and methods, include: microcontrollers with memory (such as electrically erasable programmable read-only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, systems and methods for applying strategies in data center environments, and aspects of the corresponding systems and methods, can be embodied in microprocessors that feature software-based circuit emulation, discrete logic (sequential and combinational), custom devices, fuzzy (neural) logic, quantum devices, and any hybrid of the aforementioned device types. Of course, underlying device technologies can be provided in various component types, such as metal-oxide-semiconductor field-effect transistor (MOSFET) technology such as complementary metal-oxide-semiconductor (CMOS), bipolar technology such as emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), hybrid analog and digital, etc.

[0181] It should be noted that any system, method, and / or other component disclosed herein can be described using computer-aided design tools and expressed (or represented) as data and / or instructions embodied in various computer-readable media, based on its behavior, register transfers, logic components, transistors, layout geometry, and / or other characteristics. Such computer-readable media that can embody this formatted data and / or instructions include, but are not limited to, various forms of non-volatile storage media (e.g., optical, magnetic, or semiconductor storage media) and carrier waves that can be used to transmit such formatted data and / or instructions via wireless, optical, or wired signaling media or any combination thereof. Examples of transmitting such formatted data and / or instructions via carrier waves include, but are not limited to, transmission (upload, download, email, etc.) via the Internet and / or other computer networks via one or more data transmission protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data- and / or instruction-based expressions of the aforementioned components can be processed by a processing entity within the computer system (e.g., one or more processors) in conjunction with the execution of one or more other computer programs.

[0182] Unless the context explicitly requires otherwise, throughout the specification and claims, the terms "comprising," "including," etc., shall be interpreted as inclusive rather than exclusive or exhaustive; that is, meaning "including but not limited to." The use of singular or plural terms also includes both singular and plural forms, respectively. Furthermore, the terms "in this document," "in the following text," "above," "below," and similar terms, when used in this application, refer to the entire application and not any particular part thereof. When the term "or" is used with reference to a list of two or more items, the term covers all of the following interpretations: any one of the items in the list, all the items in the list, and any combination of the items in the list.

[0183] The above description of embodiments of systems and methods for applying policies in a data center environment is not intended to be exhaustive or to limit the systems and methods to the precise forms disclosed. While systems and methods for applying policies in a data center environment, and specific embodiments and examples of corresponding systems and methods, are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the systems and methods, as will be recognized by those skilled in the art. The teachings provided herein regarding systems and methods for applying policies in a data center environment, and corresponding systems and methods, can be applied to other systems and methods, not only those described above.

[0184] The elements and actions of the various embodiments described above can be combined to provide further embodiments. In view of the detailed description above, these and other changes can be made to systems and methods for applying strategies in data center environments and corresponding systems and methods.

Claims

1. A method comprising, One or more applications run on at least one processor for application segmentation in a networked environment, the one or more applications being communicatively coupled to each other, the one or more applications providing, Receive network flow information of the application from at least one source; Multiple policies are discovered using the network flow information in the first policy enforcement environment; Multiple discovered strategies are received in a first format according to the first strategy naming convention; Following the second strategy naming convention, the discovered strategies are mapped from the first format to the second format; At least a portion of the discovered multiple strategies are implemented using the first format in the first strategy implementation environment; as well as At least a portion of the discovered strategies are implemented using the second format in the second strategy implementation environment.

2. The method according to claim 1, wherein, The first policy implementation environment includes the Cisco Security Workload (CSW) environment.

3. The method according to claim 2, wherein, The second strategy is implemented in an environment that includes an application-centric infrastructure (ACI) environment.

4. The method according to claim 3, wherein, The CSW agent is deployed to a server hosting at least a portion of the application, wherein the at least one source includes the CSW agent.

5. The method according to claim 4, wherein, The network flow information includes the network activity of the application reported by the corresponding CSW agent.

6. The method according to claim 5, wherein, The ACI environment includes network switches, wherein an Encapsulated Remote Switch Port Analyzer (ERSPAN) resides on each network switch and monitors its traffic, wherein the at least one source includes the ERSPAN.

7. The method according to claim 6, wherein, The network flow information includes an export from the ERSPAN.

8. The method according to claim 7, wherein, The discovery strategy includes applying a CSW application dependency mapping (ADM) to the application using the network flow information, wherein the ADM discovers and visualizes dependencies between groups of the application.

9. The method according to claim 8, wherein, The CSW agent enforces at least a portion of the policies it discovers at the host firewall level.

10. The method according to claim 9, wherein, The first format includes the CSW environment naming convention.

11. The method according to claim 10, wherein, The second format includes the ACI environment naming convention.

12. The method according to claim 11, wherein, The mapping includes converting the discovered strategy from the first naming convention to the second naming convention, wherein the second naming convention defines the contracts in the ACI environment.

13. The method according to claim 12, wherein, The contract includes filters that restrict the protocols and ports for network traffic permitted between application groups.

14. The method according to claim 1, wherein, The findings include prioritizing applications for segmentation, where each application corresponds to an environment.

15. The method according to claim 14, wherein, The prioritization includes assigning application metrics to each application / environment (app / env) combination.

16. The method according to claim 15, wherein, The application metrics include Application Criticality (ACM), where ACM indicates how critical the app / env is to the enterprise served by the networked application on a scale of one to five, with a score of one indicating the highest criticality.

17. The method according to claim 16, wherein, The application metrics include the Application Server Count (ASC), where ASC includes the number of servers corresponding to the app / env combination.

18. The method according to claim 17, wherein, The application metrics include the Application Address Count (AAC), where AAC includes the number of Internet Protocol addresses assigned to the app / env combination.

19. The method according to claim 18, wherein, The application metrics include Application Breadth (ABM), where ABM indicates the dependencies of other applications on the app / env combination on a scale of one to five, with a score of one indicating the largest dependency.

20. The method according to claim 19, wherein, The priority ranking includes grouping app / env groups by ACM score.

21. The method according to claim 20, wherein, The prioritization includes selecting the most critical groups based on ACM scores.

22. The method according to claim 21, wherein, The priority ranking includes further subgrouping of applications within the selected groups based on the environment.

23. The method according to claim 22, wherein, The priority ranking includes selecting the most critical subgroups.

24. The method according to claim 23, wherein, The priority ranking includes ranking the applications in the subgroups from lowest to highest ASC scores.

25. The method according to claim 24, wherein, The priority ranking includes further ranking the applications in the subgroups using a common ASC score, from lowest to highest AAC score.

26. The method according to claim 25, wherein, The priority ranking includes further ranking the applications in the subgroups using a common AAC score, from lowest to highest ABM score.

27. The method according to claim 26, wherein, The priority ranking involves iteratively selecting the next most critical subgroup of applications and performing further ranking of the applications within that subgroup.

28. The method according to claim 27, wherein, The priority ranking involves iteratively selecting the next most critical group based on ACM scores and performing further ranking of applications within the corresponding subgroups.

29. The method according to claim 28, wherein, The segmentation continues until the ternary content-addressable memory resources of the ACI environment switch are exhausted.

30. The method of claim 29, further comprising implementing a plurality of strategies identified in the prior analysis in the second strategy implementation environment.

31. The method according to claim 30, wherein, The analysis includes applying the discovered policies to historical network flow data and identifying unexpected drops within the second policy implementation environment.

Images