Workload Configuration Extractor

Embodiments determine configuration information pertaining to a compute layer, a virtualization layer, and a service layer of a computing workload. In an example embodiment, a machine learning engine interfaces with a workload deployed upon a network to initially determine file structures of the workload. The machine learning engine then compares the determined file structures of the workload with predefined representations of file structures stored in a classification database. In turn, the machine learning engine identifies configuration information pertaining to the workload based on the comparing.

BACKGROUND

Workloads are known to utilize various computing resources to accomplish tasks as desired by a user entity by loading and executing appropriate software instructions. Such workloads may be deployed across a network of an organization such as an enterprise, and may feature, for example, various versions of sets of software instructions.

SUMMARY

Embodiments provide a method for automatically determining configuration information pertaining to a computing workload.

In some embodiments, a machine learning engine interfaces with a workload deployed upon a network to determine file structures of the workload. The machine learning engine compares the determined file structures of the workload with predefined representations of file structures stored in a classification database. The classification database may be a framework discovery database. In turn, the machine learning engine evaluates whether a given predefined representation substantially matches the file structures of the workload according to an accuracy threshold. If the result of the evaluation is “no,” the machine learning engine returns to determining file structures, so as to continue monitoring the workload for changes that may introduce a file structure that may substantially match the file structure of the workload. If the result of the evaluation is “yes,” the machine learning engine identifies configuration information pertaining to the workload based on the comparing. After such an identification, the method returns to determining configuration information for continuous monitoring as described above.

In some embodiments, the workload includes at least one of a framework, an operating system, and a software application. In some embodiments, the workload includes hardware. In such embodiments, the hardware includes one or more processors, one or more memory devices, one or more storage devices, and one or more network adapters. In such embodiments, the method further includes determining a status of a resource pertaining to the hardware tool by taking a pre-defined number of measurement samples at a node of the hardware tool, and comparing a function of the measurement samples with a pre-defined threshold value.

In some embodiments, the configuration information is at least one of an identifier of a framework or library associated with the workload, and at least one of a language, a version, and a name of a framework, operating system, or application deployed upon the workload. An identifier of a library may be, for example, a name of a library file such as a .dll file. In some embodiments, the configuration information includes type details of a virtualization environment deployed upon the workload, wherein the type details include at least one of a designation as serverless, a designation as a container, and a designation as a virtual machine. In some embodiments, the method further includes configuring the machine learning engine to modify representations of file structures stored within the classification database, or store additional representations of file structures within the classification database according to an update of a framework, operating system, or application, or creation of a new framework, operating system, or application.

In some embodiments, the identifying is informed by the evaluation of the result of the comparing, wherein the evaluation includes evaluating the result of the comparing with the aforementioned accuracy threshold. Some embodiments further include automatically determining a protection action based on the identified configuration information, and issuing an indication of a recommendation of the determined protection action to a controller associated with the workload. Some such embodiments further include automatically selecting the recommendation from a recommendation database. In some embodiments, the recommendation is selected from the recommendation database by an end-user. In some embodiments, the method further includes, prior to issuing the indication of the recommendation, augmenting a recommendation database in response to an input from an end-user defining the recommendation.

Some embodiments further include deploying software instrumentation upon the workload. The software instrumentation can be configured to determine real-time performance characteristics of the workload. In some such embodiments, the software instrumentation is further configured to indicate a condition of overload perceived at the workload. In some embodiments, the identified configuration information includes an indication of a vulnerability associated with the workload. In some such embodiments, the vulnerability is identified based on an examination of process memory. In such embodiments, the indication of the vulnerability further provides a quantification of security risk computed based on the examination of process memory. In some embodiments, the identified configuration information includes an indication of at least one file that is to be touched by a given process during a lifetime of the given process running upon the workload. In such embodiments, the method includes constraining execution of the given process to prevent the given process from loading files other than the at least one file that is to be touched by the given process, thereby increasing trust in the given process. In some embodiments, the workload includes a plurality of workloads. In some embodiments, a framework, an operating system, or an application is distributed or duplicated amongst the plurality of workloads. In some embodiments, the method further includes constructing a topological representation of the plurality of workloads based on identified configuration information corresponding to respective workloads of the plurality thereof.

Another example embodiment is directed to a system for automatically determining configuration information pertaining to a computing workload. In such an embodiment, the system includes a machine learning engine configured to determine file structures of the workload. The machine learning engine is further configured to compare the determined file structures of the workload with predefined representations of file structures stored in a classification database. The classification database may be a framework discovery database. The machine learning engine is configured to evaluate whether a given predefined representation substantially matches the file structures of the workload. If the result of the evaluation is “no,” the machine learning engine returns to determining file structures, so as to continue monitoring the workload for changes that may introduce a file structure that may substantially match the file structure of the workload. If the result of the evaluation is “yes,” the machine learning engine identifies configuration information pertaining to the workload based on the comparing. After such an identification, the machine learning engine returns to determining configuration information for continuous monitoring as described above.

Yet another example embodiment is directed to a computer program product for automatically determining configuration information pertaining to a computing workload. In such an embodiment, the computer program product includes one or more non-transitory computer-readable storage devices and program instructions stored on at least one of the one or more storage devices. In such an embodiment, the program instructions, when loaded and executed by a processor, cause a machine learning engine associated with the processor to determine file structures of the workload. The machine learning engine is further configured to compare the determined file structures of the workload with predefined representations of file structures stored in a classification database. The classification database may be a framework discovery database. The machine learning engine is configured to evaluate whether a given predefined representation substantially matches the file structures of the workload. If the result of the evaluation is “no,” the machine learning engine returns to determining file structures, so as to continue monitoring the workload for changes that may introduce a file structure that may substantially match the file structure of the workload. If the result of the evaluation is “yes,” the machine learning engine identifies configuration information pertaining to the workload based on the comparing. After such an identification, the machine learning engine returns to determining configuration information for continuous monitoring as described above.

