Patent Description:
Organizations are increasingly challenged in their ability to gather, store and query information regarding their ever-evolving technology assets. In this innovation, a technology asset is described broadly as a digital item of value owned [or leased from a third party]; including physical, virtual, mobile, cloud, industrial or data itself. Such technology assets may include, but are not limited to desktop computer systems, physical technology hardware, applications, software containers, databases, cloud services, microservices, industrial control systems, loT devices, workloads, user identity data, network domains, virtual servers, machine learning models, or a repository of data, binaries or source code supporting a specific business function. This challenge is amplified by the rapid evolution of information technology systems, both in their nature and applications within public and private sector organizations.

Significant business risks arise when a company is not able to understand the volume and nature of its technology assets, including digital assets. The proliferation of technologies such as <NUM>, cloud computing and rapid pivot to digital business increases the need for and complexity of understanding those assets. Companies are currently adopting enabling and cost saving technologies, e.g., artificial intelligence, business process automation technologies and machine learning. However, adopting these technologies will not be successful without a reliable understanding of a company's assets. Further, increasingly aggressive regulations require keeping an accurate ledger of technology assets. <CIT> discloses a method of processing data in a distributed computing system, and such distributed computer system.

One embodiment of the invention is directed to a system with the features prescribed by claim <NUM>.

One embodiment of the invention is directed to a method with the features according to claim <NUM>.

One embodiment of the invention is directed to a non-transitory computer readable storage device with the features according to claim <NUM>. BRIEF DESCRIPTION OF THE.

As discussed in detail below, embodiments are directed to a system, method and computer program of providing a "single source of truth" or "system of record", articulating what technology assets an organization has and providing adjacent information, such as what their business value is, what they do (function), where they are (for example in a public cloud), and their relationships with other assets, has a broad number of possible uses in an organization. This information can be used to focus on individual or small groups of assets, or in aggregate form to drive use-cases such understanding the overall "attack surface" of an organization. Such uses and challenges solved herein include, but are not limited to:.

Timely identification of previously unknown business risks, such as the presence of unidentified end of life systems being utilized for critical business functions.

The high costs associated with previous asset inventory/management solutions due to a lack of automation and inability to keep up with the base of technological change in today's modern enterprise. Cost saving technologies, leveraging automation and machine learning that currently do not meet their potential, due to a lack of reliable sources of asset information. Such an example is the ability to implement security orchestration, automation and response (SOAR) technologies that take the nature of an impacted asset into consideration.

Some features of the system, method and computer program are as follows. These may be utilized together, or individually.

An overview of a system <NUM> is shown in <FIG>. The system <NUM> may include a database <NUM> and circuitry <NUM> coupled to different technology systems <NUM> on a technology network and in communication with the database <NUM>, e.g., via technology connectors <NUM>. In particular, the circuitry <NUM> may include event processing circuitry <NUM> for processing event data from the technology connectors <NUM> and update the database <NUM> accordingly and interface circuitry <NUM> for providing a user interface for users <NUM> to query and access the database <NUM>.

