Asset Registry

Asset Registry

KScope "Asset Registry": Bridging Static and Dynamic Asset Management

While dynamic asset intelligence is the future, static inventories still have an important role — especially for legacy systems, non-networked assets, and manually tracked items (like sensitive physical devices or contracts tied to IT assets). Recognizing this, KScope "Asset Registry" provides a user-friendly interface that allows teams to manually model, create, and manage static asset records easily.

Key Features for Static Inventory Management:

  • Intuitive Entry and Modeling: Users can manually input asset details — hardware specs, ownership, location, business criticality, lifecycle stage — through a clean, guided interface.

  • Custom Asset Classes and Attributes: Teams can define asset types and fields that match their unique organizational needs, beyond out-of-the-box templates.

  • Data Quality Controls: KScope offers validations and enrichment suggestions even for manually entered data, ensuring higher accuracy and consistency.

  • Static-to-Dynamic Correlation: Static entries are not isolated — KScope automatically correlates manually entered assets with those discovered dynamically from live integrations (e.g., endpoint management, cloud accounts, network scans, vulnerability management tools).

Unified Asset Intelligence: Static + Dynamic Together

With KScope, organizations are no longer forced to choose between static or dynamic inventories — they can combine both for a complete, continuously enriched view of all assets:

  • If an asset is entered manually, and later detected dynamically (via integrations or scans), KScope links the records to avoid duplication and improve completeness.

  • If an asset is discovered dynamically but lacks contextual metadata (like business owner, criticality, regulatory tags), users can manually augment the record within Asset Registry.

  • If an asset is only available manually (such as offline industrial control systems, air-gapped servers, or unscanned IoT), it remains trackable and policy-enforceable through the platform.

This hybrid approach ensures that no asset is left unaccounted for, no matter how it enters the environment or how difficult it is to track.

Why This Matters

Organizations operate in a world where not every asset can be automatically discovered — but every asset still matters for compliance, cost management, and security posture.

By supporting both static input and dynamic discovery — and intelligently correlating them — KScope "Asset Registry" delivers:

  • Greater Inventory Completeness: Capture 100% of the asset landscape, not just what's discoverable via scans.

  • Stronger Security Foundations: Know what you have, how it's configured, and how it's changing — at all times.

  • Operational Efficiency: Reduce redundant data management efforts by automatically linking and enriching asset records.

  • Improved Decision-Making: Leverage a single source of truth for assets across IT, security, compliance, and procurement functions.

Overview of Asset Modeling Concepts in KScope "Asset Registry"

The KScope Asset Registry is built on a graph database model to systematically store, manage, and represent digital assets and their interrelationships. Its conceptual foundation is structured around a set of modeling constructs that together enable scalable, flexible, and rich asset management.

The key modeling constructs are:

  • Element Type (Vertex Type): Defines the schema (properties, structure) for an asset category, such as Server, Application, or Database.

  • TypeFunction: Groups multiple Element Types into logical categories, such as "Infrastructure" or "Software," to organize assets based on their purpose.

  • Element (Vertex): A concrete instance of an asset, populated with values according to its Element Type schema.

  • Module: Represents an external data source (e.g., AWS, Azure, ServiceNow) that supplies or synchronizes assets into the registry.

  • Domain: Provides logical grouping of assets based on organizational, departmental, or business needs.

  • TypeUnit: Specifies units of measure for numeric properties, ensuring standardization and clarity (e.g., GB for storage).

  • ElementAttribute: Stores the actual property values of an Element.

  • ElementAttributeType: Defines the types of attributes that Elements of a specific Element Type can have.

  • Relationships (Edges): Model dependencies and interactions between assets, such as an application running on a server, along with any properties tied to those relationships.

Each concept plays a crucial role in making the Asset Registry highly adaptable, context-aware, and integration-ready — essential features for managing the complexity of modern digital environments.

Table of Concepts and Their High-Level Descriptions

