Asset Security

1.1 What is an asset?

Every organization relies on three kinds of resources. Materials are inputs consumed by a production process (components, plastics, packaging). Supplies are consumables that keep the business running (paper, ink, office supplies). Assets, by contrast, stay with the organization and carry lasting value: they are what security protects.

An asset can be tangible (server, building, storage media) or intangible (idea, data, procedure, intellectual property). The central point of Domain 2 is that information holds value the moment it is conceived, even before it is written down. A database illustrates this layering: the data is one intangible asset, the DBMS that manages it is another, the server that hosts it is a tangible asset, and the procedural know-how in the employee's head is a tacit asset.

Identifying assets, especially information assets, is therefore the first act of any security program. You cannot protect what you have not inventoried.

1.2 Classification vs categorization

The two words are often confused, and that is a recurring exam trap. Classification is primarily about access: it recognizes the impact of a compromise (confidentiality, integrity, availability, but also authenticity, non-repudiation, privacy, safety) and is derived from the organization's compliance mandates. It is the world of 'Secret', 'Top Secret', 'Confidential' labels.

Categorization is primarily about impact: it is the process of grouping sets of data with comparable sensitivities and similar protection needs mandated by law, contracts or compliance. The official references are NIST SP 800-60 and FIPS 199, which categorize impact as low, moderate, high.

A phrase to remember: a classification is not a label. The label is part of implementing the controls that protect classified information. For a long time the conversation was limited to the CIA triad; the textbook insists on broadening to CRUD actions (Create, Read, Update, Delete) because creating, updating and deleting data directly affects its integrity, availability and authenticity.

1.3 Schemes and levels: military and private

The military/government scheme has five levels, most to least sensitive: Top Secret, Secret, Confidential, Sensitive but Unclassified (SBU), Unclassified. Each level's compromise maps to a damage degree (exceptionally grave, serious, damage). These communities prioritize confidentiality above all.

The private/commercial scheme usually has four levels: Sensitive, Confidential, Private, Public, most to least sensitive. There is no mandatory nomenclature: each organization names its own levels. The Center for Internet Security, for example, offers a simple three-level scheme (sensitive, business confidential, public) mapping to low/medium/high.

Categorization, by contrast, is not always hierarchical: categories include PII, PHI, proprietary, human safety critical, time-critical, compliance data. A single asset can carry several labels at once, e.g. 'human safety critical, HIPAA, highly restricted'.

1.4 Sensitivity levels, labels and benefits

Beyond the level names, each level captures in a word or two the possible harm if data is compromised. A typical private scale has four notches. Highly restricted: compromise could threaten the organization's very existence, even lead to loss of life, damage and the litigation that follows. Moderately restricted: loss of temporary competitive advantage, revenue, or disruption of planned investments. Low sensitivity (often 'internal use only'): compromise causes only minor disruptions or delays. Unrestricted public: data already published, no further harm possible.

Categorization labels, by contrast, do not necessarily rank from worst to least: they reflect the source or nature of the requirement. Examples: human safety critical (risk of death or injury), equipment/property safety critical (physical damage), PII critical (identifies a person), private data (distribution limited by agreement), proprietary data (internal business logic), compliance data (specific legal or contractual requirements), time-critical data (a delay makes an activity fail). A single asset can stack several labels, e.g. 'human safety critical, HIPAA, highly restricted'.

Classifying well brings benefits beyond protection: awareness among employees and customers of the organization's commitment, identification of critical information and its vulnerability to modification, focus on integrity controls, understanding the value of information, and meeting legal requirements.

1.5 Classification criteria and issues

To set a classification, the asset owner answers a series of questions: who must access the data and under which roles? How is the data secured by default (open or off-limits)? How long must it be retained (e.g. seven years in finance)? How will it be destroyed? Must it be encrypted? What use is appropriate (internal, restricted, public)?

Classification is driven by the asset owner because they understand the asset's value. They may delegate the task (the responsibility) but never the accountability: they remain answerable for protection. The classic analogy is the ship's captain, who may delegate operation to a watch officer but remains ultimately accountable for the ship, crew and cargo.

