Asset relationship system and method

Abstract

An asset relationship system and method store assets and related data for the asset so that it can be queried. In one embodiment, the asset and the related data may be stored in a graph database in which each node in the graph database stores a piece of asset data and each edge in the graph database encodes a relationship between the two nodes / piece of asset data to which it is connected.

Description

ASSET RELATIONSHIP SYSTEM AND METHOD

[0001] The disclosure relates generally to managing Information Technology (IT) assets and in particular to determining and storing relationships between related IT asset pieces of data.

[0002] When working with or trouble shooting an issue for an Information Technology (IT) or internet protocol (IP) system or network or environment, each piece of information / data about an asset can be extremely valuable and useful to an analyst. An asset may be a computer, a server, a laptop computer, a user, etc. that are part of the IT or IP system being worked on or troubleshooted by the analyst. Each asset has a plurality of pieces of data that define various aspects / characteristics of the asset or the relationship of the asset to other assets.

[0003] Only having one piece of "asset information" available at any given time could make it more difficult to see the full picture about that asset. For example, an analyst might know that a computer with hostname "firewall_wa_02" is expected to be offline due to maintenance, but then some other system generates and sends a warning that "firewall 10.7.5.2" also has gone offline. The analyst based on the hostname information alone cannot determine, for example, that "firewall_wa_02" is the same computer as "firewall 10.7.5.2." An asset relationship system and method that was able to associate / relate the pieces of asset information for an asset to each other would be very helpful and desirable and would, in the example above, allow the analyst to determine that "firewall_wa_02" is in fact the same computer as "firewall 10.7.5.2".

[0004] Thus, it is desirable to provide an asset relationship system and method and it is to this end that the disclosure is directed.

[0005] According to at least one aspect of embodiments, an asset database apparatus, includes:

[0006] a graph database having a plurality of nodes wherein each node represents a piece of data about an asset and a plurality of edges wherein each edge represents a relationship between two nodes that each contain a piece of data about the same asset;

[0007] an asset manager connected to the graph database that manages access to the graph database, adds or deletes asset data stored in the graph database and enforces a time to live for each piece of data for an asset stored in the graph database; and

[0008] an asset relationship application programming interface (API) by which a user may access the asset manager.

[0009] Figure 1 illustrates an example of an asset relationship system;Figure 2 illustrates a method for adding a new asset to an asset relationship storage;Figure 3 illustrates an example of asset with relationships stored in the asset relationship storage;Figure 4 illustrates more details for adding a node;Figure 5 illustrates more details of looking up an asset;Figure 6 illustrates more details of deleting the asset;Figure 7 illustrates a process of confirming that the deleted asset is no longer viewable in the system;Figure 8 illustrates a display of the related assets in the asset relationship storage;Figure 9 illustrates an example of JSON code with the related assets;Figure 10 is an example of a user interface and code for getting nodes / assets from the asset relationship storage;Figure 11 is an example of a user interface and code for getting nodes / assets from the asset relationship storage;Figure 12 is an example of a user interface and code for getting edges / relationships from the asset relationship storage; andFigure 13 is an example of a user interface and code for getting edges / relationships from the asset relationship storage; andFigure 14 illustrates an example of the assets and their relationships displayed in a graph database user interface.

[0010] The disclosure is particularly applicable to an asset relationship system and method for IT / IP (Information Technology / Internet Protocol) assets that uses a graph database and it is in this context that the disclosure will be described. It will be appreciated, however, that the system and method has greater utility since the system and method can used to discover and store other types of assets and their relationships to other assets. Furthermore, the system and method may use other types of storage than the graph database to store the set of related assets. In the example below, the internet protocol (IP) assets may be a hostname, a IP address, a network, a piece of software and a username. One skilled in the art would understand that additional or fewer assets may be used by the system within the scope of the disclosure.

[0011] In addition to using the system by an analyst to diagnose / address an IT asset issue, the asset relationship system and method may be used to make sure software is up to date. For example, an administrator could make a request for all hosts which have "softwareX" installed, and then have the version of that software as a tag, and then loop over the results and print out all hosts which are not on a given version. Thus, when there is a new vulnerability, the administrator / user could have an overview of what hosts might be vulnerable, see if there is any pattern (maybe you have added "location" as a tag), and then see that all the systems are vulnerable in department X or Y, or in Spain.