It is noted that embodiments of the method, system, and computer program product may be configured to implement any embodiments described herein.

DETAILED DESCRIPTION

A description of example embodiments follows.

Embodiments provide a method of determining configuration information pertaining to a workload. In some embodiments, the workload is deployed upon a network. Amongst other examples, workloads may include frameworks, operating systems, or applications, or a combination thereof.

Some embodiments use machine learning to automatically determine configuration information pertaining to the workload. Some such embodiments implement an Application Topology Extraction Machine Learning (ATE-ML) engine to automatically determine configuration information for workloads. In such embodiments, an ATE-ML engine may be configured to produce an output that can, in turn, be used to create, for example, an application-aware inventory of software assets deployed on the network as represented in an application topology file, as described in U.S. application Ser. No. 17/646,622, filed Dec. 30, 2021. The ATE-ML engine may alternatively or additionally be configured to produce, as outputs, other representations of configuration information pertaining to at least one workload.

Embodiments of an ATE-ML engine are configured to perform auto-discovery and auto-compliance procedures as described hereinbelow, and to establish auto-instrumentation of a subject network and workloads associated therewith.

Embodiments of an ATE-ML engine perform a deep discovery and learning of a network environment, e.g., of an organization such as an enterprise. In such embodiments, the performing of the deep discovery and learning serves to inform establishment of the aforementioned auto-discovery, auto-compliance, and auto-instrumentation procedures.

Example Environment of Implementation

FIG. 1is a schematic block diagram depicting an example network environment101in which an embodiment of a method of automatically determining configuration information may be performed. In such an embodiment, a workload may include a monolith or microservices-based software application. Such an application may be installed at additional workloads deployed across a network. InFIG. 1, objects111a,111b,113a,113b,115,117a,117b,119a,119b,119c,121a,121brepresent network topology of an aspect of a workload such as an application. Depicted in the lowest layer of the network topology are individual workloads that provide the application functionality. Such individual workloads may comprise three layers, including an infrastructure layer (shown in red inFIG. 1), a virtualization layer (shown in orange inFIG. 1) and a service layer (shown in blue inFIG. 1). In such an embodiment, code used within a given workload can be resident in either the file system or in memory. The network environment101may include an intranet103connected to the Internet105and as such may be accessed by an end-user107. In some cases, the end-user107may be a malicious attacker.

Continuing with respect toFIG. 1, deployed upon the intranet103is business logic for respective business units, which may include a first business unit109aand other business units up to and including a Tth business unit109b. Such business units may also be referred to as tenants. Within the business logic for the business units109a,109bare software applications111a,111b. While only a first application111aand second application111bare depicted, the business units109aand109bmay utilize any number of applications. Each such application111a,111bis deployed on at least one cloud location113a,113b. Within the cloud location113a,113bis deployed a demilitarized zone115, beyond which are deployed at least one subnet from a first subnet zone117ato a Zth subnet zone117b. Within the subnet111a,117bare deployed various services including at least a first service referred to as service119aand a last service referred to as service119bon subnet zone117a. Other subnets may also run services, depicted in the diagram101as subnet zone Z117brunning service K119c. Within each service, such as service119a, are deployed workflows including at least a first workload121aup to and including a Wth workload121b. Upon each workload is deployed an application service instance. The application service instance includes an infrastructure hardware layer123, a virtualization layer125, and a service, which may include operating system runtime packages127, compatible precompiled binary packages129, and compatible byte code packages131.

FIG. 2is a block diagram201illustrating an individual workload that may be deployed upon a network to enable functionality of software such as an application. Such a workload may include an infrastructure layer, a virtualization layer, and a service layer. So configured, such a workload may be referred to as an application service instance (ASI). The infrastructure layer defines attributes such as compute, storage, and host operating system (OS) attributes. This layer can be provided and managed by either a 1stor 3rdparty cloud provider or a private data center provider.

The ASI shown in the diagram201ofFIG. 2includes a collection233of components comprising a monolith service or a microservice. Such a collection233includes virtual machines233a, containers233b, and serverless functions233c. The ASI shown in the diagram201encompasses a workload235deployed on a server. The workload235includes an infrastructure layer235a, a virtual, i.e., virtualization layer235b, and a service layer235c. The infrastructure layer235aincludes physical hardware237, persistent storage239available on the network, a host device241with a processor and memory, a physical network interface card243, local storage245, and a host operating system247. The virtualization layer235bmay include a hypervisor249, and a guest entity251that may include a virtual processor and memory. The virtual layer may also include a virtual network interface card253, a virtual disk255, and may have an operating system257installed thereupon. The virtual layer235balso includes, for container applications, container mounts259, container runtime components261and network plugin263. The virtualization layer235bmay also include a serverless function handler265. The hypervisor249of the virtual layer235bmay, through the operating system257, connect to one or more virtual machines233athat are part of the service layers235c. Such virtual machines233amay include handlers279a,279b,279c,279d, application programming interface (API) or web logic or databases275a,275b, third-party binaries277a, operating system runtime binaries280, web frameworks269a,269b, binary framework271a, operating system services273, and process name spaces267a,267b,267c. In embodiments operating upon software configured as containers233b, the service layer235cincludes handlers279e,279f, API or web logic or database275c, web frameworks269c, process namespace267d,267e, third-party binaries277b, and binary frameworks271b. In serverless configurations, a serverless function handler265interfaces with handles279g,279h, respectively through APIs or web or business logic functions281, and binary functions283.

The workload's virtualization layer235bdefines attributes such as a virtualization type, which may be implemented as a bare metal instance, a virtual machine instance, a container instance or a serverless function. This layer235bcan be provided and managed by either the 1stparty (where the application and infrastructure are owned and operated by the same entity) or by 3rdparties (where the application and infrastructure are owned and operated by different entities).

