Context & Asset Identification
Purpose
This page defines what is considered in scope within Scheol Security Lab and how relevant assets are categorized for governance and risk documentation purposes.
Its objective is not to produce an exhaustive technical inventory, but to structure the environment in a way that supports threat-scenario modeling, risk reasoning and control traceability.
Asset identification is therefore used here as a decision-support foundation, not as a purely administrative listing exercise.
Scope Context
Scheol includes both externally exposed services and internally hosted infrastructure, supported by a growing set of administrative, monitoring, identity and documentation-related capabilities.
From a governance and risk perspective, this means the environment must be documented across multiple layers, including:
- externally reachable services and supporting systems
- internal infrastructure and trust zones
- administrative and privileged access paths
- supporting security and operational platforms
- information assets relevant to confidentiality, integrity and availability
- documentation and governance-related artifacts
This context is important because risk exposure in Scheol does not come from a single system, but from the relationships between these elements.
Asset Classification Model
Scheol uses a simplified asset model structured around four main categories:
- Business Assets
- Infrastructure Assets
- Platform Assets
- Information Assets
This classification is used to help distinguish:
- what the lab is intended to support
- what enables it technically
- what services or control layers operate within it
- what data or information requires protection
This layered model makes later threat and risk documentation easier to structure and review.
Asset Categories
Business Assets
Business assets represent the capabilities or operational functions that the lab is intended to support from a security and governance perspective.
They help explain why the environment exists and what it is expected to enable.
Examples include:
- secure administrative access
- identity and access management
- security monitoring and detection
- infrastructure administration and maintenance
- governance and security documentation
- backup and recovery support
These assets are not tied to a single technical component, but are typically supported by multiple infrastructure, platform and information assets.
Infrastructure Assets
Infrastructure assets represent the foundational hosting, network and connectivity components required to operate the environment.
These assets form the underlying technical base on which the rest of the lab depends.
Examples include:
- virtualization hosts
- network security gateways
- segmented internal network areas
- externally hosted infrastructure
- core network and connectivity components
These assets are particularly important from a resilience, exposure and dependency perspective.
Platform Assets
Platform assets represent the services, applications or supporting operational layers used to deliver security, administrative or technical capabilities within the lab.
These assets often act as intermediaries between infrastructure and information.
Examples include:
- identity-related services
- administrative access platforms
- monitoring and logging services
- automation and configuration platforms
- documentation and internal service platforms
- backup and operational support services
These assets are often central to control implementation, observability and administrative trust relationships.
Information Assets
Information assets represent the data, records, secrets or operational information that require protection.
They are documented primarily from a confidentiality, integrity and availability perspective.
Examples include:
- configuration and infrastructure data
- credentials and authentication material
- backup data
- log and event data
- administrative records and documentation artifacts
- personal or identity-related data where relevant
These assets may exist across several systems, but should ideally be traceable to a primary or authoritative source whenever possible.
Dependencies & Relationships
Assets within Scheol are not treated as isolated elements.
Infrastructure supports platforms, platforms process or expose information, and together they enable higher-level security and operational capabilities.
For that reason, asset documentation should progressively reflect:
- dependencies between supporting components
- trust relationships between systems or zones
- exposure paths affecting reachable or sensitive assets
- capability links between technical assets and higher-level functions
This relationship-oriented view is important because many relevant risks emerge from how assets interact, not only from how they exist individually.
Ownership & Responsibility
For documentation consistency, each asset is associated with a simplified ownership model.
This ownership is not intended to represent a formal enterprise structure, but to clarify who is considered primarily responsible for a given area.
| Asset Area | Primary Role |
|---|---|
| Infrastructure assets | Operations Role (Ops) |
| Security-oriented platforms | Security Role (Sec) |
| Development / automation-related platforms | Development Role (Dev) |
| Information assets | Assigned according to the system or function responsible for their handling |
This simplified model is used to support accountability, maintenance logic and later risk ownership where relevant.
Current Maturity
At the current stage, asset identification is considered partially established.
Established
- overall asset classification logic
- high-level scoping of core infrastructure and support capabilities
- initial ownership structure
- initial documentation of key dependency areas
In Progress
- deeper mapping of relationships and supporting dependencies
- consistency of categorization across all documented components
- identification of authoritative sources for information assets
- improved traceability between assets, controls and risk scenarios
Planned / Next Phase
- more complete dependency mapping across future infrastructure components
- stronger linkage between asset classification and control coverage
- broader support for validation and evidence traceability
This page is therefore intended to evolve as the environment and its documentation become more complete.