[0012] Figure 1 illustrates an example of an asset relationship system 100 that has been implemented using an application programming interface (API) type architecture. It should be understood, however, that the system and method may be implemented in other manners, methods or architectures that are all within the scope of the disclosure. The system 100 may have one or more computing devices 120 that may use a connection 140 to access an asset relationship application programming interface (API) 160A in a backend computer 160. Each computing device 120 may be used by a user to submit a request for related information for a particular asset through the API 160A and an asset manager 160B may return the related information for the asset to the user using the API 160A. For example, in the IP asset example, the user may submit a hostname of a computer that is an IP asset and the system 100 may return, to the user, one or more of an IP address, network, software and username related to the particular IP asset. The API 160A may be a plurality of lines of code / instructions executed by a processor of the backend computer 160 that handle validation of inputs, determining an appropriate database based on the request and a look up of the pieces of data for the asset in the graph database.

[0013] The one or more computing devices 120 may be various types of computers such as a desktop computer or terminal 120A, a smartphone device 120B, such as an Apple(r) iPhone(r) or an Android(r) based operating system device, a laptop 120C and / or a tablet computer 120N or any other computer that is capable of interacting with the API 160A. Each computing device 120 may have at least one processor, memory, wireless or wired communication circuits and a display. Each computing device 120 may have a well known browser application or other application that is a plurality of lines of instructions / computer code that are executed by the processor to interface with the API 160A.

[0014] The connection 140 may be a wired and / or a wireless connection that has a connection protocol, such as TCP / IP, and a data / communications protocol, such as the Simple Object Access Protocol (SOAP), Remote Procedure Call (RPC), Representational State Transfer (REST), etc. to access the API 160A. For example, the connection 140 may be one or more of a wired network, a wireless network, a cellular data network, a computer data network and the like.

[0015] The backend 160 may be one or more computer systems implemented using one or more computing resources such as cloud computing resources (Amazon(r) AWS(r) or Microsoft(r) Azure(r)), a server computer, a blade server, an application server, a database server and the like. The backend 160 may include at least one or more processors and a memory. As described above, the backend 160 may support the asset relationship API 160A and exchange data with the API 160A and also hosts / has the asset manager 160B that manages the asset data and interfaces with the asset storage 180 that may be a hardware or software storage and may be a database and more specifically, in one embodiment, a graph database. The API 160A and the asset manager 160B may be implemented using a plurality of lines of computer code / instructions stored in the memory of the backend 160 and executed by the processor of the backend 160 to configure the processor to perform the processes of the asset manager 160B and / or the API 160A. The asset manager 160B may manage the asset information for each asset and may include processes to add a new asset, to add a new piece of asset information related to an already stored asset, to remove an asset or its information and / or to perform a garbage removal process that removes assets whose time in the storage 180 exceeds a time to life (TTL) threshold as described in more detail below. The asset manager 160B may also enforce and assign the TTL to each asset or piece of data for an asset.

[0016] The asset manager 160B may further include (not shown in Figure 1) one or more artificial intelligence modules / elements, such as an large language model appropriately trained for the asset data and connected to the storage, that could be used as a chatbot / agent to answer user questions about the asset data. For example, a system of the asset relationship system that lists each or all of the assets may be then able to respond to questions such as "what network(s) are potential guest networks?" or "what network has the most outdated software?".

[0017] The asset storage 180 in Figure 1 may be a graph database and may have one or more nodes and one or more edges that connect the one or more nodes to each other. Each node of the graph database may store data about a particular asset. Each edge in the graph database may be used to connect two or more nodes to each other wherein the two or more nodes have a relationship with each other such as two or more asset characteristics / variables of an asset as discussed in this disclosure. Thus, each edge encodes a relationship between the two nodes connected by the edge. Note that a node for a new asset may also be added to the asset storage 180.

[0018] Thus, as shown in Figure 1, the system may have one or more users / actors / components / modules that would add data from an arbitrary or other system (as discussed below) into the asset relationship system. One or more users (using each device 120 and the asset relationship API 160A) could then retrieve the data about a queried asset.

[0019] In a preferred implementation, the API 160A may be written in golang, using a web framework called "gin". The data may be written into and stored in a commercially available graph database "arangoDB". The backend 160 may run in kubernetes in Azure, but the backend 160 could also be hosted locally. In the IP asset example, the type of assets may be "ip", "hostname", "username", "software" and "network" and the list of assets may be expanded. For a different type of asset, there may be a different set of asset characteristics as would be understood by those skilled in the art.