The service layer235ccontains active code that provides the application's observable functionality. The service layer235ccan be powered by a mixture of OS and OS-provided runtime services (e.g., a host framework), one or more 1stor 3rdparty precompiled executables and libraries (e.g., binary frameworks), and one or more 1stor 3rdparty interpreted code files (e.g., interpreted frameworks).

Basis of Automatic Determination of Configuration Information

FIG. 3is a flow diagram showing an example embodiment of a method301of determining configuration information pertaining to a workload. The method301begins at a machine learning engine by interfacing385with a workload deployed upon a network to determine file structures of the workload. The method301continues by comparing387, with the machine learning engine, the determined file structures of the workload with predefined representations of file structures stored in a classification database. The classification database may be a framework discovery database. In turn, the method301evaluates389whether a given predefined representation substantially matches the file structures of the workload. If the result of the evaluation389is “no,” the method301returns to step385to continue monitoring the workload for changes that may introduce a file structure that may substantially match the file structure of the workload. If the result of the evaluation389is “yes,” the method301continues by identifying391, with the machine learning engine, configuration information pertaining to the workload based on the comparing. After such an identification391, the method301returns to step385for continuous monitoring as described above.

In some embodiments of the method301, the workload includes at least one of a framework, an operating system, and a software application. In some embodiments, the workload includes hardware. In such embodiments, the hardware includes one or more processors, one or more memory devices, one or more storage devices, and one or more network adapters. In such embodiments, the method301further includes determining a status of a resource pertaining to the hardware tool by taking a pre-defined number of measurement samples at a node of the hardware tool, and comparing a function of the measurement samples with a pre-defined threshold value.

In some embodiments of the method301, the configuration information is at least one of an identifier of a framework or library associated with the workload, and at least one of a language, a version, and a name of a framework, operating system, or application deployed upon the workload. An identifier of a library may be, for example, a name of a library file such as a .dll file. In some embodiments, the configuration information includes type details of a virtualization environment deployed upon the workload, wherein the type details include at least one of a designation as serverless, a designation as a container, and a designation as a virtual machine. In some embodiments, the method301further includes configuring the machine learning engine to modify representations of file structures stored within the classification database, or store additional representations of file structures within the classification database according to an update of a framework, operating system, or application, or creation of a new framework, operating system, or application.

In some embodiments of the method301, the identifying391is informed by the evaluation391of the result of the comparing, wherein the evaluation391includes evaluating the result of the comparing with an accuracy threshold. Some embodiments further include automatically determining a protection action based on the identified configuration information, and issuing an indication of a recommendation of the determined protection action to a controller associated with the workload. Some such embodiments further include automatically selecting the recommendation from a recommendation database. In some embodiments, the recommendation is selected from the recommendation database by an end-user. In some embodiments, the method301further includes, prior to issuing the indication of the recommendation, augmenting a recommendation database in response to an input from an end-user defining the recommendation.

Some embodiments of the method301further include deploying software instrumentation upon the workload. The software instrumentation can be configured to determine real-time performance characteristics of the workload. In some such embodiments, the software instrumentation is further configured to indicate a condition of overload perceived at the workload. In some embodiments, the identified configuration information includes an indication of a vulnerability associated with the workload. In some such embodiments, the vulnerability is identified based on an examination of process memory. In such embodiments, the indication of the vulnerability further provides a quantification of security risk computed based on the examination of process memory. In some embodiments, the identified configuration information includes an indication of at least one file that is to be touched by a given process during a lifetime of the given process running upon the workload. In such embodiments, the method301includes constraining execution of the given process to prevent the given process from loading files other than the at least one file that is to be touched by the given process, thereby increasing trust in the given process.

In some embodiments, the workload includes a plurality of workloads. In some embodiments, a framework, an operating system, or an application is distributed or duplicated amongst the plurality of workloads. In some embodiments, the method301further includes constructing a topological representation of the plurality of workloads based on identified configuration information corresponding to respective workloads of the plurality thereof.

Overall Architecture of ATE-ML Engine

FIG. 4Ais a schematic block diagram depicting an example embodiment of a system401afor automatically determining configuration information pertaining to a workload. According to the embodiment, the system401aincludes an application topology extraction (ATE) module494-01. The ATE494-01includes an ATE engine494-02and a message transmit-receive module494-03a. The ATE494-01is configured to perform a basic scan494-04at stage zero, an advanced scan494-05at stages one and four, and a deep discovery scan494-06in stages two and three. Such basic494-04, advanced494-05, and deep discovery494-06scans respectively produce scan databases494-07a,494-07b, and494-07c. The ATE494-01so enabled may communicate with a central logger repository494-08. In turn, the central logger repository494-08may communicate with a cloud interface such as an Athena cloud interface494-12, and a machine learning platform494-09. The message transmit receive module494-03aof the ATE494-01may interface with a corresponding message transmit receive unit494-03bdeployed within the machine learning platform494-09. The machine learning platform494-09includes a machine learning engine494-10that communicates directly with the message transmit receive module494-03b.

The ATE engine494-02and the machine learning engine494-10ofFIG. 4Atogether comprise an aspect referred to herein as the ATE machine learning engine (ATE-ML engine). The machine learning engine494-10provides various compliance models including compliance models for the ATE494-11a, for characteristics494-11bof the workload (e.g. application), code files494-11cof the workload (e.g., application), and classes and methods494-11dof the workload (e.g., application). The machine learning platform494-09may interface with the cloud interface such as Athena494-12, supported by a disk including auto segmentation JSON data494-07d. The cloud interface494-12may connect to a larger network494-13. In some embodiments, the machine learning platform494-09is configured to provide at least one recommendation494-14based on an evaluation by the machine learning engine494-10according to models494-11a-d. Such recommendations494-14may include at least one of library injection494-15a, runtime memory protection494-15b, FSR494-15c, APG494-15d, PVE and CVE recommendations494-15e, FSM recommendations494-15f, network activity monitor recommendations494-15g, and post monitoring recommendations494-15h. Each such recommendations494-15a-hmay be deployed upon the network494-13. The network494-13may also provide access to an offline storage location494-07f.

