Computer security

Computer security studies how to preserve intended properties of information and computing systems against failures and adversarial actions. Confidentiality limits disclosure, information integrity limits unauthorized changes, and availability concerns continued access to intended services. Authentication establishes an identity or source claim; access control decides permitted actions. A design needs an explicit threat model: encrypting stored data addresses different risks from verifying who may alter it. Security properties depend on the whole interaction between software, hardware, protocols and operational assumptions.

Malware is software or code intentionally used for an unauthorized harmful purpose, such as disclosing data, altering it or disrupting access to a computing system. Computer viruses and computer worms are types of malware, but self-replication is not required for every malicious program. The classification concerns purpose and behavior, not merely whether a computer program contains a bug.^[ref]

A useful distinction separates what a program does from how it spreads. Replication, unauthorized disclosure and destructive changes are different properties. A computer worm can disrupt a system through replication-related resource use; another malicious program might disclose data without producing copies of itself.

For an original classification example, suppose three hypothetical programs produce the same unexpected loss of a test file. One has an accidental defect, one implements an authorized deletion request, and one intentionally deletes data without authorization. The visible outcome alone does not establish that all three are malware. Intended function, authorization and behavior supply different evidence.

Likewise, finding a familiar byte sequence in a file is a detection clue rather than a complete behavioral explanation. Digital forensics connects observed artifacts with supported conclusions; a label by itself does not reconstruct an incident.

A computer virus is self-replicating code that propagates by becoming part of host computer programs or suitable files. Its replication depends on the host's execution context. This distinguishes it from a self-contained computer worm, although both are conventionally grouped as malware.^[ref]

Replication and any additional harmful effect are separate features. A computer virus can make unauthorized changes simply by incorporating itself into another host; a dramatic data-destruction effect is not necessary to recognize that replication mechanism.

For an original counting example, imagine ten archived copies of the same infected host file on an isolated storage medium. That is ten stored artifacts, not evidence of ten running processes or ten infected computers. Conversely, one executing host can affect more than one stored artifact. Counts of detected files, affected machines and active executions measure different things.

The biological analogy is useful only in a limited sense: a computer virus depends on a host context for reproduction, but its mechanism is computation and file modification. Digital evidence about copies and execution should support the particular incident claim being made, rather than treating every occurrence of a byte pattern as a separate observed infection event.

A computer worm is a self-contained computer program that propagates by creating further copies across computing systems, often through a computer network. In the usual security classification it is malware. Unlike a computer virus, it need not attach its code to another program in order to replicate.^[ref]

A worm's impact can include resource exhaustion from replication itself, independently of any additional destructive action. Eugene H. Spafford's analysis of the November1988 Internet worm is an early primary study of a large network incident and its program behavior.^[ref]

An original population model shows why replication matters. Suppose each affected machine remains affected and produces exactly one newly affected machine per time interval, with no overlap or shortage of susceptible machines. If $I_t$ counts affected machines, thenThis stipulated exponential growth model is not a forecast of a real outbreak. Repeated contacts, limited connectivity and containment change the growth pattern. It separates the potential for multiplying copies from the behavior of any particular implementation.

The concept is useful in computer security because one compromised machine can become a source of further disruption. Network structure and the timing of defensive containment matter alongside the behavior observed on an individual host.

Data sanitization is a process intended to make recovery of specified data from a storage medium infeasible at a stated level of effort. The target data, medium and recovery capability are part of the claim. Ordinary file deletion may remove a file system entry while leaving content recoverable; disappearance from a directory is not evidence of sanitization.^[ref]

The NIST framework distinguishes clear, purge and destroy: they address different recovery capabilities and whether the medium remains usable. The appropriate method depends on the medium and the information-protection objective. A device-independent slogan such as “deleting a file removes all its data” ignores those conditions.^[ref]

A primary study by Simson Garfinkel and Abhi Shelat examined158 second-hand hard disk drives and found residual information on some readable devices. The study distinguished unreadable drives and warned that its sample was small relative to the larger used-drive market.^[ref] It supplies measured evidence of a disposal problem, not a timeless population-wide failure rate.