[0020] Figure 2 illustrates a method 200 for adding a new asset to the asset relationship storage. The method 200 may be implemented by the system shown in Figure 1 including the asset manager 160B and storage 180, but may be implemented in other manners that are within the scope of the disclosure. For illustration, the method is described in the context of IP assets, but the method may be performed on various different assets. A request to add a new asset (202), such as an IP asset, is received to add a new asset into the storage. A set of validations (204) may be performed for each different type of API call. For example, all endpoints where you add nodes perform checks so that a "customer", a "type" and a "value" are set, but there might be additional validations. For example, if the "type" is a network, there may be additional validations to confirm, for example, that the value in this field should be a valid classless inter-domain routing (CIDR) value.

[0021] The method may then determine if the new asset has successfully passed (206) the validation(s). If the new asset passes the validations, the new asset may be stored (208) in a storage, such as the storage 180 that may be preferably be a software and hardware implemented graph database. If the storage 180 is a graph database, then a new node in the graph database is created for the new asset. When the new asset is stored, it may be assigned a time to leave (TTL) value as described below. If the new asset does not pass the validation(s), the user (210) who submitted the request to add the asset is notified that the new asset is not being stored. For example, if an API request is submitted to an endpoint that add both nodes and edges between two or more items, but the request only includes one item, the storage may respond that "Item2 must have a type / value" since Item2 is missing from the request made.

[0022] In addition to the process described above, the asset manager 160B may implement a process by which a user can modify a prior request. For example, if a user requests to add a new asset and then later discovers that this newly added asset is related to a different asset already stored in the graph database, the asset manager 160B provides a process to relate those assets. Specifically, the asset manager 160B may have a process to add an edge or edges in the graph database (relationship between nodes). Thus, for example, if a user discovers that the asset identified by IP address 123.123.123.123 is related to asset hostname "myhost", the user may make a request to add the edge between the two assets that indicates that the IP address and the hostname are related and are pieces of data about the same asset.

[0023] Figure 3 illustrates an example of an asset with relationships 300 stored in the asset relationship storage such as the storage 180 in Figure 1. In one implementation, the asset with relationships 300 may be stored in a graph database in which each endpoint in the graph database may be an asset characteristic / variable and each edge in the graph database may be a relationship between the asset characteristics / variable. For an IP asset example, the 10.10.7.171 IP address asset may be related to a "software" zoom, the "username" tim and the network "10.10.7.0 / 22". Similarly a "firewall_wa_02" hostname may be related to a 192.168.2.6 IP address. An example of graph (from the arango UI) when adding 3 assets to the IP 10.10.7.171 are shown in Figure 3.

[0024] Thus, when a user queries the asset relationship system 100 for the 10.10.7.171 IP address asset, the other related asset characteristics / variables may be returned to the user, such as an analyst, who is better able to troubleshoot the IP asset situation based on the asset and each of the other related IP asset characteristics / variables.

[0025] The asset relationship system may have a method for loading assets and relationships in the asset relationship store when a new asset or a new asset variable that has a relationship to an asset already stored in the asset relationship store is received by the system. This ensures that the asset relationship system "learns" about each asset and can thus provide more related asset characteristics / variables over time for an asset requested by a user. The additional related asset characteristics / variables for an asset may make the user's task easier.

[0026] In order to ensure that the asset storage does not contain older and likely irrelevant data about an asset or asset characteristics / variables, the asset relationship system may purge older assets after a predetermined time. For example, older assets (and the older asset related characteristics / variables) may be purged once a time to live (TTL) for the asset has expired. In one embodiment, the TTL may be seven days which is a default setting. In one embodiment, the same TTL may be applied to all types, but the TTL is configurable. (Method of Loading Assets / Relationships)

[0027] The loading of each asset or new asset characteristic / variable may be done via an application programming interface (API) of the asset storage. For example, the commercially available graph database being used in one embodiment of the system may have an API that is used to load the asset or new asset characteristic / variable into the database. Alternatively, a developer could create a "module" of the asset manager 160B to retrieve data from a given other system that is a source of asset data and use the API to insert the retrieved data to the database. The other system (from which data may be retrieved by the module) may be various data sources, such as, for example, a log management system, an endpoint detection and response (EDR) product, by doing active scanning of the network, etc. in a well known manner. The use of the module that retrieves data from other system means that the asset relationship system can add new assets or new characteristics / variables of existing assets independent or in addition to the asset data that may be gathered by the system as a result of the queries made by each user. Each new asset in the graph database becomes a new node in the graph database.