Auto-Discovery and Auto-Compliance Procedures with ATE-ML Engine

The ATE-ML may be configured to perform auto-discovery and auto-compliance procedures. Such functionality may include basic scan494-04, advanced scan494-05, and deep discovery494-06as described hereinabove with reference toFIG. 4A. Such functionality may be performed in stages. As such, a Stage 0 may include basic scan494-04, Stages 1 and 4 may include advanced scan, and stages 2 and 3 may include deep discovery.

In Stage 0 of the auto-discovery and auto-compliance procedures, the ATE-ML engine extracts baseline characteristics of a workload such as resources thereof (e.g., installed products, OS, disk, processor (CPU), memory, platform, and/or network interfaces). The ATE-ML engine may also extract real time performance characteristics for various system resources (e.g., available memory, CPU usage, and/or network traffic). The ATE-ML engine may also extract various processes characteristics (e.g., active processes, context, network activity, and/or process parent-child relationships). These aforementioned baseline characteristics may thus be used to establish an auto-discovery and auto-compliance profile.

A hardware profiling procedure, which may be subordinate to Stage 0 of the auto-discovery and auto-compliance procedures, may be performed by the ATE-ML engine for guest or host ASIs, and for instances of physical hardware used by the workload (including hardware used by a software application running on the workload), to ensure each guest ASI and each physical host ASI conforms to requirements and has enough head room in terms of available resources. In such a hardware profiling procedure, the ATE-ML engine may extract the resource information and performance information of each guest or physical host ASI. The ATE-ML engine will capture such data (e.g., on resource headroom) for each guest or host ASI for a period of x samples. Such a period may be the duration of resource utilization, may be programmable, and may be subject to a pre-defined default value.

Resource information and performance information of guest or physical host ASIs may include indicators such as: (i) number of physical/virtual cores associated with an ASI or an image deployed thereupon, (ii) CPU utilization—user, kernel and wait cycles system level, (iii) memory utilization—committed, working set, shared memory system level, (iv) memory utilization—total and free system memory on a host ASI or associated with an image deployed thereupon, (v) network address—IP address associated with each physical/virtual network adapter, (vi) network adapter—physical/virtual network adapters associated with a guest ASI, (vii) network utilization—receive and transmit I/O per physical/virtual adapter associated with a host ASI or an image deployed thereupon, (viii) disk access I/O—disk I/O for read and write operations at process level, (ix) disk space utilization—total and free disk space on a host ASI or an image deployed thereupon.

From performance indicators such as those mentioned above, the ATE-ML will create an aspect of the auto-discovery and auto-compliance profile specifically pertaining to resource requirements and utilization context. The ATE-ML engine may perform a threshold analysis and flag such indicators accordingly. For example, based on the performance analysis, if a CPU utilization threshold is crossed, the ATE-ML engine will flag the CPU utilization indicator and apply predefined heuristics to determine a next stage of operation.

In Stage 1 of the auto-discovery and auto-compliance procedures, the ATE-ML engine extracts “App+Web+Interpreter”-based vectors through a compliance extraction method. Data represented by these vectors may be evaluated by the ATE-ML engine according to various defined heuristics of compliance, to automatically determine a current and next stage of operation. For example, at Stage 1 on a .Net-based ASI, the ATE-ML engine may extract the .Net vectors (.Net framework, pipeline mode, etc.) to determine a current and next stage of operation. Such vectors may be further analyzed by the ATE-ML engine to augment or update the auto-discovery and auto-compliance profile.

In Stage 2 of the auto-discovery and auto-compliance procedures, the ATE-ML engine performs a first phase of deep discovery using various techniques to extract “App+Web+Interpreter”-specific details. Such details may include application code files, web framework-related code files, etc. The deep discovery method may apply techniques such as iterative Virtual Address Descriptor (VAD) extraction of an interpreter process, clustered directory traversal to extract code files, inspection, and extraction of application topology through application- or web server-aware structured files, such as configuration files. Once the extractions are complete, the ATE-ML engine structures the extracted application code and web server code files in pre-defined formats (as they are found on the platform). Such clustered and VAD data vectors may be further analyzed by the ATE-ML engine to augment or update the auto-discovery and auto-compliance profile. For example, at Stage 2, the ATE-ML engine may identify the applications, their web context locations, and their infrastructure present in the system (i.e., workload) in real time.

In Stage 3 of the auto-discovery & auto-compliance procedures, the ATE-ML engine performs a second phase of deep discovery using various techniques to extract “App+Web+Interpreter”-specific details, such as “Classes+Methods” hierarchy and relationships. The deep discovery method applies techniques such as RegEx extractions on plaintext code files, assembly extractions for managed code modules, and Import Address Table (IAT) parsing for imported functions for native code modules. RegEx extractions are very application-specific techniques since structures of classes and methods are highly based on semantics of the languages of “Application+Web” server development. Once the extractions are complete, the ATE-ML engine will structure the extracted application and web server Classes+Methods relationships in defined formats, as they are found on the platform during the discovery phase.

The data acquired by deep discovery in Stages 2 and 3 will be used by the ATE-ML engine to apply the modelling and determine the compliance results. The ATE-ML engine takes many inputs from different sources, such as vulnerability profiles and a compliance matrix. Once the compliance results are determined, the ATE-ML engine will proceed to Stage 4 of the auto-discovery and auto-compliance procedures, which include an auto-instrumentation sub-procedure.

