Analytics Pillar
The Analytics group of Zero Trust Capabilities is an extremely important aspect of the Zero Trust deployment process. The need for analytics, like the ongoing need to continue to look for and gain more insight into anything identity based, is constant and ever evolving, with a need to sort through a massive amount of data sometimes likened to “noise” to find the data that indicates what is happening within the ecosystem.
Analytics comes in many forms and can be anything from the analytics associated with changes made to the network that may attempt to overcome the Zero Trust implementation, including tracking users and their actions on the network throughout their time both on and remotely connected to the network. Analytics about what threats are found within the network that provide more insight into how to detect these threats, and, of course how these threats were blocked will all come into play and will help overcome any reluctance that management, business units, operational staff, or administration staff have when it comes to the implementation.
Application Performance Monitoring (APM)
Application performance monitoring is the process of establishing data points on the performance of an application by observing the behavior from user interactions as well as via synthetic testing. These data points can be used to establish a baseline that can then be used to understand when the application is deviating from that baseline and requires investigation.
The data points collected can include CPU usage, error rates, response times or latency, how many instances of an application are running, request rates, user experience, and more. This data can also be utilized to ensure that an application is meeting a specified level of performance or availability as part of a service-level agreement (SLA). A well-rounded APM should be able to monitor not only down to the application code level but also across the infrastructure supporting the application to ensure a complete picture of the health and performance of an application. This means the APM solution setup process will need to include stakeholder decision-making on how to implement monitoring and tuning of the solution for optimal effect in each unique environment.
APM is a necessity for Zero Trust Architectures because users may access an application from various locations using disparate devices that may or may not be managed by the organization. When a user experiences a problem with an application, it is imperative that the operations and engineering teams can quickly understand whether the issue is related to the application itself or if there are factors beyond the organization’s control. This data is important to ensure that an unhealthy application is restored to a healthy state or, if outside factors are causing the issue, that the users are informed so they can adjust as necessary to improve their experience. As mentioned, APM can also provide a way to track application performance against a service-level agreement, so Software-as-a-Service offerings can be monitored to ensure that the organization is receiving the level of service they have agreed to with the vendor.
Finally, APM provides the ability to utilize synthetic tests, which are tests that the APM runs to simulate normal user behavior but in a repeatable fashion. These tests can be useful in periods of low user utilization or after a change to an application or its supporting systems to function as a check and balance. The output of these tests may help an organization quickly ascertain whether the changes made have had a meaningful negative impact to an application and allow for quicker resolution. Due to their repeatability by isolating as many variables as possible, synthetic tests run at regular intervals may also be able to highlight minor deviations that, if left unchecked, can turn into user-impacting issues. This enables the organization to proactively address the issue and keep the application in a healthy state to improve user satisfaction and improve organization efficiency.
Auditing, Logging, and Monitoring
Audit, logging, and monitoring are an ongoing process that takes in the identity and vulnerability assessment of an endpoint and attempts to link or align this assessment with what the user or device is doing on the network throughout its life cycle on the network. The challenge of logging and monitoring is the sheer number of devices and users who access the network on a regular basis, and the need to crunch vast amounts of data to validate and archive what users and devices are doing. In addition to the need for users to administer network devices through command issuance, upgrade, periodic reboot, and similar actions, the organization also must track the behaviors of users and devices as they then connect through the network access devices and the potential responses that are sent back to the actions taken by these devices.
The phrase “signal within the noise” has been used throughout this book without much detail on what that signal is that should be looked for and sorted through. After the identity of a user or device has been determined, the identity’s expected behavior is mapped out, actions are taken to determine the potential vulnerabilities that exist within that identity, and enforcement is applied to attempt to prevent that identity from communicating with resources that it is not meant to do so. What could arguably be considered the most ongoing labor-intensive aspect of the equation is now required. This aspect is the need to monitor the behavior of that user or device while validating that this behavior is expected and aligns with security policy.
Change Detection
Change detection is when change occurs within the ecosystem, and that change is detected. Many times, this is not the case because there may be gaps in change detection tools within the organization. Working to close those gaps, even across Shadow IT environments, enables an organization to improve Zero Trust capabilities.
Change detection is just as it sounds. Changes happen. Organizations need to know what was changed, how it was changed, who authorized and/or did the change, where the change was made, and when it was changed. The organization needs to know all changes that occur, for research, response, or regulatory requirements.
For change detection in Zero Trust, if a change is made that violates policies, we want to be able to identify whether automatic alerts will be generated and sent to SOC, NOC, or appropriate personnel, including all of the what, how, who, and when information. Change detection can be very challenging; changes typically occur constantly in IT environments. Changes can include software updates or patches that are frequently applied. Configurations are frequently updated or newly created to support changes. The following types of solutions identify changes or detect unauthorized changes:
File Integrity Monitoring Solutions
Syslog
Messaging
Privilege access solutions
SIEM
Network Threat Behavior Analytics
Behavior analytics enables the method of Zero Trust that is to be able to define what traffic is expected in the environment or what traffic is out of norms in the environment. As a part of monitoring, organizations need to focus on not just what they are able to pull into a file that contains activity; organizations also need to analyze that information to make it actionable. When we say “make it actionable,” it is important to understand that organizations need to be able to see what traffic is doing in the organization’s environment whether in the data center or in the cloud. This is where network threat behavior analytics comes into a Zero Trust strategy.
Informing network behavior analytics with threat information and intelligence is critical to create greater understanding of the traffic in the environment, with current threats that are changing every day, every hour, and every minute. Network threat behavior analytics solutions are only as good as how they have been tuned for the organization.
Most organizations have enormous amounts of data transferring to and from data centers and externally to third parties. It is important for organizations to monitor this activity and define whether it is normal or if the activity is out of the norm. By implementing automation to sort through the alert information, organizations can use their teams to look at what is shown in the anomalies and what are the exceptions. By sorting out the “noise” and by extracting pertinent information, teams are able to respond with solutions to the most important events as they occur, instead of SOC or NOC personnel getting lost in the avalanche of information being collected when trying to track down relevant information.
One of the key takeaways is that organizations must be able to look at their information flow and define what has been compromised or is in a nominal state. This must be done in a structured way due to the level of traffic involved in the environment. Monitoring of network threat behavior analytics is a regular function that must be maintained and updated. It is not a “set it and forget it” set of solutions. For organizations, it is a very important part of any security operations center or any network operations center. The data must be analyzed in many ways. Next, we look at a few key concepts to analyze the data flow.
A common term in network threat behavior analytics is lateral movement, or east-west movement. When we talk about lateral movement, we must think about what normal traffic is between applications, databases, and endpoints and what is abnormal behavior.
Does this traffic go to an unknown repository inside the environment or ecosystem?
Are there communications between servers that should not talk to one another?
Is database traffic being transferred into a file for exfiltration?
Is there some kind of nefarious activity going from or to various objects on an intermittent basis or at a high frequency?
Do communications originate from a compromised endpoint?
Rules should be established in these tool sets to alert key resources to unexpected behavior in the environment. Another form of network threat behavior analytics modeling is looking at north-south movement, or vertical movement, which is traffic coming into or going out of the organization. Organizations need to ask questions like these:
Is data moving using standard methods, or are there command and control communications between malware and known threat actors in the world?
Are there geographic tendencies of the data going to places where the organization is not doing business?
Are there organizations that should not be receiving information from them?
Why is data moving out of the organization in large volumes?
What destinations are receiving traffic from the organizations? Valid or invalid?
These are valid questions to review and monitor, to establish rule sets that conform to the organization’s best practices. Organizations should define what actions should be taken when they see abnormal traffic performing outside of the baseline. When looking at this traffic, many times we see a combination of east-west traffic with periodic north-south traffic, to a command and control (C2) host outside of the organization.
In addition to network behavior, the same analytical process can be used by other tools for applications or cloud data. These tools will ingest data available to them using sources such as logs, API data, and other telemetry feeds to define a baseline for user or entity behaviors. As with network behavior analytics, other behavior analytic platforms will likely require a degree of tuning to help adapt the system to each particular organization. An example might be accounting systems that experience increased utilization for reporting during quarter or year-end financial events, where the number and frequency of user visits will increase as data is compiled to support financial reporting requirements. The output from application or cloud behavior analysis tools is similar to those supporting the network, in that they enable security personnel to more rapidly identify variances in access frequency or duration that may require further investigation. An attacker in the network may not be actively exfiltrating data or operating in a way to trigger the network behavior analysis tools but, if actively focusing on high-value systems, could still be discovered by other behavioral analysis platforms. Thus, ensuring that behavioral analysis beyond the network is also addressed helps to alleviate blind spots and prevents a false sense of security.
Security Information and Event Management (SIEM)
A Security Information and Event Management solution enables an organization to ingest enormous amounts of log and audit data from multiple systems and process this information into actionable data on security threats for response.
To have manual review of this data would be both ineffective, and potentially, even counterproductive. Therefore, a well-tuned and maintained SIEM is key to ensuring that the right information is presented in such a manner to be actionable in a Zero Trust Architecture.
A robust SIEM should be able to capture all desired events that are sent from the syslog or other sources and typically requires that the SIEM be designed and implemented in a distributed manner to ensure no blind spots or data gaps exist. It should be able to classify the source of the logs that it receives to add intelligence into the analysis process, with different analysis algorithms being applied to servers as opposed to network devices. A SIEM should have the ability to tag sources of events with some sort of metadata labeling system, giving the ability to add ownership by department, user, use case, or organizational data to the event source. It should be able to sort sources of events into a classification system. It should also support secure transport so that messages sent between systems of interest and the SIEM prevent eavesdropping.
The same need for behavioral monitoring goes for the ability to analyze denials from enforcement actions, such as access control lists or authentication failures. While it may be expected that a device is prevented from accessing the network or a specific device on the network, once enforced, that attempt to access that device should be limited or halted by the source device altogether. When the attempts to access the network or device continue, a threshold should be set indicating abnormal behavior thresholds have been met, which will trigger an alert on the SOC console, which will in turn lead to investigation of the identified issue. This approach can also take into consideration the identity of the device or user attempting to access the network or a certain resource. An alert to a specialized team, such as one that supports the C-suite executive team, would then be sent and prioritized for remediation.
The SIEM should directly integrate to organizational data brokers, such as a CMDB, ticketing system, or other security event monitoring solutions. This integration can provide additional valuable information that enhances the quality of data in the SIEM. Integration may also trigger external activities to occur via ticketing systems or other monitoring systems like in a network operations center.
For example, in many identity-based network access control products, the addition of data into tables, such as local users, or the addition of invalid data into tables to attempt to undertake a SQL injection attack may not trigger a syslog. However, inquiries via the API of the user database table can detect changes and utilize intelligence built into the SIEM to monitor and alert on this invalid data injection attempt.
There is commonly confusion for some on the differences between a SIEM and other seemingly similar tools, such as extended detection and response (XDR) and security orchestration, automation, and response (SOAR) platforms. While the intent for these tools is similar in their goal to aggregate and analyze data from multiple sources, they differ in that SOAR is focused on supporting multiple security tools to coordinate their activity based on one or more inputs. An XDR, on the other hand, concentrates on utilizing collected data from endpoints, which provides a large-scale view of changes to the environment because many security events will either ingress or occur at the endpoint, making it a valuable data stream.
Threat Intelligence
Threat intelligence is information that is collected by incident responders, governments, application vendors, equipment vendors, and many other sources. This intelligence gains more usefulness when it is ingested directly and in real time into the network, security, and application solutions within the organization. The information consists of things such as indications of compromise (IOCs), Common Vulnerability and Exposures (CVEs), IPS rulesets, and other types of information surrounding new or ongoing security events.
The global threat landscape is constantly evolving and shifting. The concept of collecting threat intelligence brings a clear focus into the strategy of Zero Trust. Understanding the environment in which an organization operates—with an eye on what is trusted and what is not—is what creates and tunes threat intelligence for an organization. Relationships between different types of active threats and the associated Internet activity to malicious domains provide deeper insights into patterns of malicious actors’ behavior. Keeping an eye on what is happening in the world, the country, the regulating bodies, and the news surrounding the organization can help inform the overall security standing and posture of an organization.
Partnering with key organizations that help connect an organization to its critical infrastructure community is critical. Working with fusion centers, government agencies, and public–private intelligence-sharing organizations helps you to partner with like or disparate organizations that will be important in a crisis. Setting up these relationships when times are good helps to support organizations when times are bad. In the US, organizations like InfraGard (Infragard.org) connect the community and are free to join.
Understanding the organization’s risk tolerance and key goals provides “tuning” to the intelligence that needs to be collected. Key questions include
Have there been changes to security reporting laws that impact the organization?
Are there new requirements that the organization is required to respond to?
Has there been a breach of a supply chain organization?
Does the organization have a robust third-party risk program?
Do third and fourth parties have a duty to report issues or breaches they have experienced in the contracts the organization has in place?
In public source news, does the organization observe threats that are impacting the organization, suppliers, governments, or treaty groups?
Taking this observed information and turning it into action requires solutions and tools that keep a constant vigilance over the threat landscape. An organization must have several methods to obtain threat intelligence and digest that intelligence directly into the organization’s solutions as well as to the teams and leaders of the organization. Being able to react and respond to critical situations and make correct business decisions based on the threat landscape enables companies to outperform their competition. Public sector organizations or agencies are better able to respond correctly to nation-state actors.
Most sources should be readily and automatically ingested by the processes, solutions, and services with a primary focus on the diversity of threat feeds and methods of intake in the overall solution set for the organization. Firewalls, automated segmentation solutions, anomaly detection solutions, monitoring solutions, endpoint protection solutions, and host protection solutions are examples, all of which need to have active thread feeds and the ability to alert when changes occur that affect the organization.
Traffic Visibility
Traffic visibility is the ability to view the full data activity of an organization at the time of occurrence and the ability to aggregate the traffic to be usable in the future. Many critical infrastructure organizations are required to retain traffic visibility information for extended amounts of time due to laws or regulations. This information should be aggregated into specific systems that support profiling of endpoints, security events, network events, or data analysis information.
Another requirement of traffic visibility is to ensure that there are no blind spots in the organization’s span of control. If there are blind spots, there will be issues with compliance to regulation based on industry (for example, PCI, FCC, FFIEC, and many others). When there are blind spots within an organization, they will weaken the organizational posture related to Zero Trust and may even degrade the function of critical capabilities.
Traffic visibility tools are also critical components of determining and creating segmentation enforcement policy.
Asset Monitoring & Discovery
The asset management database is a set of tools that are consistently and reliably updated as assets have been purchased, retired, or, in the case of building the asset management database, currently exist in the network. For those devices that currently exist in the network, a specified amount of information should be set as a standard to be populated, to give those monitoring the analytics for potential threats or security breaches within the network a fair advantage in investigating the endpoint. Policy & Governance should define the attributes that should be collected for each asset type.
Asset management is another key area to ensure that organizations have a standardized life cycle for all assets to provide the most effective and efficient usage of those assets for their intended purpose. The intent of an asset management program is to simplify operations and reduce risk by ensuring that the entire life cycle of the assets is mapped out and approved processes are followed from prior to acquisition up to the point of decommissioning or disposal. This includes standardizing as much as possible, such as configurations that make it easier to track for unapproved changes or modifications to these assets, while also ensuring that new deployments are fit for use. A lack of proper asset management can easily lead to lost productivity as users are unable to access key resources, such as applications, resources, or data repositories. With proper asset management, an organization gains the ability to harden configurations, ensure physical and virtual maintenance is regularly performed, and validate designs, while ensuring that assets are fit for use. While for the purposes of Zero Trust, the operation and configuration of an asset are likely to be the first line of thought, asset management must extend beyond this to include the entire life cycle of an asset, including the evaluation and acquisition, design, operation, maintenance, and replacement or decommission of the asset. The final point of replacement or decommission must also be properly managed to ensure that the asset is appropriately purged of any proprietary or sensitive data to limit risk to the organization.