[0028] The process to add an edge to relate two characteristics / variable of an asset may be performed when a user requests to "draw a line from A to B" (add an edge) via the API. When a new asset is to be added, the API 160A and manager 160B checks that the required data exists (e.g., the customer is specified, a database exists for the customer and the customer is authorized to edit the database and / or the data is valid). (Method of Removing Assets)

[0029] In one embodiment, the assets may be automatically removed once the TTL has been exceeded for that asset. In addition, the asset manager 106B may also implement a method to remove an asset before reaching the TTL for the asset. In one embodiment, the removal may be performed using a DELETE request of the commercially available asset storage system. Using the API, an API call can be made to delete an edge or a node. If a node is deleted, the one or more edge(s) connected to that deleted node are not automatically deleted.

[0030] This method may be performed on any asset at any time (not just when the TTL is exceeded). The example method to remove an asset is shown using code shown in the figures for the exemplary "Arango_db" graph database. Figure 4 shows a example "delete_me" hostname asset being created which will then be removed before its TTL has expired. Thus, Figure 4 illustrates one example of a method for removing the asset from the asset relationship storage, but the method for removing the asset may be performed using other techniques that are within the scope of the disclosure. Figure 5 illustrates a process to add a node with hostname "delete_me" into the asset database. Figure 6 illustrates the API call to delete the asset added in Figure 5. Figure 7 is a sequence of code showing that a subsequent search for the node "delete_me" does not return any results.

[0031] Figure 8 illustrates a display 800 of the related assets in the asset relationship storage. In the example in Figure 8, a hostname 802 has a value shown in Figure 8 that is a first piece of information about that asset. As shown in Figure 8, there may be one or more tags 804 associated with the original piece of asset data (the hostname is this example) that contain additional pieces of data (such as asset source, last external IP address, status, host based firewall status, current sensor policy name and OS (operating system) and OS version in the example in Figure 8) that may be queried and retrieved from the asset relationship storage. Thus, a user may know the hostname and then retrieve all of the other related data from the asset relationship storage. Alternatively, the user may know a last IP address of an asset and then retrieve the other asset data such as the hostname. The retrieval of the other asset data from the system allows the user to better assess a risk of the asset or connect together two pieces of otherwise unrelated asset data.

[0032] As an example, if a user wanted to know what other types of "assets" are related to the hostname "desktop-49dq0jc" on client "51dd709a-1342-477d-b0ee-1147068dafd2", the user can make a request / query to the graph database such as:

[0033] <BASE_URL> / getnoderelation?customer=51dd709a-1342-477d-b0ee-1147068dafd2&value=desktop-49dq0jc&type=hostname

[0034] This request / query, in one embodiment, returns a list 900 of the asset and its related characteristics (the IP address in this example in Figure 9) that may be in the form of JSON code in one embodiment shown in Figure 9. As shown in Figure 9, the list includes the known asset value (the hostname) other related asset values and relationships.

[0035] Figures 10 -11 are an example of a user interface of the asset storage (Figure 10) and a piece of code (Figure 11) for getting nodes / assets from the asset relationship storage. As shown in this example, note that any type of asset and / or related assets may be stored and related in the system. In the example in Figures 10-11, the asset is a hostname and the tags / related assets may be spiral related assets which are different from the other examples provided herein. Figures 12-13 are an example of a user interface (Figure 12) and code (Figure 13) for getting edges / relationships from the asset relationship storage. Finally, Figure 14 illustrates an example of the assets and their relationships displayed in a graph database user interface. However, it is understood that the asset storage may be any type of storage including databases (software and hardware based), memory and the like and that Arango DB is just one example of a graph database that may be used for the system.

[0036] The system 100 shown in Figure 1 may be a stand alone asset relationship system that may be queried for asset information. Alternatively, authorized third parties may use an application programming interface (API) to request asset data and receive the asset data results back from the system. Furthermore, the asset relationship system may be integrated into other system such as malware detection or tracking systems and other systems. Each of these other systems may have a tool / component / module that can, via an API or other mechanism, reach out to the asset manager 160B to query the asset storage to determine if there is more data available for a given asset to "enrich" the knowledge about the asset for various purposes.