In Stage 4 of the auto-discovery and auto-compliance procedures, the ATE-ML engine performs a set of final data extractions in support of instrumenting the workloads in the server environments. The ATE-ML engine will execute an application instrumentation extraction method to retrieve the data, which will, in turn, be integrated in a JSON structure by the ATE-ML engine, to support an auto-instrumentation workflow.

Below is the structural format of the aforementioned JSON structure according to an example implementation:

Predictive and Explanatory Models for ATE-ML Engine

The ATE-ML engine includes several predictive & explanatory models. One purpose of this engine is to provide recommendations to control or influence the auto-discovery phase, and, from there, produce a partially filled template of Instrumentation JSON.

FIG. 4Bis a block diagram depicting overall architecture401bof such models. According to the embodiment, a target system494-31is chosen. Target system494-31may be virtual. Depending upon an operating system of the target system494-31, packages chosen may be a Windows package494-32a, a Linux package such as a Red Hat Linux package494-32bor another type of package494-32c. Initially, a set of test bed data494-33may be run through the system494-31, producing configuration information to be stored in the ATE result store494-34. A compatibility matrix494-35may provide data to the ATE results store494-34so as to train the model to adapt to variations in the workloads of such version. In an initial case, or periodically when updates or refinements are released, training data494-36is pulled from the ATE results store494-34to train the machine learning enabled auto-discovery model engine494-38. Subsequently, validation data494-37bmay be run through the auto-discovery model engine494-38to ensure accuracy of training. After training and validation, auto-discovery model engine494-38may apply a Windows discovery machine learning model494-39a, a Linux model such as a Red Hat Linux discovery machine learning model494-39b, or another model494-39c, depending upon the operating system deployed upon the workload. An auto-discovery model494-40may be thus produced and exported to an application topology extractor (ATE)494-41. Results494-42may include configuration information and decisions or recommendations associated therewith. The model401bofFIG. 4Bis an iterative process494-43that includes periodically training and updating models and packages used in determining configuration information, and continuously scanning workloads to maintain updated configuration information.

In an embodiment, all models are built on top of results produced by the ATE-ML engine (i.e., ATE results) during the auto-discovery and auto-compliance procedures and stored in a master database. Predictive models may include classifiers, which can identify the installed and running server components on target systems in the auto-discovery phase ofFIG. 4B. There may be specific models for different OS types (e.g., Windows, Linux). Under each OS type, there may be further divisions between models for different types of server components. For example, database discovery and web application server discovery may have separate models. All these predictive models consume ATE-ML engine output as input and produce data classifying server components and other server statistics as output. Choice of underlying machine learning (ML) methods varies from model to model (e.g., random forest, logistic regression).

Explainability of ML models helps to produce recommendations to be fed into Instrumentation JSON in the Discovery Results phase ofFIG. 4B. According to an embodiment, explainable AI (XAI)-based methods are used to interpret a model and find out a reason for a prediction. For example, if a remote system is classified by the predictive model to have a web server, then XAI-based approaches help to identify processes and services responsible for running that web server. Such XAI-based methods may include standard model-specific explanatory methods or more robust model-agnostic methods such as game theory-based approaches.

FIG. 5Ashows an example time sequence500afor an embodiment of an application topology extractor machine learning workflow to be used in conjunction with a PUP workload. The time sequence500aincludes actions performed by an application topology extracting module502, a communications layer504, and a machine learning ML engine equipped with a ML model506. The time sequence500astarts at step508having been supplied with an IP location such as an Athena IP address510of a workload, and having been supplied with instrumentation data512, vulnerability profiles514, and a compatibility matrix516. Items510,512,514,516serve as inputs to an ATE compliance model518. A workload may be configured as an ASI, i.e., a host. Compliance data522pertaining to such a host may be provided via a command data channel520of the communications layer504. Such host compliance data522may include examples527pertaining to installed hardware products, operating system, disk, processor (CPU), memory, platform, network interfaces, system performance, profiling, active processes, context, network activity, and process identifications (PID) which may include indications of parent-child relationships among processes. The ATE compliance model518interfaces with host resource threshold interpreters526and performs a PHP stack discovery process528a. If a PUP stack is not discovered, web compliance discovery completes582; otherwise, if a PUP stack is discovered530a, the sequence proceeds to implementation of a PUP compliance model532aand execution of a PUP compliance extractor method534a, to discover various attribute aspects of the workload. Such aspects may include PUP NTS version discovery536a, Zend version discovery538a, framework discovery540a, web and application discovery542a, and PUP deployment discovery544a. Framework discovery540amay discover example frameworks540a-1such as WordPress, Joomla!, and Laravel, amongst others. PUP deployment discovery544amay determine544a-1deployment with either a web or application server. If the workload is not found to be PUP compliant, web compliance discovery completes582; otherwise, if the workload is found to be PUP compliant546a, a PHP application discovery process548ais run. The PHP application discovery process548aincludes application code discovery550, web code discovery552, Zend code discovery544, a walkthrough VAD of interpreter process memory to extract code file locations556, a walkthrough of clustered file systems to extract code file locations558, and inspection and extraction of application topology (i.e., geometry) through a configuration file560. The process548athereby extracts application PHP code files562a. Subsequently, a customer application clients model564is applied. If the customer application client model564is not found to be compliant, web compliance discovery completes582; otherwise, if the customer application client model564is found to be compliant, the machine learning engine506proceeds to discovery of PHP application classes and methods568a. Discovery of PHP application classes and methods568amay include discovery, by the ATE, of application classes and methods570, which, in turn, may include direct class/method extraction through PHP code files572a, and indirect class/method extraction574. Such functionality produces a final class/method collection set576to be applied to a customer application class and methods compliance model578. If the application is not found to be compliant, web compliance discovery completes582; otherwise, instrumentation584is deployed upon the application584. If web compliance discovery is unable to complete, an APG is consulted586; otherwise, extraction auto-instrumentation data588, provided by the applied instrumentation584, is uploaded594to the cloud, e.g., Athena. Such extraction auto-instrumentation data may be provided by an application instrumentation extraction engine590, and may include data592such as at least an application context path, application launch path, and other context.

