Memra

Three scopes, six services, eight mechanisms

◈ 8 cards

Computer, network and internet security separated by scope, and the X.800 catalogue of security services with the mechanisms that implement them.

Three scopes, and the clause that separates them

The field is named three ways, and the names are not interchangeable. The exam question is always which clause distinguishes them.

  • Computer security — protection of an automated information system's resources so as to preserve their integrity, availability and confidentiality. The scope is the system, largely at rest: its hardware, its software, its firmware, its stored data.
  • Network security — the controls that discourage, block, notice and repair security failures arising from data in motion between systems. The distinguishing clause is transmission. If the violation happens because data moved, network security owns it.
  • Internet security — network security specialised to an interconnected network of networks, where no single administration controls the path and the intervening infrastructure must be assumed hostile.
  • Intranet security, when the term appears, is the same discipline scoped to a single organisation's internal network.

The trap is that internet security also involves transmission, so "it involves transmission" alone does not pick a single answer. Read the stem exactly: the general term for measures against violations involving transmission is network security; internet security is the sub-case where the transmission crosses networks under different administrations.

Six service categories

ITU-T Recommendation X.800, the OSI security architecture, gives the vocabulary that most later protocol work still uses: a catalogue of security services, and a separate catalogue of security mechanisms that implement them. The distinction is the point. A service is what you want. A mechanism is how you get it.

The service categories are:

  1. Authentication — assurance that a communicating entity is who it claims to be. It has two forms, and they are separately examinable: peer entity authentication (in a connection, at setup, that both ends are who they claim) and data origin authentication (for a single message, that it came from the claimed source; it says nothing about duplication or modification of a stream).
  2. Access control — prevention of unauthorized use of a resource: who may do what, having been authenticated.
  3. Data confidentiality — protection of data from unauthorized disclosure. Its variants run from a whole connection down to selected fields, and include traffic-flow confidentiality, which protects the pattern rather than the content.
  4. Data integrity — assurance that data received is exactly as sent, with no modification, insertion, deletion or replay.
  5. Non-repudiation — protection against one party to a communication denying having participated. Non-repudiation of origin proves the message was sent by the claimed sender; non-repudiation of delivery proves it was received by the claimed recipient.
  6. Availability — that a system or resource is accessible and usable on demand by an authorized entity.

Eight specific mechanisms

X.800's specific security mechanisms — the ones built into a protocol layer — are: encipherment, digital signature, access control, data integrity, authentication exchange, traffic padding, routing control and notarization. (A separate group of pervasive mechanisms — trusted functionality, security labels, event detection, security audit trails, security recovery — is not tied to any one service.)

Four of the eight are routinely confused with each other because all four sound like plausible protections. Learn them by purpose, because purpose is what the exam tests:

  • Traffic padding — injecting filler units into the idle spaces of a link so that the volume of traffic looks the same whatever is actually being sent. Its purpose is to frustrate traffic analysis. It protects no content — encryption already did that — it protects the pattern.
  • Routing control — selecting, and changing, the physical routes the data takes, so that sensitive data travels only over links that are trusted, and so that a route can be abandoned when a breach is suspected.
  • Notarization — using a trusted third party to vouch for properties of an exchange between two parties who do not trust each other.
  • Authentication exchange — a protocol run whose purpose is to establish an entity's identity: the challenge and response, not the credential.

Note that three names appear on both lists — access control, data integrity and authentication all name a service and a mechanism. That is not sloppiness: the service is the guarantee the user asked for, the mechanism is the specific machinery in a layer that provides it.

Worked example — one message from a workstation to a remote server

A Northreach marker at home submits a batch of marks to the grading service in the campus machine room. Follow it hop by hop and name the scope and the service being asked for at each.

Hop 0 — on the marker's laptop, before anything is transmitted. The marks file sits on disk; the operating system decides which processes may open it; the disk is encrypted at rest. Scope: computer security. Service: access control, delivered by the mechanism of the same name (the access control lists the OS keeps), with data confidentiality delivered by encipherment.

Hop 1 — the laptop opens a connection to the university endpoint over a home ISP and the public internet. Scope: internet security — many administrations, none of them ours. Services requested, in order: peer entity authentication (is that endpoint really the university?), delivered by an authentication exchange over certificates plus digital signature; then data confidentiality and data integrity for the session, both delivered by encipherment with an integrity check value. If the university also cared that an observer should not learn when marking happens or how much, it would add traffic-flow confidentiality, delivered by traffic padding — nothing else on the list does that job.

Hop 2 — inside the campus network, from the edge to the machine room. Scope: network security: it is transmission, but under one administration. The university may require this leg to stay on links it owns rather than a leased path through a third party — that requirement is delivered by routing control.

Hop 3 — at the grading service. Scope: computer security again. The service checks that this marker may submit for this course (access control), records the submission in a log bound to the marker's identity (accountability, supported by the data integrity mechanism protecting the log), and issues a signed receipt so that the marker cannot later deny submitting and the university cannot deny receiving. That receipt is non-repudiation, of origin and of delivery, delivered by digital signature — and if the two parties did not trust each other, by notarization through a third party they both do.

Now do it yourself. Name the mechanism that delivers each of these services: data origin authentication · traffic-flow confidentiality · non-repudiation of origin. Then map these three onto the service they support: a challenge-response handshake · a keyed integrity check value appended to each record · a route policy that keeps a flow off leased circuits.

ServiceMechanisms that deliver itAuthenticationencipherment, signature, auth exchangeAccess controlaccess control lists, capabilitiesData confidentialityencipherment, routing control, trafficpaddingData integrityencipherment, signature, integrity checkNon-repudiationsignature, integrity check, notarizationAvailabilityauth exchange, integrity check, recoveryTraffic padding exists to frustrate traffic analysis.
A service is what you want; a mechanism is how you get it. Three names — authentication, access control and data integrity — appear on both sides, which is the source of most of the confusion in this table.

source ITU-T X.800 (OSI security architecture); RFC 4949 — not in Stallings & Brown 5e

source ITU-T X.800 (OSI security architecture) — not in Stallings & Brown 5e

source ITU-T X.800 (OSI security architecture) — not in Stallings & Brown 5e

source ITU-T X.800 (OSI security architecture) — not in Stallings & Brown 5e

source ITU-T X.800 (OSI security architecture) — not in Stallings & Brown 5e

source ITU-T X.800 (OSI security architecture) — not in Stallings & Brown 5e

NORMAL ~/memra/learn/comp-400/computer-network-internet-security-and-the-x800-services utf-8 LF