This is the second part of the article on Asset Management, the previous article can be found under here.
Just Enough Asset Management(JEAM) design was influenced by the concepts and definition of Minimum Viable Product(MVP); what is the least amount of data, engineering and operational effort required to create and operate a viable JEAM product. The concept was applied rigorously during the conception and design of the JEAM, anything that didn’t meet that criteria was thrown out or moved to a higher layer. The design can always be improved but the MVP principle should always be front and center in any modifications to the design. Remember most Asset Management initiatives failed because they tried to do too much.
JEAM is designed to be simple but requires some engineering effort, this was estimated to be nominal compared to the value proposition of building such a system. Watch out for startups working on similar ideas, there are already some in the works.
JEAM has the following main components, these components can be collapsed in a single system:
- Primary and Secondary Attribute Log Sources
- Near Real-time Processing Engine
- Asset Aggregation Layer(Aggy)
- Data Enrichment Sources(DES)
Primary and Secondary Attribute Log Sources: The first steps in designing the JEAM system is to identify reliable log sources to extract Primary and Secondary attributes. Ideally some of these log sources should already exist within an organization. Some key considerations are noted below:
- The log source is reliable, durable and is part of the core infrastructure capability.
- Wireless AUTH logs, Network Access Control(NAC), VPN, Cloud API logs were assessed to be consistently reliable. An organization might have other log sources that it considers reliable after their internal review.
- The log source is not dependent on another asset management system e.g. vulnerability management asset log, Endpoint asset logs, etc.
- Network scanning and active network discovery was considered redundant and error prone as the primary source.
- Hostname and Cloud Asset ID are considered primary attributes. If the system is only logging secondary attributes then either correlate this with a primary attribute or if that is not possible, discard the data and reassess the usability of the data source.
- Ephemeral assets should be added as regular assets however assets that are not observed in the logs should be archived or purged after a pre-determined period.
Near Real-time Processing Engine: The Near Real-time Processing engine normalizes the data to a consistent format and then de-duplicates it across all data sources in a given timeframe. Near Real-time Processing engine should handle both log sources and static entries from DNS or DHCP configuration. It also acts as the ingestion point for Aggy. Enhancement to this can include a caching and base analytic system with a subset of asset data retrieved from Asset Aggregation Layer, this might act as the fundamental building block for a User Behavior Analytics(UBA) and Context-Based Access Control System, think Google’s Beyond Corp. However, the main focus should remain normalization and deduplication of data in version 1.
Asset Aggregation Layer(Aggy): Aggy is the core of the JEAM system. It must follow an API first model and performs the following functions:
- Indexes all asset data.
- Processes Primary attributes as existing or new and performs appropriate activities to update an existing record or creating a new one.
- Perform data enrichment on existing index asset data by regularly querying data enrichment sources. This should only be done as batch processing as this information will not change frequently and might not be required immediately. However, Aggy should be able to query data enrichment sources on demand. This can be implemented as a pull or a push model or a combination.
- Provide an API access to the indexed data. API would be the primary method to consume JEAM data. Dashboards and additional applications can be built on top of that API.
Data Enrichment Sources(DES): Data enrichment sources add additional context to the asset. DES can be the HR or LDAP system, etc. These additional data fields add context to the asset including the business unit of the primary user, Operating System, primary application supported, whether this is an assigned corporate device, etc. Overtime external footprint data can also be added as a source. Once this is added JEAM should provide external and internal asset view of an organization.
The base JEAM system should immediately provide a reliable source of asset inventory within the organization. This might become the single source of truth for incident response, operational support, asset inventory metrics, project and capacity planning etc.
The next article will cover how JEAM can be extended to support User Behavior Analytics(UBA), Zero Trust models, holistic and proactive vulnerability management, Incident Detection, threat hunting and Risk Management.
Feedback to improve JEAM’s architecture can be shared directly with the author.
Hemanth Srinivasan, Vincent Samuel, Siddharth Vangavaragu, Akash Malwa and Drew Miller have contributed to the design of JEAM.