Circuitry <NUM> may be configured via the execution of computer readable instructions, and the circuitry may include one or more local processors (e.g., CPU's), and/or one or more remote processors, such as a cloud computing resource, or any combination thereof. Embodiments discussed herein can be implemented in suitable instructions that may reside on a non-transitory computer readable medium, hardware circuitry or the like, or any combination and that may be translatable by one or more server machines. The present technology can be configured as a form of cloud computing in which one function is shared in cooperation for processing among a plurality of devices via a network. Also, the present technology can be configured as a form of a server or IP converter in a location in which one function is shared in cooperation for processing among a plurality of devices via a network.

In order to store and later retrieve the relationships between asset entities, a graph database, which allows the creation of multiple edges between records or nodes, may be used. Edges may carry weighting values, to indicate values such as the strength of a relationship between nodes representing technology assets. The graph database also allows for the storage of properties of the technology assets for later search and retrieval. The graph database treats relationships between data as important as the data itself. This allows for the weighting of edges, representing factors such as the confidence the system has in a given relationship. Edges between nodes representing technology assets may also be created through predictions, not only direct observations.

The edges between nodes themselves can be used for a plurality of purposes, including but not limited to:.

The use of the database enables a plurality of technologies (including but not limited to mobile devices, servers, workstations, cloud systems, cyber security technologies, telecommunications devices, satellite assets, industrial control systems) to:.

Some examples showcasing the simplicity of a graph query based DSL:.

The equivalent SQL would typically involve at least two joins and multiple filters and the complexity increases with more hops added to query.

The system for gathering and processing technology asset intelligence is capable of querying a multitude of technology systems within an organization, normalizing that information, enriching where appropriate and storing it in a database, which may be queried for a plurality of use cases, to include cyber security decision making (such as security automation and orchestration), financial systems, business asset tracking, mergers and acquisitions due-diligence activities, industrial control operations, business risk assessments and complying with a plurality of IT and non-IT regulatory requirements which the end-user may be subject to.

To gather this information, the system includes a series of technology integrations, utilized for querying a plurality of technologies, to retrieve asset data, understand their and other assets properties and other attributes concerning themselves and peer assets. The nature of the integration and the data it yields can significantly vary and may include multiple asset data types from a given integration. For example, a single integration to an endpoint management technology, could yield system asset data, user asset data and application asset data.

The breadth of integrations and respective asset data includes but is not limited to, integration with industrial control systems (such as programmable logic controllers and data historian systems), cyber security technologies, enterprise technology systems, operating systems, databases, cloud provider APIs, digital identity and access management systems and source code repositories.

These integrations are designed with a detailed understanding of the underlying technology being interfaced to such that translation between what that external system reports and the asset data models can be made.

Through a similar mechanism, the system may also identify the presence of a technology in the deployed environment, even though full information about where and how the technology is utilized is not known. For example, a finance system may report the procurement of a particular technology, indicating that technology from that vendor is, or is planned to be, deployed into the environment.

Through the processing of data from technology integrations (as noted above), the system may take note that a technology asset has been referenced (or "mentioned") in metadata processed by the system. This is similar to the way in which a social network works; however, mentioning technology assets, instead of people. As an example, the system may include a technology integration with a source code repository. Through this integration, the system may identify references to technology assets embedded within pragmatic code stored in the repository. Such a reference could include, but is not limited to, programmatic instructions defining database connection strings, which would generally comprise of an IPv4 or IPv6 address, or fully qualified hostname (or FQDN). Once a mention is identified, a relationship with the asset nodes in question is created. This is implemented through the creation of a database record, such as the creation of an edge between two or more asset nodes in a graph database.

As an example of this feature in action, a graph <NUM> in <FIG> has asset nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> representing technology assets and edges <NUM>, <NUM>, and <NUM> that indicate relationships between the asset nodes. As may be seen therein, a Customer Banking asset node <NUM> which has been previously discovered is not related to the other nodes, i.e., the Customer Banking application asset node <NUM> has no attribution or edges to an organization or context in terms of where the application is utilized in an organization. The Customer Banking application asset node <NUM> has not been mentioned and therefore lacks context. Providing this context is important for organizations as they seek to understand assets in their environment.

Continuing this example, <FIG> illustrates an intake process <NUM>. When an inbound event is received from a technology integration as discussed above at operation <NUM>, here from a source code repository connector, the system ingests the inbound event in operation <NUM> and extracts relevant information (in this example, a username tied to the author of the Customer Banking application and a database connection record found within the source code data) in operation <NUM>.

Through the ingestion of the above event, the processor may establish the following relationships.

Depending on the type of ingestion event and nature of the technology that generated the ingestion event, different relationships may be established.

In practice, this is implemented through the creation edges between nodes in a graph database based on the relationships established by the intake process <NUM>. The resultant data is visualized in a graph <NUM>' shown <FIG>. In particular, the updated graph <NUM>' now includes edges or relationships <NUM> between node <NUM> and node <NUM> (determined from (<NUM>)), edge <NUM> between node <NUM> and node <NUM> (determined from (<NUM>)), and edge <NUM> between node <NUM> and node <NUM> (determined from (<NUM>)). This shows how the system can be used to bring immediate, previously unknown context to an application asset and user asset.

While in this example, the system leveraged existing graph data with event data from software source code, the same process could be applied to a plurality of asset types and events generated by a plurality of events from the technology integrations described above.

The system can automatically, at scale, determine how best to treat event data, with a view to maximizing the value of a given data source, allowing for real-time or historical analytics of asset data, while reducing noise in the graph, through ensuring that data is appropriately ingested and the graph properly updated.

First, the system ingests a plurality of data elements to identify the presence of a possible asset in a technology environment (such as a network). Such data elements may include, but are not limited to, system logs, firewall logs, netflow information, endpoint data, user access logs, network device routing and state tables and packet capture metadata. These plurality of data elements may indicate the existence of a possible asset in the environment without necessarily revealing many details of attributes of the asset itself. For the purposes of this system, we term this as low fidelity data. While low fidelity may not provide sufficient information for many end user use-cases of the system, the identification of the presence of the asset in the environment carries some value. Other data contained in ingestion events, with a higher fidelity level, may be used to build more complete database records concerning that asset. Regardless of the fidelity of the data in the ingested event, it may be used to either create new asset records, enrich existing asset records, establish relationships, or perform other operations in the system.

Second, the system consumes the data elements contained within the ingestion event and performs analysis of them with asset data contained within the system, for a plurality of purposes, including: (<NUM>) establishing whether the ingested event data, relates to an existing asset record or records within the asset inventory. This process is aimed at posing a binary (yes/no) question, whose answer can be used to identify a number of factors; and (<NUM>) performing analysis of data ingested through the first and second methods, to create confidence statistics regarding the completeness of data concerning a particular asset. While the existence of record is a binary (yes/no), to what extent the record matches the data element is not. When a match between the data element and a record in the existing asset inventory equals or exceeds a first threshold, the data element may be used to enhance the record. When a match between the data element and the record is less than a second predetermined threshold, which is less than or equal to the first predetermined threshold, a new asset may be created in the database. When a match between the data element and the record is between the first and second thresholds, additional policies may be used to determine how to treat the data element and other thresholds may be applied with the first and second threshold to make this determination.

This is achieved through an ingest policy. The policy applies a set of rules, to determine the treatment of data elements contained within an event. The policy itself may be either statically created, or dynamically created and/or tuned through secondary analytics, leveraging technologies such as machine learning, to continually tune and improve the policy - reducing false positives, false negatives and therefore improving the handling of data ingested into the database.

When leveraging the rules, the policy engine will broadly conduct a series of steps. An example of the processing of such a policy, is illustrated in <FIG>:.

The system <NUM> may leverage caching or bloom filters to improve the performance of steps taken in <NUM>, <NUM> and <NUM>.

<FIG> illustrates an overall flowchart for generating an inbound event and then processing the inbound event by the circuitry <NUM>. Before an inbound event is received by the circuitry <NUM>, in operation <NUM>, one or more information sources sends event data to be subject to technology integration in operation <NUM>. The circuitry <NUM> receives the inbound event from the technology integration and, in operation <NUM>, the inbound event is ingested (see <FIG> and <FIG>). In operation <NUM>, the identity of the data type is determined, e.g., data element, technology asset, etc. The data is then extracted in operation <NUM> (see <FIG> and <FIG>). Operation <NUM> searches the database <NUM> for correspondence with records in the database <NUM> in accordance with an appropriate policy (see <FIG> and <NUM>-<NUM> in <FIG>). Once correspondence is found, operation <NUM> updates the database <NUM> to manipulate a relationship between the technology asset and the record in the database <NUM> (<FIG>), enrich the record if a match exceeds a first predetermined threshold (see <NUM> and <NUM> in <FIG>), create an asset if a match is below a second predetermined threshold and there is sufficient data (see <NUM> and <NUM> in <FIG>), store an orphan record if there is insufficient data (see <NUM> and <NUM> of <FIG>), and/or proceed to further processing in operation <NUM>. The flow may further include storing raw event data in operation <NUM>, which may be further processed in operation <NUM>.

The system <NUM> may represent asset information through a series of visualizations. The goal is to display data pertaining to a given asset or plurality of assets, showing the relationships and optionally the strength of those relationships between assets. A given visualization may vary given the end use-case. Broadly speaking, visualizations may be broken down into two categories.

First, when viewing a large amount of asset data, indicating trends in a technology environment or environments. This is not too dissimilar from a heat-map type concept, except the data may be more easily explored. Such an example of how this method may be applied, includes providing the end user with an understanding of how server operating system versions are distributed across an environment of a technology environment. This example is helpful both tactically and strategically, to enable and take action on a server upgrade effort.

Second, those that are focused on a small grouping of technology assets as a starting point. The system would typically be interacted with to further explore and expand the graph visualization to provide further context around the assets of particular interest to the user. Such an example of how this method may be applied, includes searching the database for a user asset, based on a username. The visualization may then simply render a node representing that user, which may be interacted with to expand relationships (or edges) connecting that user to other assets in the database, such as associated system assets, applications, or organizations.

In <FIG>, a graph <NUM> includes technology asset nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, a group node <NUM>, and edges <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. For example, the node <NUM> with the IPv4 address <NUM>. <NUM> with a number of secondary nodal attributes, identifying pertinent information about the technology asset, including an observed relationship with a secondary node, with the IP address of <NUM>. This graphical user interface may be interacted with, to further explore information regarding this and other assets. Such an interaction may include clicking on a node, or information bubble regarding an asset, to "expand" the visual graph. As shown in <FIG>, each asset note may include an icon indicating a type of node, a count of related nodes, and an identifier of an asset. Each group node may include a group name and a count of relates nodes.

These nodes may be interacted with in a variety of manners. For example, selecting the node <NUM> with the IPv4 address <NUM>. <NUM> may result in a details screen <NUM> of <FIG>, in which additional details of the node may be viewed, along with a subset of the graph of <FIG>, e.g., only immediately connected nodes, i.e., nodes <NUM> and <NUM>, in a window <NUM>. The screen <NUM> may also include a window <NUM> displaying particular asset detail, a window <NUM>, displaying further asset details, a window <NUM> displaying a key score identifying the asset, a window <NUM> displaying a secondary score identifying the asset, a window <NUM> displaying relevant history of the asset, and window <NUM> displaying related assets.

Asset data and derived information (such as analytics or visual representations) contained within the described system, may be extended and used for a plurality of purposes, leveraged by secondary applications which are purpose built to leverage the system described, e.g., to provide additional security or visualization functionality. Such applications may be installed (enabled) and disabled, as modular "add-ons" into the system, and may be contributed by a community of developers (i.e., an app-store-like environment), e.g., third party developers. As shown in a high-level depiction in <FIG>, a platform architecture <NUM> may include a core platform <NUM>, asset data <NUM>, and a data ingest and analytics of the system <NUM>, a platform application <NUM>. Platform applications <NUM> can subscribe to and publish data from/into the core platform <NUM> in order to extend functionality of the system <NUM>. Such an application installed into the system could include a Technology Transformation "app", leveraging data from the system, to inform an end-user how a technology migration (such as a move to Cloud computing) may be best approached, or identifying opportunities for technology cost savings through rationalization of technologies, described by the database system.

The system <NUM> can determine a likely utility type of a system asset. Such utility types may include, but are not limited to, technical utility (ex. Server, Workstation, Mobile Device) and business-level utility (e.g., a server involved in finance reporting; a web server responsible for a customer web application) etc..

In order to establish a likely asset utility type, the system performs analysis of event data and existing database edge relationships, derived from multiple sources including, but not limited to, user access events and behaviors, user identity directory data, application-level data, system and application access data, source code, asset and organization information.

In <FIG>, a graph <NUM> includes nodes <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, and edges <NUM>, <NUM>, <NUM>, <NUM> between nodes. The system asset <NUM> may run on a cloud server <NUM>. The user assets <NUM>, <NUM>, <NUM>, and <NUM> have been found to authenticate to the organization node <NUM> to which those user assets belong and as the party financially responsible for the infrastructure the asset <NUM> was launched on are shown. No single data source provides the entire body of relationships required to ascribe the utility type of an asset. In this example, data from multiple connectors are used to build the edges in the graph that allows determination of the organization ultimately utilizing an asset. From this graph <NUM>, this system asset <NUM> is owned by the Finance organization <NUM> primarily for running financial software used by their users for business operations and reporting purposes, i.e., an edge <NUM> between node <NUM> and node <NUM>, can be inferred with high confidence, i.e., a confidence level for this edge exceeds a predetermined level.

Claim 1:
A system (<NUM>), comprising:
circuitry (<NUM>) coupled to different technology systems (<NUM>) on a technology network; and
a database (<NUM>) storing a new or existing inventory of technology assets in the technology network and coupled to the circuitry (<NUM>), wherein the circuitry (<NUM>) is configured to:
ingest an inbound event from one of the different technology systems (<NUM>);
extract at least one data element from the inbound event or at least one technology asset from the inbound event;
search the database (<NUM>) with respect to the at least one data element or the at least one technology asset; and
determine a correspondence between the at least one data element or the at least one technology asset and at least one record in the existing inventory;
wherein, on condition that the at least one technology asset is extracted, create a relationship between the at least one technology asset and the at least one record in the database (<NUM>),
wherein, on condition that the at least one data element is extracted, determine a match between the at least one data element and the at least one record in the existing inventory,
on condition that the match equals or exceeds a first predetermined threshold, enrich the at least one record in the database (<NUM>),
on condition that the match is less than a second predetermined threshold, create a new asset in the database (<NUM>),
determine whether there is sufficient data to create a new technology asset, in accordance with a rule set read from policy parameters, wherein the rule set is specific to a technology that was responsible for creating the data element found within the inbound event,
on condition that the match is less than a second predetermined threshold, wherein an extent to which the second predetermined threshold matches the data element is less than the extent to which the first predetermined threshold matches the data element, and that the at least one data element has sufficient data to create the new technology asset, create the new technology asset in the database (<NUM>),
on condition that the at least one data element does not have sufficient data to create the new technology asset, in accordance with the policy read from the predetermined policy parameters (<NUM>), creating an orphan record in the database (<NUM>).