For an original scope example, suppose a document has one copy on a retired drive and one in an independent backup. Successfully sanitizing the retired drive does not sanitize the backup. The claim concerns the specified copy, not every occurrence of the information.

Similarly, verifying that an operation completed and deciding that its result adequately protects the target data are distinct judgments. The current NIST guide calls these verification and validation.^[ref]

Sanitization validation decides whether a data sanitization outcome is adequate for its intended data-protection objective. It considers the evidence from sanitization verification, the suitability of the method and any relevant errors or anomalies. The result is an acceptance or rejection of the sanitization claim.^[ref]

For an original distinction, suppose a device reports that its selected operation completed successfully, but the method was not suitable for the stipulated recovery capability against which the data was meant to be protected. The operation can have passed its completion check while the sanitization claim is rejected. This is a mismatch between a successful operation and an inadequate objective, not a contradiction between the two assessments.

An invented batch example makes the denominator explicit. Of20 outcomes,19 have successful completion evidence. Of those19, only15 also satisfy the stipulated adequacy criteria. The accepted fraction is then $15/20=75\%$ of the batch, or $15/19\approx 78.9\%$ of the successfully completed operations. Reporting only $19/20$ would answer the verification question while leaving the validation question unresolved.

The scope remains the specified target data on the specified medium. A decision about one device does not establish that a separate backup or another copy of the same information has also been sanitized. Validation connects the observed evidence to a bounded protection claim.

Sanitization verification checks the outcome of an attempted data sanitization operation: whether the technique completed, and whether its result shows errors or anomalies. In the NIST terminology, this is distinct from sanitization validation, which decides whether the outcome adequately protects the target data.^[ref]

The evidence depends on the technique and medium. It may include a tool's completion status, device-health information or inspection of the remnants of a destructive process. A successful status message concerns the operation that was actually attempted; it does not establish that the chosen technique was appropriate.^[ref]

For an original accounting example,20 devices enter an assessment. Nineteen report successful completion and one reports an error. The completion fraction is $19/20=95\%$. That figure is not a95-percent probability that every device is sanitized, nor does it show that each of the19 successful outcomes meets the intended protection objective.

A useful record preserves both the attempted operation and its observed outcome. Without that link, an otherwise plausible completion report could refer to the wrong device or a different attempt. Verification supplies evidence for a decision; it is not a substitute for the decision itself.

Digital forensics is the systematic collection, examination, analysis and reporting of digital evidence to answer questions about events involving computing systems. It supports computer security incident investigation and troubleshooting as well as investigations associated with legal proceedings. Preserving the data and documenting how it was handled make later conclusions assessable.^[ref]

Collection and interpretation are different tasks. A cryptographic hash function can help check whether an acquired file has changed, but a matching digest does not establish who created the file or whether its contents are true. Chain of custody records handling history; it does not replace the analysis of what the evidence establishes.^[ref]

An original clock example illustrates the distinction. System A records an event at10:02 and system B records another at10:01. If A's clock is known to run two minutes fast while B's is correct, their reference times are10:00 and10:01. In symbols,where $\Delta$ is the stipulated clock offset. The apparent order reverses after correction. These invented times demonstrate why comparing log entries requires a clock model; they do not identify the actor responsible for either event.

A useful report therefore separates observed data, transformations such as clock correction, assumptions and conclusions. Missing records or uncertain offsets can leave several explanations consistent with the same digital evidence.

In digital forensics, a chain of custody is the documented history of who possessed or handled an item of digital evidence, when transfers occurred and what actions were taken. It connects an analyzed item with its recorded collection and subsequent handling. The record concerns provenance and accountability, while data integrity concerns whether the relevant data changed.^[ref]

For an original example, an evidence drive is recorded as collected by A at09:00, transferred to B at10:00 and delivered to C at12:00. If B's receipt and transfer record are missing, matching serial numbers at the endpoints do not explain what happened during the intervening interval. That is a gap in documentation, not by itself proof of alteration.