FIG. 5Bshows an example ATE-ML workflow time sequence500bof the application discovery of a .Net workload. The sequence500bproceeds in a similar fashion as the sequence500afor a PUP workload. Differences therebetween include a .Net stack discovery process528b, an evaluation530bthereof, extraction534bof the .Net compliance model532b, and aspects of the .Net compliance model532bincluding .Net version discovery536b, framework discovery540b, and web and application discovery542b. Framework discovery540bfor .Net may include determinations540b-1of ASP.net, 4.x, webforms, web pages, web services, and MVC. The .Net compliance evaluation546bis performed subsequently. A .Net application discovery548bis performed to extract code files including application binaries and code files such as .dll and .aspx files562b. A .Net application class and method discovery process568bmay include data obtained through direct class method extraction572bthrough files such as .aspx files, reference assemblies, IAT modules, and decompiled managed code.

FIG. 5Cshows an example ATE-ML workflow time sequence500cof the application discovery of a Java workload. The sequence500cproceeds in a similar fashion as the sequences500aand500bfor PUP and .Net workloads described hereinabove in relation toFIGS. 5A and 5B, respectively. Differences therebetween include a Java stack discovery process528cand evaluation530cthereof, extraction534cof the Java compliance model532c, and aspects of the Java compliance model532cincluding runtime version discovery536c, framework discovery540c, and web and application discovery542c. Framework discovery540cfor Java may include determinations540c-1of SpringWeb, Struts, GWT, JSF, etc. Web and application discovery542cmay include determinations542c-1of web or application servers based on the compliance matrix. The Java compliance evaluation546cis performed subsequently. A Java application discovery548cis performed to extract code files including application binaries and code files such as .war, .jar, and class files562c. A Java application class and method discovery process568cmay include direct class and method extraction572cthrough files such as Java code files.

FIG. 5Dshows an example ATE-ML workflow time sequence500dof the application discovery of a Ruby on Rails (RoR) workload. The sequence500dproceeds in a similar fashion as the sequences500a,500b, and500cfor PUP, .Net, and Java workloads described hereinabove in relation toFIGS. 5A, 5B, and 5C, respectively. Differences therebetween include a RoR stack discovery process528dand evaluation530dthereof, extraction534dof the RoR compliance model532d, and aspects of the RoR compliance model532dincluding framework discovery540dand web and application discovery542d. Framework discovery540dfor RoR may include determinations540d-1of a Rails framework. Web and application discovery542dmay include determinations542d-1of an Apache HTTP Server, e.g., version 2.4, or application servers such as Puma, Unicorn, or Passenger. The RoR compliance evaluation546dis performed subsequently. A RoR application discovery548dis performed to extract code files including application code files such as .rb files562d. A RoR application class and method discovery process568dmay include direct class and method extraction572dthrough files such as Ruby code files.

FIG. 5Eshows an example ATE-ML workflow time sequence500eof the application discovery of a Node.js workload. The sequence500eproceeds in a similar fashion as the sequences500a,500b,500c, and500dfor PUP, .Net, Java, and RoR workloads described hereinabove in relation toFIGS. 5A, 5B, 5C, and 5D, respectively. Differences therebetween include a Node.js stack discovery process528eand evaluation530ethereof, extraction534eof the Node.js compliance model532e, and aspects of the Node.js compliance model532eincluding framework discovery540e. Framework discovery540efor Node.js may include determinations540e-1of Express, HTTP/S, Node.ts, etc. The Node.js compliance evaluation546eis performed subsequently. A Node.js application discovery548eis performed to extract code files including application code files such as .js files562e. A Node.js application class and method discovery process568emay include direct class and method extraction572ethrough files such as Node.js code files.

Phases of Initial Provision of ACM Functionality

An initial MVP phase of provisioning an auto-configuration manager (ACM) involves delivering a ML model for all web frameworks already on the existing compatibility matrix, for initial deployment in virtual machine (VM) form factor in the customer setup. This phase will allow the ACM to discover and provision host-monitoring, web-monitoring, and memory-monitoring capabilities on an on-demand basis, to support automatic determination of configuration information of hosting aspects, remote web service aspects, and local memory aspects of a workload.

In Phase 2, the ACM may add further automation such that the customer does not have to perform on-demand provisioning. The ACM will discover that the homeostasis has been disturbed automatically. As a result, the customer simply takes a maintenance window in which the ACM will reprovision a cloud-management solution (CMS) automatically.

In Phase 3, the ACM will provision both VM-based and container-based workloads. For container based applications, the ACM may output a CMS-appropriate package manager manifest. In this case, both the container runtime file as well as the overall deployment manifest will be fully ready. The ACM stacks the customer's provisioning tool (e.g., helm, terraform, etc.) with appropriate monitoring and protection modules.

In Phase 4, the ACM will provision the workloads directly instead of via the CMS. In this case, workloads will come up fully protected. This is needed because with serverless virtualization, there would not be enough time to perform provisioning through the CMS because this operation can take minutes.

Please note that changing a web application's business logic does not require a rediscovery; it is only necessary to do so when the framework code is changed.

In embodiments in which a workload includes a software application, determined configuration information pertaining to the application may be stored in various application-aware maps (AppMaps) to ensure that the application always operates within a predetermined set of guardrails at runtime.

FIG. 6depicts various application maps, i.e., AppMaps696, supported by embodiments. AppMaps696a-eare imposed by a host-monitoring module. AppMaps696f-iare imposed by a web-monitoring module, and the AppMap696iis imposed by a memory-monitoring module. Such AppMaps696include maps of legal non-vulnerable executables696a, legal non-vulnerable libraries696b, legal non-vulnerable scripts696c, directory and file control696d, runtime memory protection696e, local file inclusion696f, remote file inclusion696g, interpreter verbs696h, continuous authorization696i, and control flow696j.