[0037] The foregoing description, for purpose of explanation, has been with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the disclosure and its practical applications, to thereby enable others skilled in the art to best utilize the disclosure and various embodiments with various modifications as are suited to the particular use contemplated.

[0038] The system and method disclosed herein may be implemented via one or more components, systems, servers, appliances, other subcomponents, or distributed between such elements. When implemented as a system, such systems may include and / or involve, inter alia, components such as software modules, general-purpose CPU, RAM, etc. found in general-purpose computers,. In implementations where the innovations reside on a server, such a server may include or involve components such as CPU, RAM, etc., such as those found in general-purpose computers.

[0039] Additionally, the system and method herein may be achieved via implementations with disparate or entirely different software, hardware and / or firmware components, beyond that set forth above. With regard to such other components (e.g., software, processing components, etc.) and / or computer-readable media associated with or embodying the present inventions, for example, aspects of the innovations herein may be implemented consistent with numerous general purpose or special purpose computing systems or configurations. Various exemplary computing systems, environments, and / or configurations that may be suitable for use with the innovations herein may include, but are not limited to: software or other components within or embodied on personal computers, servers or server computing devices such as routing / connectivity components, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, consumer electronic devices, network PCs, other existing computer platforms, distributed computing environments that include one or more of the above systems or devices, etc.

[0040] In some instances, aspects of the system and method may be achieved via or performed by logic and / or logic instructions including program modules, executed in association with such components or circuitry, for example. In general, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein. The inventions may also be practiced in the context of distributed software, computer, or circuit settings where circuitry is connected via communication buses, circuitry or links. In distributed settings, control / instructions may occur from both local and remote computer storage media including memory storage devices.

[0041] The software, circuitry and components herein may also include and / or utilize one or more type of computer readable media. Computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and / or computing components. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and can accessed by computing component. Communication media may comprise computer readable instructions, data structures, program modules and / or other components. Further, communication media may include wired media such as a wired network or direct-wired connection, however no media of any such type herein includes transitory media. Combinations of the any of the above are also included within the scope of computer readable media.

[0042] In the present description, the terms component, module, device, etc. may refer to any type of logical or functional software elements, circuits, blocks and / or processes that may be implemented in a variety of ways. For example, the functions of various circuits and / or blocks can be combined with one another into any other number of modules. Each module may even be implemented as a software program stored on a tangible memory (e.g., random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be read by a central processing unit to implement the functions of the innovations herein. Or, the modules can comprise programming instructions transmitted to a general-purpose computer or to processing / graphics hardware via a transmission carrier wave. Also, the modules can be implemented as hardware logic circuitry implementing the functions encompassed by the innovations herein. Finally, the modules can be implemented using special purpose instructions (SIMD instructions), field programmable logic arrays or any mix thereof which provides the desired level performance and cost.

[0043] As disclosed herein, features consistent with the disclosure may be implemented via computer-hardware, software, and / or firmware. For example, the systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them. Further, while some of the disclosed implementations describe specific hardware components, systems and methods consistent with the innovations herein may be implemented with any combination of hardware, software and / or firmware. Moreover, the above-noted features and other aspects and principles of the innovations herein may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various routines, processes and / or operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, and may be implemented by a suitable combination of hardware, software, and / or firmware. For example, various general-purpose machines may be used with programs written in accordance with teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.

[0044] Aspects of the method and system described herein, such as the logic, may also be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices ("PLDs"), such as field programmable gate arrays ("FPGAs"), programmable array logic ("PAL") devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor ("MOSFET") technologies like complementary metal-oxide semiconductor ("CMOS"), bipolar technologies like emitter-coupled logic ("ECL"), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, and so on.

[0045] It should also be noted that the various logic and / or functions disclosed herein may be enabled using any number of combinations of hardware, firmware, and / or as data and / or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and / or other characteristics. Computer-readable media in which such formatted data and / or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) though again does not include transitory media. Unless the context clearly requires otherwise, throughout the description, the words "comprise," "comprising," and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of "including, but not limited to." Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words "herein," "hereunder," "above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word "or" is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

[0046] Although certain presently preferred implementations of the invention have been specifically described herein, it will be apparent to those skilled in the art to which the invention pertains that variations and modifications of the various implementations shown and described herein may be made without departing from the spirit and scope of the invention. Accordingly, it is intended that the invention be limited only to the extent required by the applicable rules of law.