A cryptographic hash function supplies complementary evidence about a particular byte sequence. A matching digest can support continuity of the data under the hash function's security assumptions, but does not identify everyone who had access to it. A complete custody log likewise cannot establish the truth of every statement stored on a device.

A useful record therefore distinguishes the physical item, any acquired copies and the actions applied to each. Conclusions should state what that record supports; documentation alone does not determine every question about an incident.

Digital evidence is information represented in digital form that is used to support or test a claim about an event. A file, system log or recorded computer network activity can supply such information. An artifact becomes evidence through its relation to a question and the explanation of how it was obtained and interpreted; being stored on a computer does not make its contents true.^[ref]

Digital forensics separates collection from analysis. Chain of custody documents handling, and cryptographic hash functions help check continuity of acquired data. Those checks support the reliability of a particular artifact; they do not by themselves establish its author or the cause of the recorded event.^[ref]

An original mathematical distinction is useful. For a fixed deterministic hash function $h$, if byte sequences $x$ and $y$ satisfythen $x\ne y$. Identical inputs must produce identical outputs. The converse fails: $h(x)=h(y)$ does not logically prove $x=y$, since a fixed-length digest can have collisions. A well-chosen cryptographic hash function makes finding such collisions computationally difficult under its stated security assumptions.

Even exact byte equality is narrower than factual truth. Two identical copies of a log preserve the same recorded assertion, including any inaccurate clock value or fabricated entry already present. Interpretation must connect the artifact to independent context and identify uncertainty.

Information integrity concerns preserving information against unauthorized alteration or destruction under a stated policy, and detecting violations when they occur. It is distinct from confidentiality: a public record can require strong integrity even though everyone may read it.^[ref]

For example, a downloaded scientific dataset can be checked against a trusted checksum to detect accidental corruption. If an attacker can replace both the dataset and its published unprotected hash, that check does not establish authenticity. A message authentication code uses a secret key, while a digital signature permits verification with a public key. These mechanisms protect particular data and contexts; an authorized but mistaken measurement can retain its cryptographic integrity while still being scientifically incorrect.

A threat model states what is being protected, which adversarial actions are considered, which assumptions are trusted and which security properties must hold. A trust boundary marks where data or authority crosses between differently trusted parts. The model guides design and evaluation rather than treating every possible failure as equally relevant.^[ref]

For example, encrypting a database backup protects its contents from someone who obtains only the stored backup. That mechanism does not by itself stop a logged-in administrator from replacing live records, or an endpoint from disclosing data after decryption. Adding those capabilities to the attacker changes the model and may require authorization checks, integrity protection and audit evidence. An explicit model makes the scope of a security claim inspectable.

A trust boundary separates components or actors to which a threat model assigns different trust or authority. Data crossing it must be checked under the receiving side's rules. A boundary can exist between a browser and server, between two operating-system processes, or inside one application.^[ref]

For example, a browser sends a requested record identifier to a database-backed service. The service must check both its format and the requester's authorization to access that record. Hiding the identifier in a GUI widget does not establish either property: an attacker can send a different request. Identifying the trust boundary makes the required checks visible before choosing a security mechanism.

A moderately expensive computation whose result can be checked cheaply. Request-specific puzzles can mitigate a computational denial-of-service attack if verification precedes expensive service and solved puzzles cannot be reused indefinitely.

An attack on service availability by exhausting resources or preventing useful work. Requiring inexpensive unauthenticated messages to trigger expensive private-key operations creates an amplification opportunity.

Reuse of previously observed valid messages to obtain an acceptance or action in a different context. Cryptographic nonces, fresh session keys and explicit context binding can prevent particular replay patterns.

Obtaining valid responses to a predicted future challenge before that challenge is issued, then delivering them when the predicted value becomes current. Challenge uniqueness alone need not establish freshness when challenges are predictable.

A participant whose correct behaviour and protection of secret state are assumptions of a security argument. It can mediate authentication and session key transport, but the protocol still needs to authenticate its responses.

Protection of data against unauthorised or accidental alteration. It is distinct from information confidentiality and service availability.