Errors lurk: human error, inconsistent methods, arbitrary or capricious determinations, confusing or incomplete labeling. Inconsistent classification makes all security rules look arbitrary and destroys trust. When the data owner lacks knowledge, they tend to over-classify out of caution, needlessly inflating costs; a classification board with the right expertise corrects that bias.

2.1 Marking, labeling and enforcement

As with physical assets, classified information assets must be clearly marked and labeled. Ideally systems enforce those labels automatically - but in practice that only happens in mandatory access control (MAC) systems. Discretionary access control (DAC) systems do not enforce labels uniformly, and labels may be lost as information moves from one system to another.

A media label must show the sensitivity of the information, state whether the media is encrypted, and may carry a point of contact and a retention period. The golden rule seen earlier: media found without a label is labeled at the highest sensitivity until analysis proves otherwise.

Traditional marking (physical labels, color codes) is still relevant for removable media and paper documents. On the digital side, productivity suites are starting to use keyword scanning and sentiment analysis to spot incorrect labels, but these techniques are not yet widespread.

2.2 Handling and storage of sensitive media

Only designated personnel should access sensitive media, and handling procedures must be distributed and taught. The security professional must remember that unencrypted media offers no digital accountability: heightened vigilance is required.

Storage combines physical and logical controls. Backup media should be encrypted and kept in a secure container (a safe). A separate encrypted off-site copy is recommended for disaster recovery, while on-site backups are placed in a fire-resistant box. In all cases the number of people with access to media is strictly limited, and separation of duties plus job rotation are implemented where cost-effective.

2.3 Declassification and end of life

Declassification lowers an asset's sensitivity level. Marking, handling and storage requirements must then be adjusted accordingly, and the owner plays a central role in that decision. The process may rely on obfuscation techniques such as de-identification (removing identifiers) or tokenization (replacing a sensitive value with a token).

Media no longer needed or defective must be destroyed rather than simply discarded. A destruction record is kept, consistent with media-handling logs. When a medium's sensitivity is unknown, apply object-reuse controls rather than recycling it as is: you must ensure no exploitable residue remains.

3.1 The IT Asset Management Life Cycle

Two lifecycle models frame information security: the IT Asset Management Life Cycle (hardware, software, data) and the Data Security Life Cycle (the data itself). The first has five major stages.

Planning: align the asset with objectives, identify and value it (total cost to acquire and operate, expected revenues, competitive advantage, potential harm if compromised). It is also when security needs are assigned via classification and categorization. Acquiring: acquire or develop the asset, baking in the identified security requirements from design. Deployment: put into service, train users and support on security aspects. Managing: operate and monitor continuously (do controls still work? has the threat landscape shifted?), plan recovery and archive. Retiring: retire the asset, handling destruction and remanence, and briefing staff.

Two paths lead to management: a deliberate, requirements-driven path, and a discovery path (systems enumeration, baselining) for pre-existing assets. Both converge on the same first step: making the inventory.

3.2 Inventory, ITAM and CMDB

The asset inventory lists all physical and virtual assets: hardware, software, data. IT Asset Management (ITAM) is the set of governance and management practices for those assets; the reference standard is ISO 19770.