Automated Configuration and Reconfiguration of ATE-ML Engine by ACM

Since applications are constantly evolving, sometimes as often as multiple times a day, the ATE-ML engine is configured to identify compatible web and binary application frameworks. This configuration of the ATE-ML engine may have two components: a static component, and a runtime component.

The static component involves (i) finding files on disk and identifying a cluster of executable files that are rooted at a directory location that may change from installation to installation but not relative to each other, and (ii) finding one or more configuration files that determine “configurable options” for a given framework.

The dynamic component involves (i) performing a sufficiently exhaustive do-no-harm test that exercises enough functionality of the application such that as many executables as are part of the application are loaded in memory, (ii) instrumenting the executables and determining that there is no adverse impact on the application's functionality, and (iii) recording the performance overhead, not only in terms of CPU and memory bloat, but also in terms of latency and overhead.

While the static component is rigid and does not change as easily, the dynamic component has a strong dependency on the do-no-harm test. Therefore, the ACM is able to adapt to newly detected changes.

An initial qualification can be done in a qualification testing lab of a solution provider using a standard do-no-harm test. However, if a customer has a specific do-no-harm test, then the customer can provide the same to the solution provider for use in its lab.

To summarize, there are various reasons that the deployment homeostasis of a given application can trigger (re)discovery of a web or binary framework, including (i) a customer changes or adds framework code on the disk relative to the baseline framework used by a qualification team of the solution provider to initially train the ATE-ML engine, (ii) a legal executable in the package starts running for the very first time and such a process is not included in the ML model developed by the solution provider's qualification team, (iii) the qualification team has released a fresh or modified an existing, qualified framework, and (iv) a customer may decide to run different protection actions from those specified by the initial qualification.

ACM Architecture

The system701can be employed to implement a method, e.g., the method301, for determining configuration information of a workload. Beginning from an FTP location such as Exavault797-01, via the Internet797-02, and through a local file repository (LFR)797-03, an ACM server797-04interfaces with an ACP engine797-05to connect with a maintenance window database797-06and a CVE database797-08. The ACM server797-04also connects with a machine learning database797-07, compatibility matrix database797-09, and an ACM database797-10. The ACM database797-10may be connected back to the ACM server797-04by handlers of the ACM user interface797-11. A user797-12may, through the ACM user interface797-11, access the ACM database797-10. The compatibility matrix database797-09may include information such as FSM data797-13, performance data797-14, instrumentation data797-15, and default protection actions797-16. The ECM server797-04may additionally interface with a FSR database797-17. The ACM server797-04may be provisioned upon a CMS797-18which has access to a license database797-19. CMS797-18and the ACM server797-04may, in a parallel manner, connect to a software bus, e.g., a Kafka bus797-20, which connects the various workloads, including a first workload797-21aand an Nth workload797-21b. Such workloads may include an ATE engine797-22, a machine learning engine797-23, a local ACP engine797-24, disk797-25for non-transitory storage, memory797-26, and definitions of processes797-27.

ML Training and Qualification Workflow

From time to time, a solution provider a host, binary, or web framework for qualification. First, a list of executables associated with each targeted framework(s) may be fed into ML Training tables. Next, Do-No-Harm (DNH) tests may be performed on the targeted framework(s). The goal of the DNH tests is to ensure that as much code coverage as possible is obtained, as many processes as possible are exercised, and as many libraries as possible get loaded in those processes. In case of web applications, a high-quality crawler can be used to exercise as much of the web application as possible. Reference can also be made to QA sites and GitHub where users may have checked in scripts used to exercise and test the said framework. This is especially true of open-source code.

The DNH test may be run with and without the security solution to determine performance impact. Please note that the ATE can be run for a variable amount of time and data capture is cumulative. For example, all processes that ran and all files that got loaded into memory are cumulative and this forms the basis of FSM data associated with the framework under qualification. Processes whose executable is in the package associated with the framework, or any children processes associated with the aforementioned executables, may be targeted.

In case of non-web applications or compiled binaries, the goal would be to capture compute and memory overheads, whereas, for web applications, the goal would be to additionally capture latency and throughput impacts of instrumentation features.

The output of the qualification process would be to (i) enumerate, for each process, which of four-instrumentation modes (foreground process, background service, or child process with or without inherited environment) was used, (ii) generate an instrumentation script for each process for each mode, (iii) generate a rollback script for each process for each mode, (iv) generate an FSM for each process for each mode, and (v) recommend and test the default protection action(s) associated with the framework.

An additional goal of the qualification process may be to identify configurable options in the framework under test in order to specify which vulnerability related data was captured.

Compatibility Matrix Workflows

As part of new onboarding activity, not only do new frameworks get added into the compatibility matrix, but the corresponding instrumentation and rollback scripts, performance impact and default protection action script(s) get identified.

It is also possible that some aspects of instrumentation may not work on a given framework when used in a specific configuration or in process instrumentation mode. This information is captured in the compatibility matrix. The matrix is a working document and, therefore, it is able to reflect cases in which an instrumentation aspect was not working on a given day, but was working again on another given day. As a result, the ACM reads the compatibility matrix prior to provisioning to obtain the correct instrumentation or rollback mode and the appropriate vulnerability protection profile for a given application.

ACM Server—ATE Communication Channel

The ACM server or the ATE can trigger events indicating some activity must be performed at the other end. When the messages are flowing from the ACM to the ATE, the ATE can leverage one or more .csv files it generates as part of a full scan. An example of a message like this is “Discover Web Framework(s).”

When the ATE dispatches messages to the ACM, it either responds to a previously asked ACM request or an asynchronous event at the workload. An example of a previously asked ACM request would be “Discover Web Framework(s).” An example of an asynchronous event would be a “New Workload Registration” message.