Protection against unauthorised disclosure of information. Access control can prevent a subject from reading a file, while cryptographic confidentiality protects message contents against specified adversaries using cryptography.

An authorised release of information from a more restrictive protection level to a less restrictive one. Its policy must identify who may release which information, rather than treating every downward flow as acceptable.

Rules and mechanisms deciding which subjects may perform which operations on protected objects. Discretionary access control permits designated owners to grant rights; the Bell-LaPadula model instead constrains information flow by classification.

A security principal is an identity to which an access control system can attribute requests or permissions. It can represent a user, an access-control group, a service or a machine. Authentication establishes a claimed identity; authorization decides which operations that identity may perform.^[ref]

For example, an analysis service can read a file using its own service identity even when a human user initiated the request. The relevant security principal for the file access is the identity carried into that access check, not automatically the human at the keyboard. Explicit identities prevent accidental confusion between who requested an action and whose authority executes it.

An access-control group collects security principals so that a permission can be assigned to the collection rather than copied separately for every member. A file might grant read access to a laboratory group while withholding write access. Changing membership then changes who obtains the group's applicable permissions.

In Unix-style systems, process credentials include group identifiers, including supplementary groups, and file permission checks use the relevant identity information.^[ref] The membership considered for an already running process need not change immediately when an account database is edited. Group names, account membership and the credentials used for a particular access check are therefore related but distinct pieces of state. Grouping users for permissions also does not imply that their processes are one scheduling job.

Authorization decides whether a Security principal may perform a requested action on a protected object under a policy. authentication establishes an identity or source claim; authorization uses that claim together with permissions and context. Successfully proving an identity does not itself confer every operation.

For example, Alice may authenticate to a document service and be allowed to read one file but not overwrite it. The service must check the actual operation and object, not merely whether Alice logged in earlier. In filesystem traversal, permission to search each intervening directory is part of reaching a named file; knowing a pathname alone is insufficient.^[ref] Enforcement must occur at the boundary controlling the operation, because hiding an unavailable button in a graphical interface does not stop a separately formed request.

An access right combining reading and writing, as opposed to a blind write that reveals no existing contents. Its precise meaning is part of the access model.

A classification-based information confidentiality model restricting subject accesses to prevent forbidden information flow. The simple security property restricts reading above clearance; the Bell-LaPadula star property restricts information flow through current reads and writes. It is not a complete data integrity policy.

The Bell-LaPadula model restriction that a subject operating at its current level reads only at or below that level and writes only at or above it. An access combining both operations therefore requires equal levels. Safe changes of current level must also control retained information.

The Bell-LaPadula model restriction that a readable object's classification must not exceed the subject's maximum clearance.

Discretionary access control lets an authorized owner or principal decide which other principals may access an object, subject to the surrounding system policy. A file owner granting another user read permission is a standard example. An access control list can represent grants for named users or access-control groups. This differs from a mandatory policy that ordinary owners cannot override. Permission to read data is not automatically permission to redistribute it, but ordinary discretionary mechanisms may not track all copies once a reader has obtained the contents.

Authentication verifies a claimed identity or the origin of information using evidence accepted by a system. A password demonstrates knowledge of a secret; a signed challenge can demonstrate possession of a private key. It differs from authorization: establishing which user is present does not determine which files that user may read. The relying party must also check freshness and context so an old valid message cannot simply be replayed in a different interaction. A cryptographic assertion is useful only when its issuer, recipient and validation rules are understood.^[ref]

An authentication goal in which both participants establish the identity and relevant participation of the other. Freshness, agreement on parameters and completed participation are separate properties that a protocol should specify.

An identity provider authenticates a subject and issues an identity assertion for another service, the relying party. In federated login, the application trusts specified assertions from a configured provider rather than collecting the user's password itself. The application still validates the assertion's signature, intended audience, freshness and relevant protocol state, and performs its own authorization. A provider account and an application account need not be identical records. Trust in the provider and correct protocol validation are assumptions of the federation, not consequences of the login button's appearance.