Concept

High-Level Description

Element Type (Vertex Type)

Defines the schema/blueprint for a category of assets, specifying their structure and properties.

TypeFunction

Groups related Element Types into logical or functional categories for better organization.

Element (Vertex)

A specific instance of an Element Type; represents an actual asset in the system.

Module

Represents an external system or source (e.g., AWS, ServiceNow) from which asset data is sourced.

Domain

Organizes Elements into logical groups for business or organizational needs (e.g., departments).

TypeUnit

Defines the unit of measurement for numerical properties (e.g., GB, MB, USD).

ElementAttribute

Captures actual data values of an asset’s properties.

ElementAttributeType

Defines the allowable property types for each Element Type.

Relationship (Edge)

Represents a connection or dependency between two assets, possibly with additional metadata.

🌐 Example: Modeling IT Assets for a Company’s Finance and HR Departments

Scenario

A company wants to manage its IT assets — servers, applications, and databases — using the KScope Asset Registry. These assets are sourced from external systems like AWS (for servers) and ServiceNow (for applications and databases). The company has two departments: Finance and HR, and they want to keep their asset data logically separated.

🔑 How the Asset Registry Modeling Concepts Apply

Modeling Concept

Example Use in the Scenario

Element Type (Vertex Type)

Think of this as the blueprint or template for each kind of asset. Example types: Server, Application, Database Each has specific properties: e.g., Server → {name, IP, storage_capacity}

TypeFunction

Groups similar Element Types. Infrastructure groups Servers, Software groups Applications and Databases.

Element (Vertex)

These are the actual, real-world assets. e.g., Server_001, PayrollApp, HR_DB

Module

Indicates where the data came from. e.g., AWS provides Server_001, ServiceNow provides PayrollApp, HR_DB.

Domain

Segregates data for organizational units. Finance domain holds PayrollApp and Server_001 HR domain holds HR_DB and Server_002

TypeUnit

Ensures consistency in numeric data. storage_capacity and size use unit GB.

ElementAttribute

Actual data values for an Element. e.g., Server_001 → name: Server_001, IP: 192.168.1.10

ElementAttributeType

Specifies which attributes each Element Type should have. Server should have IP, name, storage_capacity.

Relationship (Edge)

Links assets to show their interaction. e.g., PayrollApp → RUNS_ON → Server_001 HR_DB → HOSTED_ON → Server_002

🔄 Full Example Breakdown

1. Element Types

Server: {name, IP, location, storage_capacity}  
Application: {name, version, owner}  
Database: {name, type, size}

2. TypeFunctions

Infrastructure: Server  
Software: Application, Database

3. Modules (data sources)

AWS: Source for servers  
ServiceNow: Source for applications and databases

4. Domains (business groupings)

Finance: Server_001, PayrollApp  
HR: Server_002, HR_DB

5. Elements (instances of asset types)

Server_001 (from AWS): Server at Data Center A, 500GB  
PayrollApp (from ServiceNow): version 2.1, owned by Finance  
Server_002 (from AWS): Server at Data Center B, 1000GB  
HR_DB (from ServiceNow): MySQL database, 200GB

6. TypeUnits

storage_capacity → GB  
size → GB

7. Relationships

PayrollApp --RUNS_ON--> Server_001 (since: 2023-01-15)  
HR_DB --HOSTED_ON--> Server_002 (since: 2023-02-01)

✅ Summary

This example demonstrates how:

  • Element Types define what kinds of things you track.

  • Elements are the actual things.

  • Modules tell you where the asset data comes from.

  • Domains tell you who owns or manages the asset.

  • TypeUnits make sure numbers like storage sizes are consistent.

  • Relationships connect assets into a meaningful graph — e.g., apps depend on servers.

The result? A flexible, richly connected asset graph that accurately reflects your IT environment — and scales across teams, tools, and technologies.

PreviousSettingsNextElement Type

Last updated

Was this helpful?