In either scenario, the sender will maintain a current state and last sent message type and timestamp to facilitate debugging.

Three communication databases may be maintained by the solution provider and leveraged by users. These databases include (i) ML (training and qualification) database, (ii) CVE (NVD-CPE, CVE-Package, CVE-Executable-ACP, MITRE ACP Policies) databases, and (iii) compatibility matrix. In addition to these databases, the solution provider can also release a new version of an OS-dependent ATE-ML package. These databases and packages may be uploaded in Exavault (or other repository manager) from where the customer's local file repository (LFR) syncs periodically.

Packages are meant for use by customer IT, but the databases are meant for use by the ACM Server infrastructure. The databases are incremental in nature and can be updated by the solution provider at an arbitrary frequency. Therefore, the workflow involves (i) the LFR detecting that a new update has arrived, (ii) the LFR informing the ACM of the arrival, and (iii) the ACM leveraging appropriate scripts to insert the appropriate differential database into the cumulative database for the ACM server to leverage.

For the above purpose, the LFR-ACM communications path may be a Client-Server TCP based IPC communications path. The LFR acts as the client while the ACM server is the server. The messaging channel is described in the section below.

As new applications get created, updated, or deleted, the ACM needs to communicate with the CMS and update the provisioning databases in the CMS. The CMS offers a plurality of APIs that are used for this purpose. Provisioning is different for host, web and binary Frameworks. Provisioning not only describes how to setup/tear down an application, but also involves setting up a vulnerability profile, setting up protection actions, and SecOps users. Currently, there is no need for the CMS to communicate with the ACM; therefore, the communication is implemented in one direction only.

Interpreted and Binary Framework Discovery

FIG. 8Ais a flow diagram showing an example workflow801afor discovery of interpreted frameworks. The workflow801abegins with a solution898-01configured to search a cloud service898-02, an orchestration platform898-03, and a management platform898-04. The cloud service898-02, interfaces with shared services898-05and various workloads898-06a,898-06b, and898-06c. The workloads898-06a,898-06b,898-06cmay interface with an associated EDR898-07and APM898-08. The workloads898-06a,898-06b,898-06cmay interface with associated application server(s)898-09, API server(s)898-10, web server(s)898-11, database server(s)898-12, binary server(s)898-13, and operating system server(s) or service(s)898-14. Application servers may be searched by the solution898-01for framework details898-15. Such framework details898-15include architecture diagrams898-16, a web connector898-17, database connector898-18, configuration options898-19, framework libraries898-20, server runtime898-21, language898-22, version898-23, and name898-24. Version898-25may be determined by do-no-harm (DNH) tests898-25depending upon a version898-26of the solution898-01. Such DNH tests may be performed by a qualification team member898-27of a solution provider. Such DNH tests898-25may influence service(s)898-28to stop898-29or start898-30a script, or otherwise control aspects of processes898-31such as analysis engine mode898-32, vulnerability profile898-33, network ports898-34, FSM898-35, rollback scripts898-36, instrumentation scripts898-37, and a process mode898-38. A vulnerability profile898-33may define protection actions898-39.

FIG. 8Bis a flow diagram showing an example workflow801bfor discovery of binary frameworks. A network environment may be evaluated for such binary frameworks in a manner similar to that described by the interpreted software framework discovery workflow801aintroduced hereinabove and depicted inFIG. 8A, but for omission of APM898-08, application server(s)898-09, API server(s)898-10, database connector898-18, framework libraries898-20, server runtime898-21, language898-22, and in control of services898-28such as stopping898-29and starting a898-30scripts based upon results of DNH tests898-25. Accordingly, framework details898-15, virtual details898-41, and compute details898-48depend upon web servers898-11.

Computer and Network Operating Environment

FIG. 9illustrates a computer network or similar digital processing environment in which embodiments of the present disclosure may be implemented.

Client computer(s)/devices50and server computer(s)60provide processing, storage, and input/output devices executing application programs and the like. The client computer(s)/devices50can also be linked through communications network70to other computing devices, including other client devices/processes50and server computer(s)60. The communications network70can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, local area or wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth®, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable.

FIG. 10is a diagram of an example internal structure of a computer (e.g., client processor/device50or server computers60) in the computer system ofFIG. 9. Each computer50,60contains a system bus79, where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. The system bus79is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to the system bus79is an I/O device interface82for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer50,60. A network interface86allows the computer to connect to various other devices attached to a network (e.g., network70ofFIG. 9). Memory90provides volatile storage for computer software instructions92(shown inFIG. 10as computer software instructions92A and92B) and data94used to implement an embodiment of the present disclosure. Disk storage95provides non-volatile storage for computer software instructions92and data94used to implement an embodiment of the present disclosure. A central processor unit84is also attached to the system bus79and provides for the execution of computer instructions.

Embodiments or aspects thereof may be implemented in the form of hardware including but not limited to hardware circuitry, firmware, or software. If implemented in software, the software may be stored on any non-transient computer readable medium that is configured to enable a processor to load the software or subsets of instructions thereof. The processor then executes the instructions and is configured to operate or cause an apparatus to operate in a manner as described herein.

Further, hardware, firmware, software, routines, or instructions may be described herein as performing certain actions and/or functions of the data processors. However, it should be appreciated that such descriptions contained herein are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.

It should be understood that the flow diagrams, block diagrams, and network diagrams may include more or fewer elements, be arranged differently, or be represented differently. But it further should be understood that certain implementations may dictate the block and network diagrams and the number of block and network diagrams illustrating the execution of the embodiments be implemented in a particular way.

Accordingly, further embodiments may also be implemented in a variety of computer architectures, physical, virtual, cloud computers, and/or some combination thereof, and, thus, the data processors described herein are intended for purposes of illustration only and not as a limitation of the embodiments.