ASSET INVENTORY RECONCILIATION SERVICES FOR USE IN ASSET MANAGEMENT ARCHITECTURES
1. A system, comprising:
- one or more processors; and
one or more computer-readable storage media storing computer-executable instructions, the computer-executable instructions including,instructions for implementing an asset discovery handler component, the asset discovery handler component being configured to receive asset information from an asset collector component, and to normalize the asset information to a common format, the asset information describing an asset in an IT environment; and
instructions for implementing an asset reconciliation component, the asset reconciliation component being configured to apply defined reconciliation rules to determine whether a newly discovered asset is a new asset or one of the assets that the system already manages.
Disclosed below are representative embodiments of methods, apparatus, and systems for managing, monitoring, controlling, and/or classifying assets in an information technology (“IT”) environment. Certain embodiments leverage bath services oriented architecture concepts and event mechanisms to create a platform with which additional controls can easily integrate.
- 1. A system, comprising:
one or more processors; and one or more computer-readable storage media storing computer-executable instructions, the computer-executable instructions including, instructions for implementing an asset discovery handler component, the asset discovery handler component being configured to receive asset information from an asset collector component, and to normalize the asset information to a common format, the asset information describing an asset in an IT environment; and instructions for implementing an asset reconciliation component, the asset reconciliation component being configured to apply defined reconciliation rules to determine whether a newly discovered asset is a new asset or one of the assets that the system already manages.
- View Dependent Claims (2, 3, 4, 5)
This application claims the benefit of U.S. Provisional Application No. 61/800,134, filed on Mar. 15, 2013, and entitled “ASSET MANAGEMENT ARCHITECTURES” which is hereby incorporated herein by reference in its entirety.
This application relates generally to the field of information technology (“IT”) compliance and configuration control, asset control, and asset management.
Disclosed below are representative embodiments of methods, apparatus, and systems for managing, monitoring, controlling, and/or classifying assets in an information technology (“IT”) environment. Certain embodiments leverage both services oriented architecture concepts and eventing mechanisms to create a platform with which additional controls can easily integrate. The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and/or nonobvious features and aspects of the various disclosed embodiments, alone or in various combinations and subcombinations with one another.
Disclosed below are representative embodiments of methods, apparatus, and systems for managing, monitoring, controlling, and/or classifying assets in an information technology (“IT”) environment. The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and subcombinations with one another. Furthermore, any features or aspects of the disclosed embodiments can be used in various combinations and subcombinations with one another. For example, one or more method acts from one embodiment can be used with one or more method acts from another embodiment and vice versa. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.
Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, it should be understood that this manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth below. For example, operations described sequentially may in some cases be rearranged or performed concurrently. Moreover, or the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods. Additionally, the description sometimes uses terms like “determine,” “receive,” and “select,” to describe the disclosed methods. These terms are high-level abstractions of the actual operations that are performed. The actual operations that correspond to these terms may vary depending on the particular implementation and are readily discernible by one of ordinary skill in the art. Additionally, as used herein, the term “and/or” means any one item or combination of items in the phrase.
Any of the disclosed methods can be implemented as computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (such as DRAM or SRAM), or nonvolatile memory components (such as hard drives)) and executed on a computer (e.g., any commercially available computer, including desktop computers, servers, smart phones, tablet computers, netbooks, or other devices that include computing hardware). Any of the computer-executable instructions for implementing the disclosed techniques as well as any data created and used during implementation of the disclosed embodiments can be stored on one or more computer-readable media (e.g., non-transitory computer-readable media). The computer-executable instructions can be part of, for example, a dedicated software application or a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.
Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
The disclosed methods can also be implemented by specialized computing hardware that is configured to perform any of the disclosed methods. For example, the disclosed methods can be implemented (entirely or at least in part) by an integrated circuit (e.g., an application specific integrated circuit (“AMC”) or programmable logic device (“PLD”), such as a field programmable gate array (“FPGA”)). The integrated circuit can be embedded in or directly coupled to an electrical device having a suitable display device.
With reference to
The computing environment can have additional features. For example, the computing environment 100 includes storage 140, one or more input devices 150, one or more output devices 160, and one or more communication connections 170. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 100. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 100, and coordinates activities of the components of the computing environment 100.
The storage 140 can be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other tangible non-transitory non-volatile memory or storage medium which can be used to store information and which can be accessed within the computing environment 100. The storage 140 can also store instructions for the software 180 implementing any of the described techniques, systems, or environments.
The input device(s) 150 can be a touch input device such as a keyboard, touchscreen, mouse, pen, trackball, a voice input device, a scanning device, or another device that provides input to the computing environment 100. The output device(s) 160 can be a display device (e.g., a computer monitor, smartphone display, tablet display, netbook display, or touchscreen), printer, speaker, CD-writer, or another device that provides output from the computing environment 100.
The communication connection(s) 170 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions or other data in a, modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
As noted, the various methods can be described in the general context of computer-readable instructions stored on one or more computer-readable media. Computer-readable media are any available media that can be accessed within or by a computing environment. By way of example, and not limitation, with the computing environment 100, computer-readable media include tangible non-transitory computer-readable media such as memory 120 and storage 140 and do not encompass carrier waves or signals.
The various methods disclosed herein can also be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment by a processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, and so on that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing environment.
An example of a possible network topology (e.g., a client-server network or cloud-based network) for implementing a system according to the disclosed technology is depicted in
In the illustrated embodiment, the computing devices 220, 222, 230, 232 are configured to communicate with one or more central computers 210 via a network 212 (e.g., using a cloud network or other client-server network). In certain implementations, the central computers 210 execute software for performing any of the disclosed asset management functionalities (e.g., CCC tool functions, security control tool functions, asset inventory reconciliation, or analytics), for implementing any of the disclosed graphical user interfaces, and/or for computing any one or more of the intermediate or final values associated with the disclosed embodiments. The central computers 210 can transmit data to any of the computing devices 220, 222 (e.g., data to be displayed on a graphical user interface or web page at the computing devices 220, 222). For example, the computing devices 220, 222 (e.g., computing devices associated with an IT administer) can transmit a request for data to the central computer 210 over the network 212. In order to provide the data, the one or more central computers 210 can access data from the computing devices 230, 232 (e.g., computing devices or other devices associated with assets in the IT infrastructure administered by the IT administrator), which can store various types of data used by the IT administrator. For example, the computing devices 230, 232 may store device configuration data, compliance policy data, and/or other such data used by an IT compliance and configuration control tool. Alternatively, the one or more central computers 210 may themselves store the device configuration data, compliance policy, and other such IT data.
Another example of a possible network topology for implementing a system according to the disclosed technology is depicted in
In the illustrated embodiment, the computing devices 320, 322 are configured to communicate directly with computing devices 330, 332 via the network 312. In the illustrated embodiment, the computing devices 320, 322 are configured to locally implement any of the disclosed asset management functionalities (e.g., CCC tool functions, security control tool functions, asset inventory reconciliation, or analytics), implement any of the disclosed graphical user interfaces, and/or compute any one or more of the intermediate or final values associated with the disclosed embodiments. The computing devices 320, 322 can use data obtained from the computing devices 330, 332 via the network 312. Any of the data received from the devices 330, 332, can be stored or displayed on any of the computing devices 320, 322 (e.g., displayed as data on a graphical user interface or web page at the computing devices 320, 322). Any combination of the network topologies of
In the illustrated embodiments, the illustrated networks 212, 312 can be implemented as a Local Area Network (“LAN”) using wired networking (e.g., the Ethernet IEEE standard 802.3 or other appropriate standard) or wireless networking (e.g. one of the IEEE standards 802.11a, 802.11b, 802.11g, or 802.11n or other appropriate standard). Alternatively, at least part of the networks 212, 312 can be the Internet or a similar public network and operate using an appropriate protocol (e.g., the HTTP protocol).
Described herein are methods, systems, and apparatus that can be used to manage assets in an information technology (“IT”) environment. In particular embodiments, the disclosed technology can be used in connection with an IT compliance and configuration control software tool (“CCC tool”) that provides compliance and configuration control of one or more IT assets. (In some instance, the CCC tool is also referred to as a configuration management tool or security configuration management tool.) The compliance and configuration control tool can be used to detect, analyze, and report on change activity in an IT infrastructure. For example, the compliance and configuration control tool can assess configurations of the one or more assets at one or more locations and determine whether the assets comply with internal and/or external policies. The compliance and configuration control tool can identify and validate changes to ensure these configurations remain in known and trusted states. This particular usage should not be construed as limiting, however, as the technology can be used more generally with any one or more IT security tools.
One such compliance and configuration control tool that is suitable for use or adaptation to implement embodiments of the disclosed technology is the Tripwire@ Enterprise tool available from Tripwire, Inc. A compliance and configuration control tool may be part of a bigger asset management platform that can include other software tools, such as an event logging and management tool or a control security tool, examples of which are the Tripwire@ IP360 tool or Tripwire® WebApp360 available from Tripwire, Inc. One such platform that is suitable for use or adaptation to implement embodiments of the disclosed technology is the Tripwire® VIA platform. Similarly, one such event logging and management tool that is suitable for use or adaptation to implement embodiments of the disclosed technology is the Tripwire® Log Center tool.
In some instances, the examples described below reference the Tripwire Enterprise tool, the Tripwire Log Center tool, and the Tripwire VIA platform. These particular usages should not be construed as limiting, however, as the disclosed technology can be used to manage and classify assets using other tools and/or software components.
Asset Management is becoming of increasing importance. Business Proposals (“BPs”) either explicitly or implicitly require an increasing range of asset management functionality for a typical asset management platform (such as the VIA platform available from Tripwire, Inc.). Additionally, effective asset management is widely recognized in the cybersecurity domain as a necessary condition for effective risk management.
The 20 Critical Security Controls being promulgated by the Council on Cybersecurity (also known as the SANS 20 critical security controls) list asset management (hardware and software) as being of high importance, and, all else being equal, the first two activities an organization should undertake. Asset management requirements are, therefore, not only taken from BPs, but also from Critical Security Controls 1 and 2.
The scope of asset management can quickly creep into the domain of Configuration Management Databases (“CMDBs”), which are more centrally suited to providing IT operations a common view of IT resource information (of which assets are a part) than they are toward supporting security-process-specific use cases. There is, undoubtedly, feature overlap between CMDBs and asset management in the security and compliance and risk management domains.
Asset data stored by a compliance and configuration control (“CCC”) tool would typically be viewed, to a CMDB solution, as a Management Data Repository (“MDR”), as defined by the Distributed Management Task Force.
For illustrative purposes, this disclosure will sometimes make reference to one or more the following terms, whose meaning will typically have the associated definition. The definitions listed below, however, should not be construed as limiting, as the terms may have other or additional meaning depending on the context.
Asset: In general, an asset is anything that has value to an organization, including, but not limited to, another organization, person, computing device, information technology (IT) system, IT network, if circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualized computing), or related hardware (e.g., locks, cabinets, keyboards),
Asset Classification: a manner of scoping a subset of assets for use in a particular domain (e.g., security, criticality, geographical, platform, etc.),
Asset Context: semantic information pertaining to an asset providing additional meaning to the role, purpose, criticality, and so on, of the asset.
Asset Description: a piece or collection of information helping to describe the asset in some way,
Asset Discovery: the ability to passively nd/or actively identify assets connected to the enterprise.
Asset Environment: the assumed operating environment in which a given asset functions.
Asset Identification: a piece or collection of information helping to uniquely identify a given asset.
Asset Integrity: the establishment and maintenance of asset control with respect to its expected and actual state.
Asset inventory: the collection of known assets.
Asset Reconciliation: the ability to take a potentially incomplete set of information pertaining to one asset and comparing it to information pertaining to other assets with the goal of determining sameness.
Asset Relationship: providing the ability to discover and apply relationships between assets and/or sets of assets.
Configuration Management Database (CMDB): A CMDB typically stores data describing one or more of the following entities: managed resources (such as computer systems and application software); process artifacts (such as incident, problem, and change records); and/or relationships among managed resources and process artifacts. The contents of the CMDB can be managed by a configuration management process and serve as the foundation for other IT management processes, such as change management and availability management.
This section introduces several possible usage scenarios for embodiments of the improved asset management architecture disclosed herein (e.g., the architecture of FIG. 5). Further details concerning selected ones of these usage scenarios are described more detail below.
1. Correlation of Sensed Data
Information relevant to information security correlation may come from automated tools or manual processes. No matter the origin, the information pertaining to a given asset may not originate from the same tool, in which case the overall solution—that which seeks to aggregate and analyze information from disparate tools—will desirably determine when information pertains to the same or different assets. Embodiments of the disclosed technology can correlate sensed data to accomplish this goal. For example, embodiments of the asset inventory reconciliation service discussed in detail below can be used to correlate sensed data and facilitate creation of an asset inventory that can be accessed and analyzed using a variety of different tools.
2, Federation of Asset Databases
Asset information may be stored across a variety of tools, including, but not necessarily limited to: Active Directory, DHCP servers, information security sensors, inventory management systems, or other such tools. In the case where a solution seeks to aggregate and analyze security-relevant information from multiple tools with disparate notions and collections of assets, a mechanism is desirably available to moderate between the two sources. Embodiments of the disclosed technology can use a federation of databases to accomplish this goal.
3. Targeted Security Automation Actions
Many security-relevant processes require precise identification of particular assets. In the case of configuration assessment, for example, an ad hoc query may need to identify a specific instance of a specific platform family to assess in support of incident response. In the case of taking remedial actions, specific assets are desirably identified to ensure work efficiency. Embodiments of the disclosed technology allow for such targeted security automation action(s).
4. Maintain Asset Inventory
An asset management system desirably has the ability to represent and manage the asset lifecycle over time, including maintaining a list of decommissioned assets for a pre-defined period of time. Embodiments of the disclosed technology can maintain such an asset inventory.
5. Asset Authorization Management
From time to time, there are specific authorizations assigned to specific assets. For example, only assets used by the sales force and with an active sales person logged-in can connect to a subnet containing sales-specific data. Another way authorizations are used is by creating white, gray, and black lists of software that: (a) is authorized to operate on a given computing device (white); (b) is sometimes authorized to operate on a given computing device (gray); or (c) is not authorized to operate on a given computing device (black). Embodiments of the disclosed technology can provide such asset authorization management.
6. Determine Relationships Between Types of Assets
One function that can be important to a control framework, and therefore to an organizational security policy, is the ability to understand the relationship between different types of assets. A computing device that does not store, process, or transmit critical data should not, for example, be categorized as a critical asset and thereby be subjected to the most stringent controls. Similarly, it can be a requirement to relate a particular computing asset to a specific owner (a personnel asset), especially when remedial actions is to be taken. Without understanding who owns, and is therefore accountable for, a given computing or information asset, it is impossible to efficiently mitigate unnecessary risk. Embodiments of the disclosed technology can determine such relationships between types of assets.
Among the possible advantages that can be realized using embodiments of the disclosed technology are one or more of the following:
- a more complete asset management implementation than currently possible with CCC tools;
- normalization of the way each software tool in a security platform treats and refers to assets (e.g., by storing data in a format that can be queried directly or inferentially using an appropriate query language (such as SPARQL, which can retrieve and manipulate data stored in a Resource Description Framework format); and/or
- asset discovery capabilities in multiple (e.g., all) tools across the security platform; and/or integration with full and/or partial third-party CMDB systems.
This section discloses example objectives that can be met by embodiments of the disclosed technology. Any one or more of these objectives can be met by implementations of the disclosed technology. Furthermore, the objectives discussed herein are not to be considered limiting, as certain implementations may not meet any of these objectives or may meet supplemental or alternative objectives.
The disclosed objectives are derived from BPs, the SANS 20 critical security controls, and existing product functionality, and can be categorized as follows: asset description, asset reconciliation, asset discovery, and asset context,
2. Possible Architectural Capabilities
To support certain primary feature-level objectives, embodiments of the disclosed software tools, techniques, and frameworks have one or more of the following capabilities (e.g., all of the following capabilities):
- Normalization of asset information between tools (e.g., between proprietary tools, and/or between the software vendor and third-party tools);
- Reconciliation of normalized assets with the side-effect of discovery;
- The capability to acquire, establish, and/or maintain asset relationships to other assets (e.g., owned by, installed on, etc.);
- Support of asset inventory query, update, add, delete commands; and/or
- Support of asset meta-data above and beyond identification (e.g., business context)
To support additional feature-level objectives, embodiments of the disclosed software architecture have one or more of the following capabilities (e.g., all of the following capabilities):
- The ability to acquire, establish, and/or maintain asset authorizations;
- The ability to provide blocking, uninstallation, and/or other mitigation against unauthorized assets take some temporary remedial action); and/or
- The ability to provide alerting capabilities for asset-specific use cases (e.g., CSC controls one and two both require alerting within specific thresholds).
3. Security Considerations
The integrity of asset information is typically of high importance as a foundation to security controls, and therefore to reports supporting business decisions. Any reports based on tainted or incorrect asset information may result in incorrect attribution, remediation instructions, lost revenue, increased expense, and/or a discontinuity of business. In addition, the confidentiality of asset information is likely to be held important in the eyes of IT professionals, organizational policy authorities, and CISOs alike. This is especially true if the asset management system contains any proprietary, secret, or information categorized by law as personally identifying information. Availability of fresh asset information is desired by most security-related business processes, though it is typically not viewed as important as integrity and confidentiality.
As such, embodiments of an asset management solution desirably should take measures to ensure the integrity and confidentiality of the asset information it stores, processes, or transmits. Such embodiment should take reasonable measures to ensure the availability of asset information, but a “highly available” solution is not necessarily required except in the most stringent environments.
The target architecture 500 of
1. Asset Inventory
Example asset inventory component 610 illustrated in
2. Tag Manner
Example tag manager component 612 illustrated in
3. Collector Health
Example collector health component 614 illustrated in
4. Asset Data Services
Example asset data services component 616 illustrated in
5. Tat; Data Services
Example tag data services component 618 illustrated in
6. Asset Discovery Handler
Example asset discovery handler component 620 illustrated in
7. Asset Reconciliation
Example asset reconciliation component 622 illustrated in
This section discloses in more detail some example usage scenarios that help illustrate aspects of the disclosed technology.
Consider a scenario where an agent (e.g., a VIA agent) is configured through an audit logger to monitor a DHCP log. Throughout the day, the DHCP log is updated, and addresses are assigned, renewed, released, and so on. The agent is collecting and feeding these events to the message broker as they occur. In this example, the audit logger component writes the events to the appropriate location and passes them off to be normalized for correlation purposes (e.g., into a CEE-aligned format). Normalized results are posted to the messaging fabric, where the asset discovery handler 620 will be listening for specific DHCP log events to be posted.
When a DHCP “address issued” message is received, the discovery handler can look at the correlation-normalized information and create a new set of asset identification information related to that potentially new asset. This information is put into the message bus, and the asset inventory component 610 picks it up for storage. When the asset inventory component 610 adds this “new” asset identification to the inventory, this generates a message that is picked up by the asset reconciliation component 622, which then starts the process of determining whether the “new” asset is really a new asset or simply one that is already know about. Its results are posted back to the message fabric and picked up by the asset inventory component 610 where appropriate action is taken. In other embodiments, the asset reconciliation component 622 receives the assets information before it is first stored to the asset inventory component 610 (e.g., as described below with respect to
In another scenario, a chief information security officer (“CISO”) has identified a set of systems that are underperforming by interacting with, for example, a visualization solution. The visualization solution can have a contextual pop-up option automatically alerting the owners of the underperforming system when clicked by the CISO. In this case, the visualization component (a Web UI Component) will interact with the asset inventory component 610 to determine a list of all system owners for the relevant underperforming systems.
To determine the list of owners, and according to one exemplary embodiment, the process starts with the list of underperforming assets. Each asset can have a relation (stored in asset relations DB) that will provide the “owned by,” and/or “administered by” relationships. In a case where the asset does not have an “owned by” or “administered by” relationship, the “asset chain” can be analyzed to discover the first owner or administrator. For example, an IIS server requiring remediation may not have the owner or administrator identified, but it is “installed on” another asset which may have an owner or administrator identified. If the operating system does not have an identified owner or administrator, then the computing device (the asset upon which the operating system is installed) should.
Once the list of contacts is returned, the Web UI Component can then interact with whatever alerting capabilities are provided as appropriate to indicate that a system is underperforming.
It may not be possible to migrate directly from an existing asset management architecture to the target architecture in one step. Instead, an incremental approach can be used. An example interim approach based on components offered by Tripwire, Inc., looks at the CCC tool (e.g., TE) and the event logging and management tool (e.g., TLC) separately, each incrementing to common components in the target architecture, starting with the creation of, for example, asset data services 618 over tag data and collector error data, moving asset manager component 624 and asset health component 626 to the application services layer 628 of the architecture, and creating an asset reconciliation analysis engine 622.
The incremental architectures shown in
In the illustrated embodiment, the common changes in the way TE and TLC work with assets can be viewed as the first increment of an asset management platform. In this first increment (
In certain embodiments, the increments comprise one or more of the following:
- Preparing the architecture for further change and starting to consider a more comprehensive number of items as “assets” (e.g., as discussed above);
- Making tagging available to more assets or items in the architecture; this opens new opportunities for applying intelligence and/or automation outside asset management; and
- Adding relationship capabilities to asset management, changing from “management” to inventory from a nomenclature perspective, and/or centralizing asset discovery analysis.
The increments described relate only to the primary features listed above in the “Possible Architectural Capabilities” section. The “next” features are more advanced features of managing asset authorizations, such as establishing a list of appropriate subnets to which a laptop can connect or providing white-/gray-/black-lists for installed software.
In this section, example tools, techniques, and frameworks for performing asset reconciliation are described. The asset reconciliation component is referred to in this section as the “asset inventory support service” and can be applied to perform asset reconciliation as in
Embodiments of the disclosed asset inventory support service can fulfill a variety of objectives. In general, embodiments of the disclosed technology are configured to perform a reconciliation of assets from sources that discover new assets. For example, embodiments of the disclosed asset inventory support service can report on the discovery, of new assets by facilitating the collection of assets and/or asset properties not detected by a primary source through integration with other monitoring tools, such as third-party security control products or other asset monitoring tools. The primary source can be a compliance and configuration control tool that has an asset discovery mechanism (e.g., Tripwire Enterprise). Embodiments of the disclosed technology also support analytics by reconciling assets into an asset inventory so that distinct asset counts are available to provide a reliable measure with regard to coverage, through the use of distinct reconciliation identifications. Embodiments of the disclosed technology can also enable an enterprise level inventory of assets for security control product consolidation, meeting enterprise scale goals.
To illustrate the operation of the disclosed asset inventory service, a number of example workflows are described. These workflows should not be construed as limiting, as the actions performed in the workflows can be performed alone or in any combination or subcombination with one another or with other workflows.
A first example use case is to enrich asset information through reconciliation with other sources of assets.
In certain embodiments, an initial source of asset information, such as a CMDB storing information collected by a CCC tool, can populate the asset inventory reconciliation service. This source can contain metadata about the asset, such as tagging information or application inventory in the form of a Common Platform Enumeration (“CPE”). CPE is a structured naming scheme for information technology systems, platforms, and packages. When an asset is processed by the asset inventory reconciliation service, a unique reconciliation identification number can be allocated (e.g. a universally unique identifier (“UUID”)). A security control application can submit information it contains about the asset to the asset inventory reconciliation service as well, including the synthetic II) allocated by this control, and/or any synthetic IDs it is aware other systems have given the asset (such as a MAC-address, motherboard ID, or simply one shared through another security control application integration).
The asset can then be filtered, normalized, and reconciled with any asset records previously available from the initial asset information source. The security control application'"'"'s assets are associated to the same reconciliation IDs as the assets in the initial source if they match. For assets that do not match, they are allocated a unique reconciliation ID.
The asset inventory reconciliation service can also be responsive to requests for asset information from the CCC tool, security control tool, or other asset monitoring tool. For example, the asset inventory reconciliation service can respond with the reconciled asset which contains the metadata provided from the initial source as well as information other sources (e.g., the synthetic Ds from all sources). This data can be used, for example, by the security control or other monitoring tool to filter assets when reporting security results or otherwise analyzing asset events.
Building on the events of the first workflow, a second security control application can participate and submit its asset information in the same way to the reconciliation service. In particular embodiments, both security controls submit their asset information to the reconciliation service as the information changes.
Periodically, extract/transform/load (“ETL”) processes can be performed to extract security results from each of the security control applications to store in a reporting and analytics data store. The ETL, process consults the reconciliation service to transform each asset so that it can record each asset with its security results in a correlatable form—with the reconciliation ID assigned by the reconciliation service. Security results are stored in relation to the enriched asset into a data store such as a relational database management system (“RDMS”). A reporting system is then able to query the results of both security controls in the data store, and correlate control results to a single asset by distinguishing assets by reconciliations ID.
Similar to the first example workflow, an integration with one or more third party repositories of asset records extracts and publishes those assets to the reconciliation service on a continuing basis. Third party repositories can range from as simple as a spreadsheet of asset names, to tools that analyze network behavior to determine presence of computing devices (such as Nmap).
In certain embodiments, one or more security control applications publish assets they are aware of to the reconciliation service, also on a continuous basis. Security control software applications are typically made aware of assets through the installation of scanning agents on the computing device, or through manual declaration of the asset in the security control software.
The reconciled assets output as a result are collected into a reporting data store. Analytic systems can query that system to identify and display to a user which subsets of the assets in an enterprise are covered by a selected security control (e.g., by each of the security controls).
Compliance and configuration control tool 1210 can be used to detect, analyze, and report on change activity in one or more of the assets 1200. For example, the compliance and configuration control tool can discover and assess configurations of the one or more assets at one or more physical locations and determine whether the assets comply with internal and/or external policies. For instance, the compliance and configuration tool can use software agents that are implemented on each of the assets in order to monitor and report this information to the tool 1210. The compliance and configuration control tool can identify and validate changes to ensure these configurations remain in known and trusted states. In particular implementations, the compliance and configuration control tool operates by capturing a baseline of server file systems, desktop file system, directory servers, databases, virtual systems, middleware applications and/or network device configurations in a known good state. Ongoing integrity checks then compare the current states against these baselines to detect changes. The compliance and configuration control tool collects information used to evaluate detected changes, ensuring they are authorized and intended changes. For instance, the compliance and configuration control tool can crosscheck detected changes with defined IT compliance policies (e.g., using policy-based filtering), with documented change tickets in a change control management (CCM) system or a list of approved changes, with automatically generated lists created by patch management and software provisioning tools, and/or against other desired and approved changes. This allows the compliance and configuration control tool to automatically recognize desired changes and expose undesired changes. The compliance and configuration control tool can also generate one or more reports concerning the monitored assets showing a wide variety of information (e.g., compliance information, configuration information, usage information, etc.). One such compliance and configuration control tool that is suitable for use as tool 1210 is the Tripwire® Enterprise software tool available from Tripwire, Inc. The examples described below are sometimes shown as being used in connection with the Tripwire Enterprise tool. This particular usage should not be construed as limiting, however, as the disclosed technology can be used with other monitoring and reporting tools for an IT environment. Furthermore, the CCC tool 1210 typically generates and maintains its own asset data store (e.g., a change management database) that comprises asset data, such as asset IDs (e.g., synthetic IDs (which comprise identifiers assigned by, the CCC tool as opposed to an external source) and one or more asset properties (such as hostnames, IP addresses, tag information, etc.).
Security control tool 1212 is configured to detect, analyze, and report on one or more security control issues for one or more of the assets 1200. For instance, the security control tool 1212 can be a vulnerability and security risk management tool that measures and manages security risks to the assets 1200. The vulnerability and security risk management tool can itself perform an operation whereby networked assets are discovered and profiled (separate from the CCC tool). For instance, the vulnerability and security risk management tool can profile networked hosts, applications, services, vulnerabilities, and configurations in order to provide a risk management view of the assets separate from the CCC tool. 1210. The security control tool can be configured to perform vulnerability scanning operations on internal networks and/or vulnerability scanning on outward-facing networks, such as scanning for web application vulnerabilities. One such security control tool that is suitable for use as tool 1212 is the Tripwire® IP360 software tool available from Tripwire, Inc. The examples described below are sometimes shown as being used in connection with the Tripwire IP360 tool. This particular usage should not be construed as limiting, however, as the disclosed technology can be used with other monitoring and reporting tools for an IT environment. Furthermore, the security control tool 1212 typically generates and maintains its own asset data store that comprises asset data, such as asset IDs (e.g., synthetic IDs (which comprise identifiers assigned by the security control tool as opposed to an external source) and one or more asset properties.
The discovery mechanism and the information for an asset collected by the security control tool 1212 can, and often will, differ from the CCC tool 1210, making it desirable to reconcile the assets with one another so that an IT administrator has a clear and accurate understanding of the inventory of assets in the enterprise, thus enabling better reporting and management. Furthermore, the assets discovered by the CCC tool 1210 and the security control tool 1212 do not necessarily overlap. In other words, the CCC tool 1210 may detect assets undetected by the security control tool 1212 and vice versa. This potential lack of overlap is represented schematically in
Asset inventory reconciliation service 1220 in
In particular embodiments, the asset inventory reconciliation service 1220 performs reconciliation by performing one or more of attribute normalization, application of one or more asset filters, application of one or more attribute filters, asset matching, asset merging, and/or tag set management. An exemplary implementation of the asset inventory reconciliation service 1220 is described below with respect to
The asset data stored in asset inventory 1230 comprises the reconciled data from the asset inventory reconciliation service 1220. This reconciled data represents data that is more accurate and more complete than data otherwise available to an IT administrator, chief information security officer (“CISO”), or other IT executive or evaluator. As shown by
The asset inventory reconciliation service 1340 can also provide management services of tags or tag sets to be applied or retrieved for any of the assets in the asset inventory 1360. Tag set management can be performed, for example, tag set management component 1358, which can be accessed using a tag set API supported by the REST service 1342. An exemplary tag set API is disclosed below. The tag set management component 1358 can be used to perform a variety of actions concerning the tags of the stored asset, including one or more of: listing all tagsets, listing a given tag set and the tag values it supports, submitting a new tagset with a set of tag values, removing a tagset, and/or updating an existing tagset.
As illustrated in
1. Producing a Reconciled Asset
In general, the reconciled form of an asset collects from the stored source forms, the union of the tags, asset properties, Common Platform Enumerations (CPEs) (such as the CPEs developed by MITRE and referred to generally as CPE Version 2.3), IP addresses and/or synthetic IDs (IDs generated and specified by the source tool) for an asset. It should be understood that this union operation can eliminate duplicate elements or, in some implementations, maintain duplicate elements. In particular embodiments, the reconciled form also comprises an expanding first_observed date and last_observed date. The first_observed date is the earliest date submitted with an asset. The last_observed date is the newest date submitted. This allows the asset inventory reconciliation service 1340 to determine if the security tools or sources are still aware of or operating on the asset and can also assist with merging, as explained below. This information can also inform purging or coverage.
In particular embodiments, the reconciled form further comprises a universally unique identifier (a UUID). For example, when assets are submitted to the asset inventory reconciliation service 1340 that do not match any existing previously reconciled assets in the asset inventory 1360, a new UUID is allocated. When assets are submitted that match, one or more existing assets, the UUID of the asset with the oldest first_observed date is preserved. In particular implementations, the reconciled form maintains the hostname of the newest matching asset based on the last_observed date.
a. Source Form
In particular embodiments, when an asset is posted to asset inventory reconciliation service 1340 via the REST service 1342, it includes an identifier (e.g., “SOURCE”) that is reproducible for a given asset from a given asset source (such as a DHCP server, change management database (“CMDB”), VA tool, security control tool, etc), and distinct from other sources. This identifier is used to detect updates of data from a given asset source. For instance, DHCP logs do not have high update requirements, and the “SOURCE” field could be set to “DHCP”.
When an update is posted, it can be matched by either the hostname or media access control address (MAC address) with the same reconciled asset, even though the IP address may have changed. The previous data for the reconciled asset that matches the ‘SOURCE’ value will be replaced. In this case, dis-associating the old IP address, and collecting the new.
In particular embodiments, the source field should be set to a repeatable composite key value that uniquely identifies the asset in the system it is coming from
In certain embodiments, content will be executed in the context of a read-only, transaction. For instance, it shall not be permitted to update any database data; it shall also be sandboxed, as to have no permissions to update the local file-system. Content can be created or updated by a service provider (e.g., a provider of the asset inventory reconciliation service), customer, and/or other user.
In this disclosure, content refers to configuration files that serve as instructions governing the operation of the system that can be shipped in an independent cycle than that of the software solution. In other words, content files are a means of delivering functionality independent of the mechanism. In the context of the asset inventory reconciliation service, the provider of the reconciliation service (or, in some cases, the customer itself) can develop and deliver content files suited to a particular customer base or even for a particular customer without having to perform a full release of the asset inventory reconciliation software. This enables a more “nimble” release cycle and allows a service provider to have greater flexibility in the security marketplace. In certain embodiments of the disclosed technology, for example, the reconciliation rules (applied at 1354), the filtering rules (applied at 1352), and/or the normalization rules (applied at 1350) are “content” and not distributed in compiled form so that they can be adapted to a customer'"'"'s unique IT asset situation.
Some attributes may come from source systems in multiple forms, but to enable reconciliation it is desirable to normalize attributes for easy matching. For instance, MAC addresses are reported with colons on POSIX systems, and hyphens on Microsoft systems. Normalization can be performed so that the MAC address attribute has a common form regardless of source.
In the illustrated embodiment, normalization is performed by attribute normalization module 1350 and occurs before filtering so that filtering rules can assume simpler forms. Normalization can be performed, for example, using a, series of rules. These rules can be expressed in a domain specific language (“DSL”) so that they can normalize any portion of the asset. Similar to filters, the normalization, rules can be attribute specific.
Two example normalization rules are illustrated below. The first example applies to the IP addresses of the assets and canonicalizes the form of the IP address by utilizing the InetAddresses library routine from Java. In the second example, it is assumed that the source tool records an asset'"'"'s MAC address as its synthetic ID (though this is not necessarily the case, as a MAC address and a separate synthetic ID may be created by the source tool). The second example normalizes the synthetic ID to use a common form, such as 00:00:00:00:00:00 by replacing the hyphens with colons.
In certain embodiments, when an asset is posted and before it is persisted, it will go through one or more types of filtering. For instance, one or both of attribute filtering and asset filtering can be performed. In
Attribute filtering is performed to weed out unnecessary (garbage) data, such as loopback IP addresses. Attribute filtering can also be performed using a series of rules expressed in a DSL. In one particular implementation, the filtering rules are expressed in a script in the Groovy programming language masquerading as a .conf file with a domain specific language (DSL) for expressing the filters. Asset filtering can also be expressed with a DSL for rejecting assets outright. This will allow for refusing an asset based on some hostname convention, or because of the subnet expressed in the assets IP address. Both attribute and asset filtering passes will enable the content to evaluate the properties (e.g., all properties) on the source asset.
In particular implementations, the DSL can support declaring a collection of filters for specific attributes by specifying the bean field name of the attribute with the suffix of ‘Filter’, and passing to that a Groovy closure that when executed will receive the attribute value. When the filters are executed, the appropriate attributes are passed to them, and rejected or preserved based on the Boolean return value of the given Groovy closure. To reject an asset entirely, one can add a filter to the set of filters (asssetFilter); pass it a Groovy closure that can inspect an asset and return true or false, where filters return true (or, alternatively, false) to filter out the value.
The following example filters reject various values in the ip_address attribute of the source assets:
This kind of filtering can be applied to any of the fields. For instance, if one has a security information source that does a bad job of collecting MAC addresses, known invalid values can be filtered out so that they do not inadvertently cause erroneous asset reconciliations.
Reconcilers are content expressions of asset queries based on attributes of the asset being submitted. Each reconciler defined can return one or more matching assets. Typically, a reconciler will have access to all attributes of the asset, and full query expression capabilities, as well as suitable conjunctions (e.g., Groovy conjunctions) for a rich and capable expression. In particular embodiments, all reconcilers defined are run for each incoming asset. In other embodiments, a subset of one or more of the reconcilers are run for an incoming asset.
Furthermore, the reconcilers are content adaptive and can be created or modified by a system administrator or other user in order to reconcile assets according to any one or more desired criteria. For instance, the schema introduced below can be used in order to create any number of reconcilers according to any available asset property (e.g., according to tags, identifiers, or other asset properties). This adaptive and flexible approach allows the asset reconciliation service to be highly scalable and customizable for use with a variety of different asset sources and reporting tools.
Two example reconcilers are described below. A first example reconciler utilizes access to Grails'"'"' objection relational mapping (GORM) Groovy DSL for a query as an extension of the reconciliation DSL. It finds any already known asset that has a matching synthetic ID with the incoming asset. The second example reconciler uses a GORM query method to match on a single attribute value, such as the hostname.
This section describes example reconciliation flows that can be performed by the asset inventory reconciliation service 1220 or asset inventory reconciliation service 1340. The particular method acts described are not to be construed as limiting, as they can be performed alone or in any combination or subcombination with one another. Furthermore, the particular ordering is not to be construed as limiting, as the method acts can be performed in different orders or at least partially simultaneously with one another or with other method acts. For example, the normalization, filtering, and reconciliation rules can be applied at least partially concurrently in parallel pipeline stages or in different orders.
At 1410, asset data from a source is received (e.g., stored, buffered, input, or otherwise prepared for further processing). The asset data can be received via a REST or messaging API. At 1412, attributes of the asset data are normalized. For instance, and as explained above, MAC address string formats are normalized. At 1414, attributes of the asset are filtered out. For instance, and as explained above, loopback IP addresses can be filtered out. At 1416, reconciliation rules are applied (e.g., reconciliation rules as defined in the reconciliation content are applied) in order to identify previously stored assets that have one more asset properties matching one or more properties of the received asset data. At 1418, assets identified at 1416 as having one or more matching asset properties are be merged to form reconciled asset data.
An example of a reconciliation process is described below. In this example, the source_asset refers to a subset of asset details as provided from a source system, the reconciled_asset refers to the merger of details (e.g., all details) from the source_assets that have been matched together, and the synthetic IDs refer to the asset identifications assigned by various source tools. For example, each synthetic ID can be a tuple representing an asset in the terms of a source system. The ID contains a “resource” part that identifies the system the asset information comes from, and an “asset_id” part that identifies that asset within the resource. Further, in this example, the reconciled_assets further include links to the source_assets used to create the reconciled_assets, and the source_assets used to form the reconciled_assets are maintained in the asset inventory as well as the reconciled_assets.
In one example implementation, when a new source_asset is received, a new reconciled_asset wrapper is created for the source_asset. This new reconciled_asset initially includes the details of the newly received source_asset. In this example, the reconciliation rules attempt to find any previously stored reconciled_asset with at least one matching synthetic_id or matching hostname as the newly received source_asset. (It should be kept in mind that these rules are by way of example only; as explained elsewhere herein, the matching rules can be customized to any desired criteria by modifying the content of the rules.) In many cases, a single previously stored reconciled_asset will be identified as matching. In some cases, however, multiple reconciled_assets will be identified as matching. For instance, it is possible for the source tools to produce source_assets that do not contain sufficient information to link the source_assets together as relating to the same asset. Subsequently, a source_asset from another source tool (or a source_asset that contains additional linking information, such as an IP address or MAC address) can provide information sufficient to link several reconciled_assets together as relating to the same asset. This new source_asset information can therefore serve as the bridge to creating a richer reconciled_asset, which in turn provides additional related data and context for the asset at can be used by downstream analytic and reporting tools.
Continuing with the example implementation, the source_assets associated with the one or more matching reconciled_assets are gathered together into a collection of source_assets. (Since a reconciled_asset may comprise data from and link to multiple source_assets, two or more source_assets may be collected for each reconciled_asset.) If one of those source_assets has the same source ID as the newly submitted source_asset, then it is replaced in the collection of source_assets by the new source_asset (effectively removing the older source_asset having the same source ID). This process of replacing one of the older source_assets in the collection allows updated information to be correctly propagated into the new reconciled_asset and permits asset information to evolve (and even be removed) over time. The source ID can be the synthetic ID as described above, which describes an asset in terms of its asset ID and source system (source tool). The result is a new collection of source_assets.
The new collection of source_asset is used to populate one of the reconciled_assets, effectively generating a merged reconciled_asset. To determine which of the matching reconciled_assets is to be used as the merged reconciled_asset, the first_observed_dates of the reconciled_assets can be used. In one implementation, for example, the oldest reconciled_asset (the reconciled_asset with the earliest first_observed_date) is identified and used as the reconciled_asset into which the collected source_assets are merged. The other reconciled_assets can be discarded. The name of the merged reconciled_asset can also be updated with that of the newest of the source_assets (in order to represent the asset in terms of its most recent name).
To populate the merged reconciled asset, one or more of the collections fields (and, in some embodiments, each of the collection fields) of the collection of source_assets are unioned together and replace the previous sets of attributes on the reconciled_asset. The collection fields can include one or more of ip_addresses, asset_property data, tag data, synthetic IDs, etc. The new state of the reconciled_asset is persisted (e.g., in the asset inventory) and can be made available through messaging and, if appropriate, returned to the REST API caller.
As noted, in particular embodiments, the merged reconciled_asset data includes a collection of synthetic IDs for an asset. This can be desirable since each source_asset may have its own synthetic ID from the source tool, and the maintenance of the union of these synthetic IDs allows reporting tools to have the means to map the reconciled asset back to a source system. This can be particularly useful when the reporting tool or other tool works with the asset in the source system'"'"'s own APIs.
In this section, an example application programming interface (API) is introduced that can be used in connection with the disclosed technology. This particular API is by way of example only, as it can be modified in detail and arrangement without departing from the principles of the disclosed technology. The API can be a publicly available API (or API made available to clients) to help facilitate custom content. Internal messaging (e.g., using a private API) can be used for internal clients to send source_assets and retrieve a corresponding reconciled_asset.
In particular embodiments, the API manages tags and tag sets that may be associated with any of the assets. Tags are discussed in more detail in U.S. patent application Ser. No. 13/597,242, filed on Aug. 28, 2012, entitled “Managing and Classifying Assets in an Information Technology Environment Using Tags”, which is incorporated herein by reference.
In certain implementations, the REST service 1342 provides the API for managing tag sets (TagSets) and the tags within. TagSets and tags are created as needed when assets are posted. However the API allows pre-creation of them, and allows removal of them. In particular implementations, removal will purge the tag from all assets it is assigned to.
The service also provides an API for submitting assets, deleting assets, and/or retrieving assets in mass or individually by ID. For example, assets from the asset inventory 1360 can be retrieved via the API of the REST service 1342.
In particular implementation, the API supports application/json and application/xml formats for input and output.
The REST API can support the ID in the URL to be any of the synthetic IDs associated to an asset, as well as the reconciliation ID.
The synthetic Ds are a tuple: a resource defining the context of the id and the ID within that resource. The encoding can be, for example: urlEncode(resource)+/+urlEncode(id)
Reconciled assets can be represented as flat objects with embedded collections. Further, in some implementations, there will not be references to tags that have to be looked up in subsequent calls. Likewise, assets posted to the interface should contain all of the data the source has about the asset as though it is a new asset, the reconciliation engine will determine if it is an update or create, and perform the merging.
The API can represent details of an asset in the following form:
For POST operations the reconciliation UUID tag can be omitted and the collections are also optional (e.g., tags, ipadresses, syntheticIds, metaProperties, etc). In particular embodiments, empty collections for tags, ipaddresses, syntheticIds, and metaProperties will cause the corresponding element to be absent. If there are no tags, then the tags element will not appear in the XML output.
Again, for POST operations, tags, ipaddresses, syntheticIds, and metaProperties are optional. A reconciliation_uuid is ignored on POST. In certain implementations, empty collections for tags, ipaddresses, syntheticIds, and metaProperties will be absent from the map. If there are no tags, then the tags property will not appear in the BON output.
In certain embodiments, a messaging service will allow internal message clients to subscribe to asset creation/updates as they occur. For example, the messaging service can subscribe to a channel to allow submission of assets through messaging. The service can subscribe to a command channel to allow external matching systems to assert that two or more assets must be merged into one reconciled asset. The asset inventory reconciliation service can publish on a subscribable topic the resulting reconciled assets for consumption by interested applications, such as for recording into a security control data mart for reporting and analytics.
This section introduces an example schema with which assets can be submitted to and handled by the asset inventory reconciliation service 1340. The submitted source assets can be stored in a relational database management system (“RDBM”) along with the reconciled assets. Reconciliation can then be performed on the newly submitted source assets.
1. Example Naming Convention
Table names—lower_underbar_case—example: tag_set
Primary key columns integer, named <table_name>_key—example: tag_set_key
Collections—represented as link tables—<owner_table_name>_<subordinate_table_name>—example: reconciled_asset_tag
In certain embodiments, the reconciliation UUID will not be generated from details about the asset, but simply be unique to the system. They will not be reproducable, and once allocated they are opaque, meaning they cannot be decomposed into any details about the asset.
A reconciled_asset can still have a database key, for use in join tables between the collection items.
In particular embodiments, the source_asset is used to hold the collections that need to be merged, so that updates from a given source can have subtractive properties. That is, the reconciled set can be the union of values in all of the source sets. Updates from clients can replace the appropriate source set prior to the reconciler producing the union.
For example, the asset_property is used to store data like te_asset_type=Windows Server, te_asset_type=‘POSIX Device’ etc. In certain embodiments, there will be no constraint that the property name is unique per asset. Different sources are expected to have different details, and assets can be conflated into a single asset, for, for example, dbi, ndi, and fsi assets can be treated as one asset with multiple values for te_asset_type, all of which are valid.
Having illustrated and described the principles of the disclosed technology, it will be apparent to those skilled in the art that the disclosed embodiments can be modified in arrangement and detail without departing from such principles. For example, any one or more aspects of the disclosed technology can be applied in other embodiments. In view of the many possible embodiments to which the principles of the disclosed technologies can be applied, it should be recognized that the illustrated embodiments are only preferred examples of the technologies and should not be taken as limiting the scope of the invention.