[0047] While the foregoing has been with reference to a particular embodiment of the disclosure, it will be appreciated by those skilled in the art that changes in this embodiment may be made without departing from the principles and spirit of the disclosure, the scope of which is defined by the appended claims.

[0048] The present application is based on and claims the benefit of priorities of U.S. Patent Application No. 18 / 799,668 filed on August 9, 2024, the contents of which are incorporated herein by reference in their entirety.

Claims

1. An asset database apparatus, comprising: a graph database having a plurality of nodes wherein each node represents a piece of data about an asset and a plurality of edges wherein each edge represents a relationship between two nodes that each contain a piece of data about the same asset; an asset manager connected to the graph database that manages access to the graph database, adds or deletes asset data stored in the graph database and enforces a time to live for each piece of data for an asset stored in the graph database; and an asset relationship application programming interface (API) by which a user may access the asset manager.

2. The apparatus of claim 1, wherein the asset manager automatically deletes a particular asset when the time to live of the particular asset has been exhausted.

3. The apparatus of claim 1, wherein the asset manager adds a new asset into the graph database by adding a new node into the graph database.

4. The apparatus of claim 3, wherein the asset manager receives a new piece of data about an asset that is stored in the graph database, generates a new node for the new piece of data about the asset and generates an edge between the node of a the asset that is stored in the graph database and the new node for the new piece of data about the asset.

5. The apparatus of claim 1, wherein the asset manager gathers data about one or more assets and inserts the data about the one or more assets into the graph database.

6. The apparatus of claim 1, wherein a time period of the time to live is seven days.

7. The apparatus of claim 1, wherein the asset manager further comprises an artificial intelligence model that responds to a query about the asset in the graph database.

8. A method, comprising: 　　　　storing, in a plurality of nodes and a plurality of edges of a graph database wherein each node represents a piece of data about an asset and each edge represents a relationship between two nodes that each contain a piece of data about the same asset, an asset and data about the asset in nodes and edges of the graph database; 　　　　managing, by an asset manager connected to the graph database, access to the graph database including adding or deleting asset data stored in the graph database; enforcing, by the asset manager, a time to live for each piece of data for an asset stored in the graph database; and 　　　　accessing, by a user using an asset relationship application programming interface (API), the asset manager.

9. The method of claim 8, wherein enforcing the time to live further comprises automatically deleting a particular asset when the time to live of the particular asset has been exhausted.

10. The method of claim 8 further comprising adding, by the asset manager, a new asset into the graph database by adding a new node into the graph database.

11. The method of claim 10 further comprising receiving, by the asset manager, a new piece of data about an asset that is stored in the graph database, generating, by the asset manager, a new node for the new piece of data about the asset and generating, by the asset manager, an edge between the node of a the asset that is stored in the graph database and the new node for the new piece of data about the asset.

12. The method of claim 8 further comprising gathering, by the asset manager, data about one or more assets and inserting, by the asset manager, the data about the one or more assets into the graph database.

13. The method of claim 8, wherein a time period of the time to live is seven days.

14. The method of claim 8 further comprising responding, by an artificial intelligence model that is part pf the asset manager, to a query about the asset in the graph database.

15. A method for adding a new asset to an asset database using a graph database having a plurality of nodes and a plurality of edges wherein each node represents a piece of data about an asset and each edge represents a relationship between two nodes that each contain a piece of data about the same asset, the method comprising: 　　　　receiving, by an asset manager connected to the graph database, a piece of data about an asset to be stored in the graph database; 　　　　performing, by the asset manager, one or more validations on piece of data about the asset; generating, by the asset manager if the piece of data about the asset is validated, a new node in the graph database for the piece of data for the asset; 　　　　adding, by the asset manager, an edge to the graph database between the node that already stores the asset and the new node for the piece of data for the asset; and setting, by the asset manager, a time to live for the piece of data stored in the new node.

16. The method of claim 15 further comprising automatically deleting the piece of data for the asset when the time to live of the piece of data for the asset has been exhausted.

17. The method of claim 15 further comprising gathering, by the asset manager, data about one or more assets and inserting, by the asset manager, the data about the one or more assets into the graph database.

18. The method of claim 15, wherein a time period of the time to live is seven days.

Images