Download Options

Book Title

Command Reference BookMap-1

Chapter Title

This is a command wrapper topic

Cisco Secure Workload (Tetration) Platform 3.5 v1 - Demo Zone
Published: August 25, 2023
Talking points
    About

    About

    About This Demonstration

    This instant demonstration illustrates how the Cisco Secure Workload solution addresses security challenges by providing unprecedented insights, hybrid-cloud workload protection, and comprehensive workload protection across a multicloud infrastrcture.

    Limitations

    • Because this is an instant demo, customization of the environment may not be retained for future connections.

    • Sessions are limited to a maximum of 2 hours.

    • Throughout this guide, there may be slight differences between the screen shots and your environment since the Secure Workload exists in different dCloud datacenters.

    Requirements

    The table below outlines the requirements for this preconfigured demonstration.

    Required Optional

    Laptop

    Cisco.com Login to dCloud

    About This Solution

    The technological changes over the last few years has made it challenging for enterprises to secure the modern workloads and applications.

    Workloads can run anywhere: It is now common for an enterprise to have not only a data center or two (or more), but also many remote locations with server assets, as well as one or more cloud infrastructure partners. The data center perimeter today contains the data center, remote mini-data centers, and cloud infrastructure partners.

    Heterogeneous nature of the workloads: Workload types in an enterprise environment not only include bare-metal servers and virtual machines, but also more dynamic ones such as containers and microservices. These are managed and operated using different technologies.

    Applications are constantly changing: Today’s applications are dynamic, with new versions and changes coming very often, and they can also scale in and scale out depending on business needs. Some applications scale out into a public cloud environment to support increased traffic.

    Opening up of new attack vectors: With the diminishing perimeter as workloads expand to public cloud environments and users increasingly becoming mobile, the attack surface also changes. With more rapid application development occurring in more places, more often, there are more software vulnerabilities. As traffic shifted inside to east/west, where there is little to no segmentation, malicious code can now roam freely inside the trusted intranet.

    Because these trends and changes drive new security initiatives and requirements for applications and workloads across a multicloud environment, Cisco has created Cisco Secure Workload™ expressly to meet these requirements. Cisco Secure Workload enables the security objectives of CXOs and executives, while enabling disparate teams to work together using a single platform that can meet the workload security requirements of app developers, security architects, and SecOps.

    Recent years have seen a relentless pace of change and digital acceleration across industry verticals. Some trends include:

    • Business trends: High-performing application and security integrity are top of mind for CXOs due to their growing online presence.

    • People and process trends: Teams are asked to work together efficiently to support and meet service levels for the business, giving rise to the terms “DevOps,” “DevSecOps”, and “NetDevOps”.

    • Technology trends: As applications become increasingly critical to the business, new requirements for visibility, security, workload protection, and service operations in this complex environment have emerged.

    Cisco Secure Workload represents a paradigm shift that leverages machine learning and big-data analytics to address the modern data center and has the following characteristics: (1) it is multicloud, where boundaries extend beyond on-premises data centers; (2) it has heterogeneous environments with a combination of bare-metal hosts, virtualized workloads, and containers; and (3) it is dynamic to meet the changing application behavior and workload lifecycle. By leveraging algorithmic approaches, Cisco Secure Workload is able to automate the identification of application behavior and map microsegmentation policies, across private data center, cloud, and hybrid deployments at a level of detail required to support security capabilities, and added business value.

    The high-level architecture is illustrated below.

    Cisco Secure Workload is an open platform that is accessible via GUI, REST API, and an event notification framework. Operators may even leverage the compute and storage of the platform to write their own user apps in Python or Scala. The open APIs and event notification bus are leveraged by Secure Workload ecosystem partners for integration with SIEM, CMBD, and other tools.

    In summary, Cisco Secure Workload is purpose built to address industry trends impacting our customers’ businesses. The solution leverages streaming telemetry, behavior analysis, unsupervised machine learning and artificial intelligence, and big data analytics to deliver pervasive visibility, automated intent-based policy, workload protection, performance management, and much more. As a unified platform, Cisco Secure Workload allows various teams to work together efficiently across organizational silos and integrates with an ecosystem of partner solutions to increase value throughout the IT data center environment.

    Use Cases

    Cisco Secure Workload main use cases:

    • Microsegmentation: Cisco Secure Workload enables security teams to implement a secure, zero-trust model for workloads using microsegmentation. It automates the policy generation for microsegmentation using unsupervised machine learning and near real-time application behavior analysis. It normalizes this policy based on the priority and hierarchy before enforcing it. These policy elements are enforced for an application using the operating system firewall capabilities such as ipsets and iptables, in the case of Linux servers, and the Windows advanced firewall, in the case of Microsoft Windows servers. This approach delivers a stateful and consistent segmentation across multicloud data centers at scale. It also allows you to minimize lateral movement in case of security incidents. Additionally, in a virtualized and container environment, this mechanism ensures that segmentation policy moves with the workload, allowing increased application mobility without the need for an infrastructure-specific segmentation policy. As application dependencies and communication patterns evolve, Cisco Secure Workload helps ensure that the policy is updated automatically.

    • Workload anomalous behavior detection: Data center workloads are deployed for a specific activity or a function. Therefore, workload behavior could be baselined and proactively detect anomalous behaviors. To achieve this, Cisco Secure Workload monitors the process and communication activities on the workloads. It can detect various malicious behavior activities like:

      • Privilege escalations

      • Shell-code executions

      • MITRE-identified techniques and tactics

      • Side-channel attacks

      • Unseen commands

      In this way, security operations can quickly identify indicators of compromise and take remediation steps to minimize the impact.

    • Reducing the attack surface: Attack surfaces are introduced in the data center due to vulnerabilities associated with the software packages, OS versions, and due to the stale ports and processes running in the environment. Cisco Secure Workload, in real time, identifies the full inventory of all software packages installed on the workloads and provides the ability to detect common vulnerabilities and exposures associated with these packages. It also provides actionable security insight where administrators can define policies to quarantine or restrict communication of workloads when certain vulnerabilities are detected. Additionally, it also identifies those open ports with process bindings that are not used. This concrete information helps administrators determine if something can be safely shutdown to reduce the exposure.

    There are three layers in the architecture:

    • Telemetry and policy enforcement: Cisco Secure Workload primarily uses software agents to collect telemetry from the workloads as well as to enforce microsegmentation policies. These agents can be deployed across heterogeneous environments, in public or private clouds, across virtual machines, to containers, and bare-metal servers. Additionally, Cisco Secure Workload integrates natively with other systems to get workload context information. These systems include orchestration platforms (VMWare vCenter, Kubernetes, and so on), IP address management systems, DNS servers, CMD systems, and so on.

    • In certain environments where software agents cannot be used, Cisco Secure Workload offers other mechanisms to collect telemetry from workloads such as ERSPAN mechanisms, NetFlow, IPFIX, or telemetry from load balancers, and so on. Microsegmentation policy enforcement in these environments could be done through infrastructure elements such as firewalls.

    • Analytics and security: The telemetry and the system context from tens of thousands of agent sources are sent securely to the Secure Workload big-data platform, which analyzes the data, using unsupervised machine learning and behavior analysis. The relationships among the workloads and behavior baselining of the workloads are derived. The algorithmic approach and machine learning employed by Cisco Secure Workload results in the workload protection use cases of implementing microsegmentation, identifying workload behavior anomalies, and reducing the attack surface.

    About the Application Used in this Lab Environment

    A Microsoft Windows domain has been built for this dCloud experience. There are five application workspaces being monitored by Secure Workload.

    There are Domain Controllers in the Microsoft Windows domain, highlighted in the following image.

    User interaction with the solution dashboard occurs on application development servers with TA agents installed on them, and developer workstations with no agents installed. These are highlighted in the following image.

    The servers and workstations access the Reporting Servers (the Web and App tier of the reporting application) through a software load balancer, highlighted in the following image.

    The Web and App tier report data from the database tier, highlighted in the following image.

    The Sharepoint services also access the domain controllers, separately from the other workspaces.

    Scenarios

    Scenarios

    Cisco Secure Workload GUI Walkthrough and Environment Exploration

    Value Proposition: This scenario describes the Secure Workload GUI, which provides a view into the power and architecture of the platform. It also introduces the concepts of workspaces, scopes, and roles, which are preconfigured.

    Web GUI Overview

    Cisco Secure Workload Analytics provides a scalable, point-and-click web UI to search for information using visual queries. It also generates a variety of charts and tables to help users visualize the statistics. In addition, all the administrative functions and cluster monitoring can be done through the same web UI.

    The vertical menu is an intuitive navigation menu representing the main Secure Workload functions.

    The instant demo automatically logs you into the Web GUI of Secure Workload and displays the Security Dashboard.

    Procedure

     1   

    Scroll over the left panel icons, which expand to show Overview, Organize, Defend, Investigate, and Manage.

    Note: Lab users only have read access to the lab and will not see all the functions.
     2   

    In Select a scope enter mslab to display a list of the function pages.

    Example:

    Each function page presents specific options for accessing and managing different components. The following table below outlines what each page provides.

    Menu Description

    Overview

    		 Provides an at-a-glance view of the security of workloads as the exist in the various scopes throughout the application.

    Organize

    Gain visibility into flows.

    Search for specific hosts and view host details. Enable uploading information to existing inventory with flexible, user-defined attributes.

    View high-level summary of various flow dimensions and to view, add, remove, configure, and edit a variety of charts

    Defend

    Create application workspaces, define security policies or generate white-list policies based on network traffic using application dependency mapping (ADM) tool.

    Analyze flows in accordance with generated security policies and enforce security policies on hosts with agents.
    Investigate

    Monitor network performance in terms of latency, drops and throughput visually on top of the network fabric topology.

    Trace and find flows going through fabric links and switch egress queues.

    Create/use custom analytics on top of the Secure Workload.

    Manage Configure security alerts for the scopes.

    Explore Scopes, Roles, and Workspaces

    Scopes, Roles, and Workspaces are important concepts that are utilized throughout this lab.

    Scopes are used to group data center applications and, along with roles, allow fine-grained control of management. Scopes are used to define access to application flows and filters. They are defined hierarchically as sets of trees with a root corresponding to a VRF. As a result, each scope tree hierarchy represents disjoint data, which does not overlap with another scope tree.

    Roles are used to implement role-based application models so features and data can be restricted to sets of users. Roles contain sets of capabilities that can be assigned to users. Users can have any number of roles, and roles can have any number of users.

    Workspaces are containers for defining, analyzing, and enforcing policies for a particular application. Workspaces are flexible constructs which provide an isolated environment, allowing experimentation with no effect on other workspaces. Application workspaces are meant to be used by multiple users from the same team as shared documents. The level of access to an application workspace can be defined via roles defined on application scopes.

    Procedure

     1   

    In the Security dashboard, click the mslab button, which becomes editable.

    Note: Sub-scopes that have been created for this demonstration, with each scope corresponding to an application group – SharePoint, Developer Workstations, AppDev Servers, Domain Controllers, and Reporting. The TetrationMS scope applies specifically to the Tetration collectors, which allows them to be isolated in each workspace.

    Example:

    When clicking away from the button, be sure mslab is the chosen scope.
     2   

    In the menu, click Organize > Scopes and Inventory to take a closer look at the scope configuration.

    Example:
     3   

    In the Scopes list, click the query for the SharePoint sub-scope to see the details of how the query is constructed.

    Example:

    The resulting screen shows the query that is used to isolate the SharePoint scope, as well as the hostnames, VRFs, IP addresses, and operating systems of the endpoints that are running a SharePoint application. It shows the App server, the distributed cache server, the front-end server, the search server, and the database server that supports the implementation.

     4   

    In the upper-right, click the three vertical dots and then, click More Scope Details to display other available scope information.

    Example:
     5   

    Click Member History to see the membership within the scope, as well as adjacencies.

    Notice the Membership Count remains constant throughout the time interval, while Adjacencies fluctuated slightly. A drop in Membership Count and a large fluctuation of Adjacencies may indicate a problem within the Scope or the particular application.

    Example:
     6   

    Click Summary and then, click the IP address for SPApp01.

    Example:

    Note: 

    Ignore any error message at this point.
     7   

    Point out the various tabs, which show details of the configuration, status, workload protection on the host.

    Later scenarios explore Cloud Workload Protection and Segmentation/Enforcement in depth.

    Example:
     8   

    In the newly opened tab, scroll down and then, click Concrete Policies and show the policies that govern the traffic to and from this endpoint.

    Example:

    Roles

    This example uses the preconfigured lab role, mslab@dcloud.cisco.com.

    Procedure

     1   

    Expand the user drop-down.

     2   

    Click User Preferences to see the settings of the mslab@dcloud.cisco.com account.

    Example:

    The account is assigned to one role, mslab_readonly_role. The preferences are set to the mslab scope.

    Because of these settings, this user has very limited permissions, and cannot modify any settings within the Tetration application. Additionally, some areas of the UI will not be available to this user.

    Segmentation

    Application workspaces are meant to be used by multiple users from the same team as shared documents. You may create many application workspaces for a given scope, however only one of these workspaces can be primary for that scope, for advanced functions such as live policy compliance reporting or enforcement. The level of access to an application workspace can be defined via roles defined on application scopes.

    Procedure

     1   

    In the menu, click Defend > Segmentation.

    Example:
     2   

    Point out Primary Workspaces.

    Example:
     3   

    Point out that all except the Developer Workstations are enabled for enforcement (as indicated by the Primary and Enforced icons).

    This is because there are no agents installed on the Developer Workstations.
     4   

    In the right Workspaces column, scroll down and click Domain Controllers.

    The Domain Controllers dashboard shows the Application Insight derived from Secure Workload big data platform.

    Application Insight Use Cases

    Value Proposition: Application Insight is one of the primary use cases for Secure Workload. This scenario shows how Secure Workload is able to group like workloads in a cluster and create an Application Dependency Map (ADM) for an application in an automated fashion via unsupervised machine learning and behavior analysis. It recommends policy for zero-trust white-list deployment.

    Notes: 

    • Each Application Dependency Mapping requires you to create a workspace. This allows administrators to not only map their application workflows, but to automatically create, modify, test, and enforce policy.

    • Within dCloud the ability to create new workspaces is limited, therefore the screen will differ from production deployments.

    Application Dependency Mapping (ADM) and Policy Derivation

    Secure Workload is a big data, analytical cluster, providing 24x7 application flow monitoring and recording within the Data Center. This provides insight into every packet, every flow, at every speed, over long periods of time. Once all this data is collected, Secure Workload can then provide policy analysis and enforcement based on real-time, or historical, workflows.

    Procedure

     1   

    In the Domain Controllers workspace, click the Manage Policies button.

    Note: 

    Make sure that the latest version is selected.
     2   

    Click on the Policy List View icon to display the policy table view.

    Example:

    Note:  Security policies are the building blocks for many powerful features within Cisco Secure Workload. They provide a simple and intuitive mechanism for application owners and security teams to define the necessary intent to secure assets and applications within data centers. The policy table view provides a simple way to view, edit, and understand policies within a data center. If the mslab account had sufficient permissions, these policies would be editable, and each row would have an edit icon.

    In the table view, the following policies are shown.

    • Absolute and Default policies – Ordered policies to be created with the absolute rank and default rank.

    • Catch All Policy – the policy that is applied when neither an absolute or default policy applies. Notice that the default catch all policy is denied. This is due to Secure Workloads white list approach.

     3   

    Click the Provided Services tab.

    Notes: 

    The provided services page is a collaboration tool that helps application owners build tight security policies across applications with interdependencies. For example, consider an Authentication application that consists of multiple tiers and services. This Authentication application serves as infrastructure for many other applications which require access to a certain set of auth servers on a certain port.

    Also notice that the endpoints are being dynamically added into the grouping with a Query.

    Policy Analysis

    The purpose of this scenario is to explore the Policy Analysis feature in the Secure Workload Applications screen. The Policy Analysis feature analyzes the effectiveness of policies by analyzing all the traffic flow into, out of, and within the application, and to compare published policies to actual traffic.

    It’s important to note that:

    • Policy analysis must be enabled in Secure Workload.

    • Flows into, out of, and within the scope of the application may be affected by policies published in other workspaces.

    • If policy analysis isn’t enabled on this application, the flows are marked with those of the other published applications in the system.

    • All important applications must be covered by Policy Analysis so that their policies don’t get trumped by other applications.

    Procedure

     1   

    Select Defend > Segmentation in the menu and then, select the Reporting workspace.

    Example:
     2   

    Click Manage Policies and then click Policy Analysis tab on the right-hand side to review the policies that relate to the mslab: Reporting application.

    Example:

    Show that this policy analysis relates to Policy 1 (p1).
     3   

    Select the time range for the preceding week.

    If that time period is out of range, select any time period, but keep in mind that the resulting screens are different.

    Example:
     4   

    Select Permitted to view permitted flows.

    Permitted displays the flows that should have been permitted by the policy and in fact were permitted by the policy, indicating that the policy is working correctly.
    Note: 

    Make sure correct policies are selected to view desired flow observations. If you want to view permitted policy, deselect other policies and make sure only permitted is selected and in blue.

    Example:
     5   

    Click a point on the graph to display the list of nodes active then.

     6   

    Click any node to show an example of permitted flow at a given time.

    Example:
     7   

    Click any line in the detailed flow to show the information that is available; specifically pointing out the Flow Details and Quick Policy Analysis.

    Example:

    Escaped flows are flows that were allowed by the network but should have been dropped by the network according to the policy.

     8   

    Deselect Permitted and then, click Escaped.

    Note: If there’s no visible flow, click the date bar, and expand the search to possibly display some.
     9   

    Click a node to show the flow that escaped.

    Note: Explain that the Escaped flows have to be investigated to determine whether they are desired or not. If it’s desired, the network operator has to add those flows to the allow-list. The presence of quite a few Escaped flows several days ago, followed by few to none in the current environment, shows that either an operator added the flows to the allow-list, or the flow was discontinued at the source.
     10   

    Click any of the ESCAPED lines to show the information that is available within the Policy Analysis screen to help in the investigation.

    A network operator is able to add the flow to the allow-list to permit the flow going forward.

    Example:

    Rejected flows are flows that are rejected by the network and should have been rejected, meaning that the policy is working correctly.

     11   

    Deselect Escaped and click Rejected to show that there’s some rejected flow.

    Example:

    Note: Explain that a Microsoft environment is dynamic, and many environments use Dynamic Port Utilization. Sometimes a flow that should be allowed will be rejected by the network. In the previous picture, the flow that was rejected was a web server attempting to reach a network component with the IP address 224.0.0.252 on port 5355. If that should have been allowed, the flow has to be added to the allow-list by the operator.

    Security Dashboards

    Value Proposition: Security Dashboard presents actionable security scores by bringing together multiple signals available in Secure Workload. This scenario helps you understand the current security position and how to improve it. Security Dashboard acts as a springboard to many richer drill-downs within Secure Workload such as Flow search, Inventory Search, ADM, Neighborhood, Forensics, etc.

    Security Score is a number between 0 and 100. It indicates the security position in a category. A score of 100 is the best score, and a score of 0 is the worst. Scores closer to 100 are better.

    The Security Score computation takes into account vulnerabilities in installed software packages, consistency of process hashes, open ports on different interfaces, forensic and data leak events, and compliance or non-compliance to policies.

    There are 6 different score categories. Most security aspects of a workload are taken into account to come up with these categories.

    • Vulnerability Score: Vulnerabilities in the installed packages on a workload are used for scoring.

    • Process Hash Score: Process hash consistency (and anomaly) along with allow-list and deny-list process hashes is used for scoring.

    • Attack Surface Score: Process may have one or more ports open on multiple interfaces to make services available. Unused open ports are used for scoring.

    • Forensics Score: Severity of forensic events on a workload is used for scoring.

    • Network Anomoly Score: Severity of data leak events on a workload is used for scoring.

    • Segmentation Compliance Score: Compliance (permitted) and violations (escaped, misdropped) to ADM policies is used for scoring.

    Overall score is a letter from A+, A, ..., F. A+ is the best. F is the worst. There’s a donut chart with each slice (color coded) representing a score category.

    Security Dashboards

    Procedure

     1   

    From the menu, select Overview.

    Example:
     2   

    Click the Vulnerability Score and then, click SQL02 or any other endpoint under workloads.

    Example:

    You’ll see Vulnerabilities in software packages installed on workloads.
     3   

    Click outside the pop-up and scroll down to Attack Surface Score.

    Example:
     4   

    Click the SQL01 workload or any other endpoint under Workloads.

    Open unused ports (open ports without traffic) contribute to lowering this score.

    Example:

    Forensics

    Secure Workload has visibility both inside the endpoint and the traffic flowing through the network, it gives us some amazing forensic analysis capabilities.

    Secure Workload can send an alarm when it sees a command it has never seen, privilege escalation, side channel attacks, meltdowns, and so forth. We can create specific alerts for certain events or broader alerts under the Forensics Config.

    In the Forensics Analysis dashboard, we can start an analysis for a certain day, time, or range using the bar on the top.

    Note: Read-only users don’t have access to Forensics Config but can see Forensics Analysis.

    Procedure

     1   

    In the menu, select Investigate > Forensics.

    Make sure the root scope mslab is selected on the top right.

    Example:
     2   

    Set Select time range to Max (~ 7 months) then, in the Filters field enter Process Info - Exec Path contains ping and then, click Filter Forensic Events.

    We can then click into it to see that security event in more detail.

    Note: As we move our mouse over the timeline and select events, Secure Workload provides additional information on what happened, what the user did, and paint that picture in more detail.

    Example:
     3   

    Click on the rule to view the forensic event. Hover over the flow to view the security events.
     4   

    Click the Ping at the bottom to see more details and the exact command executed.

    This is useful in the case that you have failed user logon, file access event, privilege escalation—which you want to see that occurred at an earlier time.

    Example:
     5   

    Click the browser back button to return to the dashboard.

    Workload Protection Use Cases

    Value Proposition: The Cisco Secure Workload platform enables holistic workload protection for multi-cloud data centers, providing a secure infrastructure for applications. This scenario explores the various aspects of Workload Protection including Application Microsegmentation, software vulnerability detection, server process anomaly, etc.

    Application Microsegmentation

    Application Microsegmentation leverages the native firewalling capabilities of the workload, including iptables, ipsets, and Windows Advanced Firewall. In this scenario, Microsegmentation is achieved using the Windows firewall on Windows applications. The mslab user does not have permissions to fully utilize the enforcement feature, but this scenario will aid in explaining enforcement to customers.

    Procedure

     1   

    Select Defend > Segmentation in the side menu.

     2   

    In the right side Workspaces menu, select Domain Controllers and then click Manage Polices.

    Example:
     3   

    Click Absolute and DefaultPolicies.

    Example:

    If this were a newly created policy, it would allow all traffic from the mslab scope to request services from the domain controllers over port 3389 (the default port for remote desktop). Note, this example could be extended to leverage intent-based policies. An administrator can easily create an Absolute Policy that DENY Consumer PCI from communicating with Provider non-PCI.
     4   

    Click Enforcement.

    Example:

    Notes: 

    If the mslab account had admin permissions, once this policy was created there would be an Enforce Latest Policies button at the top of the Enforcement screen.

    Clicking the Enforce Latest Policies button would cause Secure Workload to push the new policy out to all the endpoints on all the domain controller firewalls, which allows applications throughout the mslab scope to access the domain controllers. This would take approximately 20 seconds. You would see firewall rules being replaced by Secure Workload rules in Windows Firewall. The following is a screenshot from DC01.

    Next Generation Cloud Workload Protection Platform Capabilities

    Secure Workload provides visibility into vulnerable assets, dynamic proactive security controls and help capture security events for forensics and business impact analysis.

    Secure Workload uses machine learning to solve complex datacenter problems by:

    • Establishing a baseline inventory of all workloads in the Datacenter

    • Collecting all network traffic generated by these endpoints with high granularity

    • Collecting system process-related metadata and correlates the network traffic to the responsible system processes.

    • Keeping the collected information up to date in real time where changes in the environment are picked up and processed.

    • Tagging every piece of workload inventory with an arbitrary set of tags (user-generated tags or tags discovered via orchestration systems that is, AWS, VMware, Kubernetes). The use of tags allows you to create simplified dynamic policies where business intent can be expressed and realized in a rapid and automated manner.

    • Indexing this information and making it readily available for fast search and can be consumed to create Application Dependency maps, deploy zero-trust enforcement and so forth.

    The following security features are included with Secure Workload

    Software Vulnerability Detection

    In addition to the workload context, Secure Workload gathers full software inventory from all monitored workloads in the Data Center.

    Secure Workload cross-checks every software package against the full Common Vulnerabilities and Exposures (CVE) database for vulnerable packages and complies a repository of all affected installed software versions and CVE impact score (Secure Workload uses the CVE database from NIST).

    Changes made to the software inventory triggers Secure Workload to reevaluate applied policies and recheck for vulnerabilities.

    Process, File System and User Activity Tracking

    Secure Workload Agents track server user, interactions with changing memory or page table permissions, cache behavior, file system actions, and, many other system-calls on the workload.

    All this information is curated, activities are associated to the workloads, and written in a time series database.

    Secure Workload enforces a strict SLA on itself and all information is gathered with minimal load on the workload (under 3% of all monitored functions).

    Secure Workload allows you to show the entire process lineage of any managed workload since the workload started. You can play the process tree sequence backwards and forwards in time.

    Process Hash Analytics

    As mentioned earlier Secure Workload tracks running processes, it calculates an SHA256 hash of each observed process.

    This allows you to identify a good process from bad processes by cross-referencing the hash against databases and collecting a verdict.

    Future software releases will integrate Secure Workload with Virus total. A verdict for a particular process hash is programmatically pulled and can be consumed by enforcement policies.

    Baseline and Application Behavior Deviation

    The Secure Workload engineering team has deconstructed malware behavior into basic building blocks and has built intelligence into the system not solely to rely on malware signatures.

    Secure Workload looks for patterns of bad behavior, cross-checks with process history and baseline, and alerts if an incident is worth noting.

    Secure Workload looks for Shellcode execution, privilege escalation, side channel attacks, user login suspicious behavior, and so forth.

    Modern Hybrid Cloud Workload Protection Capabilities

    Secure Workload is a CWPP framework that affords security practitioners rapid discovery within a heterogeneous Data Center fabric consisting of different types of workloads, automated action such as block and quarantine vulnerable systems, proactively alerting and recording the security event for later business impact analysis and understanding the anomalous behavior.

    Enhanced Visibility

    Secure Workload provides a simple way for you to view all software packages installed on a managed host. You can also search for packages within the workload based on different attributes.

    Note: This is a snapshot of a linux VM and the demo uses windows VMs so you’ll not have access to this VM.

    Endpoint host profile lists the vulnerable software package and hovering over the software package name shows the CVE and associated overall Score.

    1. In the left menu, click on Defend and then click on Segmentation.

    2. Select Domain Controllers and click on Manage Policies.

    3. Click on Policies tab. Select any of the below policies with Domain Controllers as provider to view workload and IP address.

    4. Once selected, click on the provider as Domain Controllers. A pane in the right side opens up with additional information. Click on any IP in Workloads. e.g., dc02.



    5. In the newly opened tab of Workload Profile, scroll down and click on Packages.



    6. Click on Vulnerabilities. The following figure shows the workload host profile and vulnerable software packages.



      In the preceding figure, the hyperlink embedded in the CVE takes the user to NIST, where the vulnerability description and impact is documented (as shown below).

    7. Users can create an Inventory Filter against certain match criteria. In the following image, a specific CVE is used as match criteria to create an Inventory Filter. Secure Workload automatically populates the workloads that are running the software package in question. Secure Workload also automatically removes the workloads from this filter once the workload doesn’t meet the match criteria. The figure below shows an inventory filter based on a software package CVE.

      Note: As a read-only user, you can’t create a filter, but you can do an inventory search.

    1. Click on Organize in the left pane, and then select Inventory Filters.



    2. Three filters are already added in the Inventory Filters. Click on any of the filters. For example, CVE-2020-0609.



    In the following figure, a query or match criteria is based on a CVE score that is higher than 7.5. Go back to the previous page, i.e., Inventory Filters page and select CVE filter.

    The following example shows the Binary process hash that Secure Workload tracks and allows the you to cross-check against the Virus totals repository and get a Verdict.

    The following figure shows the workload host profile where the workload process and associated binary hash are documented.

    In the initially opened Workload profile for dc02, click on Long Lived Processes. Or follow steps 1–4 and click on Long Lived Processes

    Users can search and create an Inventory filter where the match criterion is a certain Process Binary Hash and in turn restrict or limit access to workloads running that process.

    Elastic Policy

    You can create security policies against the Package or CVE-based Filters. Secure Workload enforces policies based on the workloads part of the defined match criteria.

    In the following example, Default, which is any endpoint isn’t allowed to communicate with workloads running a vulnerable version of Zookeeper and Open SSL. The figure shows a Tetration Enforcement rule where an inventory filter is used for the rule destination.

    Note: Secure Workload allows flexibility in defining the scope of the rules where a Security engineer can define these rules specific to workloads as part of a certain application or globally where these rules apply to all the workloads in the Data Center.

    The following are some other examples that allow the Security Engineer to restrict traffic to vulnerable assets with in the Datacenter.

    • Block certain TCP ports on hosts running the vulnerable version of Apache Struts.

    • Block TCP port 443 on hosts running Apache (webserver) and a vulnerable version of openssl.

    • Allow traffic to TCP port 443 on hosts running Apache and openssl versions certified by the company, block port 443 everywhere else.

    Application Security Event Allow-Listing and Analysis

    As mentioned earlier Secure Workload actively tracks suspicious events and patterns. Following are the various patterns Tetration looks for in the current release.

    Note: The dCloud pod only provides read-only access to the lab users and the security section isn’t available to users with read-only access.
    Was this page useful ?
    Was this page useful ?
    Email*
    Enter Valid Email Address
    What can we do to improve your experience?
    Help us with more info.*


    *Required field
    Was this page useful ?
    Email*
    Enter Valid Email Address
    What did you like about it?
    *Required field
    The feedback has been submitted successfully!