The Configuration Management Database (CMDB) goes beyond a plain list: it records the make, model, serial number, type and version of each asset. It traces not only what you own but also how it is configured, and provides a restoration point (e.g. to rebuild a user's workstation to the right version, hardware and software included).

A subtle point stressed by the textbook: enumeration tools can tell which applications are installed and where files reside, but they cannot spot an information asset in the business sense - for example 'the annual budget', scattered across databases, spreadsheets and emails. That is why the information-asset inventory is also built top-down, from critical business processes. And the register itself is an asset to protect.

3.3 Ownership: owner accountable, custodian executes

Identifying a responsible owner is a central act of asset management. The asset owner (or information owner, or information steward) imposes security and quality requirements for the asset: they decide who accesses it and at what permission level, how long it is kept, whether it may be shared. They do not build or maintain the controls themselves - it is a business function - but they are accountable.

Typical owner responsibilities: determine the information's impact on the mission, estimate its replacement cost, decide who needs access and under what release criteria, and know when information is inaccurate or should be destroyed.

The data custodian executes day to day: protecting, maintaining and keeping data accessible to the right operators. Their tasks: adhere to data policy, ensure access while maintaining the security level, perform fundamental maintenance (storage, archiving), document, and validate quality through periodic audits. The exam rule: the owner DECIDES, the custodian EXECUTES.

4.1 The Data Security Life Cycle

Data goes through six major stages. Create: generating or acquiring content - the preferred moment to classify, since controls depend on that classification. Store: committing to media, most often at the same time as creation; apply encryption, access control, logging, redundancy by classification. Use: data is read, processed, modified; often the most vulnerable state because it is in clear text; rely on DLP, DRM and access control. Share: information is shared with others; once shared, it escapes the organization's control, so share only by classification and with authorized recipients; DLP detects unauthorized sharing, DRM keeps control. Archive: data leaves active use for long-term storage; retention challenges (will the media still be readable in ten years?), protection maintained by classification, legal requirements. Destroy: defensible destruction, per written processes, by authorized personnel.

These stages are not a rigid sequence: creation comes first and destruction last, but storage, use, sharing and archiving chain in any order, as many times as needed. The model is a framework to map controls onto each phase.

4.2 Data roles (GDPR and NIST)

Data protection requires a clear distinction of roles, their accountabilities and responsibilities. NIST SP 800-18 and the GDPR give comparable definitions.

Data subject: the natural person described or identified by the data. Data controller: determines the purposes and means of processing; accountable, ensures all obligations (GDPR or other) are met; negotiates data processing agreements with processors. Data processor: performs processing on the controller's behalf (acquire, use, modify, dispose); may be responsible for protecting the data, but accountability stays with the controller. Data owner: decides who accesses at which levels, ensures quality, integrity and protection; takes or delegates the controller role. Data steward: responsible for content, context and business rules of the data. Data custodian: protects the data while in their custody (safe transport, storage, processing). Data protection officer (DPO): advises on compliance and interfaces with supervisory authorities; becomes mandatory when the organization processes sensitive data (health, genetics, origin, religion).

The accountability hierarchy is the key: the subject has a reasonable expectation of privacy and integrity; the controller answers for everything; the processor is never accountable in the controller's place.

4.3 Collection, location and maintenance

Data collection is the first phase: creating and acquiring content, updating existing content. This is where data owners are appointed and classifications assigned, to apply the right controls as early as possible. Secure-defaults and privacy-by-design principles apply from this phase.

Data location and localization become critical with the cloud. Where to store data depends on local law, especially for personal data treated differently across countries. Before collecting, map local and global requirements: allowed storage locations, expected protection mechanisms, retention periods. Some data-localization laws can even gate the decision to operate in a region: expansion into a new market may be slowed by costly local requirements.

Data maintenance aims to preserve confidentiality, integrity and availability across the data's life, via controls fit for each state. Data at rest, seemingly the easiest to protect, still requires identifying all repositories, encrypting, managing access and backing up. This phase is also where the eternal functionality-versus-security trade-off is arbitrated.

5.1 Data retention: neither too much nor too little

Information should be kept only as long as required. Industry standards, laws and regulations set durations (e.g. seven years in finance). Absent external requirements, the organization defines its own retention policy, applicable to paper and digital copies alike.

Retention has two bounds. Minimums are imposed by law or contract: keeping less is non-compliance. Maximums stem from minimization: keeping longer than needed raises storage cost, exposure risk and 'noise' in searches, and may violate external requirements. The classic mistake is to take the longest retention period and apply it blindly to everything: that is waste and risk.

A sound retention policy follows eight steps: evaluate legal, litigation and business requirements; classify record types; determine periods and destruction practices; draft and justify the policy; train staff; audit retention and destruction practices; review periodically; document policy, implementation, training and audits. To execute all this, an accurate inventory is essential (location, period, destruction requirements of each asset).

5.2 Data remanence: what remains

Data remanence is the residual representation of data on a medium after a supposed erasure. Insufficient deletion can compromise information. Almost all equipment retains data after the processing step: CPU or GPU registers, RAM, temporary files, display circuitry hold values until overwritten, from milliseconds to several minutes after power is removed.

The crucial point: deleting a file does not actually remove the data. The system merely marks the directory entry as deleted and returns the space to the free list; the data stays physically present until overwritten. That is why a disk 'emptied' by simple deletion remains recoverable with the right tools. Temporary files are an often-overlooked source of remanence.

5.3 Destruction methods and media choice

The official reference is NIST SP 800-88 (Guidelines for Media Sanitization). Methods escalate by assurance level. Clearing: rewrite patterns (often random) across the whole medium. 'Zeroizing' (writing zeros) is a variant, but with the risk that a missed block stays recoverable. Clearing protects against recovery via normal system functions and suffices in many operational environments. Purging: strongly eliminate the chance of recovery, even in a lab. Degaussing (a powerful magnetic field) belongs here - but it applies only to magnetic media (HDD, tapes) and also destroys the servo track, making the disk unusable. Physical destruction: shredding, incineration, pulverizing, acid - the ultimate remedy to remanence.

The major trap: degaussing does NOT work on SSDs (flash memory, non-magnetic). For an SSD, prefer crypto-shredding (destroy the encryption keys to render data unusable) or physical destruction. Finally, defensible destruction requires all this to be conducted per written processes, by authorized personnel, and traced - otherwise the destruction is not legally defensible.

6.1 The three states: at rest, in transit, in use

Data at rest: data stored on media, neither transmitted nor processed. The risk is unauthorized physical or logical access to the medium. The reference protection is encryption (algorithms limiting access to key holders), complemented by access controls, redundancy and backups. Removable media and mobile devices (laptops, tablets, smartphones, wearables) must be encrypted.

Data in transit (or in motion): data moving, typically over a network, not being processed. The risk - the same as data at rest - is interception, modification, unavailability. The protection is encryption, at the data level, network level, or both. Sensitive web interfaces use TLS; SSL, in all its forms, is considered breakable and deprecated. Email is not secure by default (sent in clear text): use PGP or S/MIME. Off the web, encrypt at the application level, or failing that at the network level via IPSec or SSH tunnels.

Data in use: data processed by software, hardware or a user. It is the hardest state to protect because the data must be in clear text for its structure and values to be readable. The main controls are access control, auditing and non-repudiation. A trivial example of risk: the over-the-shoulder attack, where a bystander reads a user's screen.

6.2 Link vs end-to-end encryption

Data is encrypted over a network in two ways. Link encryption is done by carriers: it encrypts all data along a communications path (satellite link, telephone circuit, T-1 line), including routing information. Consequence: each node must decrypt to keep routing, then re-encrypt. An attacker compromising a node can therefore see the message in clear there. In return, since routing is encrypted, link encryption offers better traffic confidentiality: it hides addressing information and prevents inferences about the existence of exchanges between two parties.

End-to-end encryption is done by the end user: data is encrypted at the source and only decrypted at the destination. It stays encrypted across the network, but routing information remains visible. A VPN is an example. The trade-off is the reverse of link encryption: better end-to-end content protection, but routing stays observable.

6.3 Protecting data in use: enclaves

Protecting data during processing is the hardest challenge, since it must be decrypted to be processed. The industry approach is the secure enclave: a zone isolated from the rest of the architecture where processing happens. Data is still processed in clear text there, but the enclave is designed to be impervious to vulnerabilities and malware present elsewhere in the system. The word 'enclave' indeed denotes a territory isolated from another.

Beyond enclaves, classic controls remain relevant: strict access control, logging and auditing to detect abnormal use, non-repudiation. Detecting usage anomalies, combined with forensic techniques, uncovers fraud and abuse. The risk remains: accidental or malicious alteration, unauthorized exposure (the over-the-shoulder attack being the simplest example).

7.1 Control types and defense in depth

To protect assets, you combine three broad control types. Administrative controls are policies, procedures, standards and training - the human and organizational framework. Technical (or logical) controls are implemented by technology: encryption, access control, DLP, logging. Physical controls protect the environment: locks, badges, cameras, environmental controls.

Controls also sort by mode of action (preventive, detective, corrective, deterrent, recovery, compensating), but that categorization is not absolute: a single control can fall into several categories depending on its implementation.

The key point for asset security: relying on a single control type or category creates a single point of failure. By combining several types and categories, you force the attacker to prepare multiple attack paths instead of one - that is defense in depth, which deters, slows down and raises the chance of detecting an attack.

7.2 Baselines: the minimum reference

A security baseline is a minimum level of protection serving as a reference point. It ensures that any evolution of technology or architecture stays above an understood, accepted threshold. Once controls are in place, everything is measured against the baseline.

Baselines break down by classification level. If you classify as high, medium, low, you define a baseline for each: for example, high = strong passwords + NDA + 128-bit symmetric encryption for creation, storage and transmission + watermark + real-time monitoring; low = simple owner-approved access process, no encryption, no labeling, no monitoring. Baselines can also be technical (the minimum configuration of a Windows machine before joining the network) or non-technical (wearing a badge, escorting visitors). In short: a baseline is a consistent reference point, defining the minimum required and breaking down into per-architecture configurations.

7.3 Scoping and tailoring

You rarely adopt a framework as is: you scope and tailor it to your context. These two operations are distinct and frequently confused at the exam.

Scoping: the process of determining which controls apply and to which assets, by removing from the general baseline the recommendations that do not apply. Several considerations influence how controls are applied; the system security plan must clearly identify which controls were scoped and describe the decisions made, approved by the authorizing official.

Tailoring: the process of modifying the control set to fit the organization's specific characteristics and requirements. It gives more flexibility and avoids costly or needlessly complex approaches. Formally, tailoring includes applying scoping, specifying compensating controls if needed, and defining organization-specific parameters. Remember: scoping REMOVES what does not apply, tailoring ADJUSTS what remains.

7.4 DLP, DRM and CASB

Data Loss Prevention (DLP) groups the controls that keep certain data compliant with policies. It rests on three components: discovery & classification (map and automatically classify data), monitoring (watch usage across locations and platforms, the key function), enforcement (interrogate data and compare its location, use or destination against policies, then alert, log, block, reroute or encrypt). DLP depends heavily on reliable data identification: without prior discovery, classification and labeling, it is much harder to operate. It is one of the few technologies effective against insider threat.

Three deployment topologies, aligned with states: Data in Motion (network/gateway DLP, near the gateway, watching HTTP/HTTPS/SMTP/FTP), Data at Rest (storage DLP, where data is stored), Data in Use (endpoint/client DLP, on workstations). DRM (Digital Rights Management) encrypts data within the file itself (format-preserving) and controls its use, modification and distribution across the intellectual property's life; if DLP does not integrate with DRM, it cannot read the protected files. Finally, the CASB (Cloud Access Security Broker) is a control point between the cloud consumer (CSC) and provider (CSP); it provides four functions - visibility, data security, threat protection, compliance - and deploys as a forward proxy, reverse proxy or via API.

7.5 Selecting compliance standards

Organizations adopt standards (sometimes called frameworks) to structure their security posture, understand baseline controls and assess their maturity. Depending on activity, some are mandatory (law or regulation): PCI DSS for card data, HIPAA for health, GDPR for European personal data. On steering frameworks: NIST SP 800-37 (Risk Management Framework), NIST Cybersecurity Framework, NIST SP 800-53 (control catalog), ISO 27001/27002 (ISMS), plus entities like ENISA or the ITU.

The professional must know this landscape and that contractual or legal requirements can directly dictate a control (PCI DSS mandates encryption of card data, for instance). You rarely adopt a framework wholesale: you implement parts of it through scoping and tailoring, to target genuinely relevant risks without waste. The overall Domain 2 logic closes here: classify to know value, choose a baseline by that value, scope and tailor to fit it, and enforce it all with the right technical and compliance controls.